I've always been passionate about the way we hire in tech. In any company I work at I attempt to identify the most successful employees and what skills they have. Did the interview process they went through highlight those skills? Or did those employees happen to get through anyway?
In recent years I've been lucky enough to design interviews myself. I thought it'd be interesting to write about it.
Do the upfront work
The most important piece of a hiring process is to make sure you're clear on what type of work a candidate will do. What level of proficiency do they need to have? How much support from other teammates is reasonable to expect and for how long? What skills do existing team members have that you're looking to complement?
The answer may be that you're comfortable with a variety of potential candidates. But knowing that up front helps you determine who should be involved in the process, what they should be looking for, and what level of experience a candidate needs to be successful.
This also helps you write a reasonable and effective job posting, but that's a post for another day.
Does this interview reflect the job?
I always start from scratch when building an interview. While my style is similar, a customer success engineer does a very different job than a frontend engineer. The interview process should reflect that.
The closer the questions match on the job tasking, the better the signal is. So what does that look like?
Suppose you have a role that requires someone who can work autonomously. Additionally, this person will need to write code that integrates with a number of new and unfamiliar technologies.
The interview should give them a chance to do that.
You can create a small codebase (super small, less than 3 relevant files) with a bug in it and an integration most people won't be familiar with. Ask them to fix it. Note that you should be able to solve this challenge in 5-15 minutes when testing it out. Will explain shortly.
If your candidate needs to have particular technologies installed on their machine make sure to define those and have them set it all up before the interview. It doesn't spoil the interview exercise and you don't want to burn valuable time during an interview.
Some other examples
Customer Support - A customer's site is rendering unstyled. Where would you start? What questions do you have for them?
Documentation Engineer - Here is a PR for a README, what recommendations do you have? Is this enough information?
UI Engineer - Here is a codepen with a table. I've made you some fruit, can you place it on the table? (This isn't my invention, but it's a great one)
All of these interviews are giving candidates a chance to show how they'd do the job you're hiring for. And it includes things they aren't already expected to know! This is a great way to determine if they can unblock themselves and learn on the job. However, you have to give them the tools in the interview to show you that.
Nerves matter
I mentioned designing a coding exercise that takes you, the interviewer, 5-15 minutes. Why should the exercise be so "quick and easy"? Because you're testing it with people who know the answer, the context, and aren't under pressure. 5-15 minutes could be 20-40 in an interview depending on what end of the range you're in. Plus, it gives candidates plenty of chance to go down the wrong path and try something else. You want to see that!
To get an accurate measure of a candidate's ability make sure you let the candidate solve the problem as if they're in a real world scenario. Google, docs, asking questions are all allowed. They don't even need to get the answer right! Are they going down logical avenues? Do they seem to know the ecosystem well enough to make good assumptions and work through the bug? You can typically tell quite quickly.
And keep in mind the level of seniority you're looking for. For a junior candidate talking through a potential reason for the bug and searching in the wrong direction could be enough. If you give them a hint do they get on the right track? Awesome.
For a senior candidate maybe you'd expect them to isolate the technology causing the issue and find a doc with the solution.
In both cases you've given them an unfamiliar problem and expecting them to work towards a solution. However, their efficiency with doing so will differ.
As an aside, it's important to remember we all have different levels of familiarity with particular types of syntax. This is generally dependent on how often we use it in our current environment. Don't discount candidates based on what they look up, you want to see what they do with it.
What other skills will they need?
Including coding exercises in your interview isn't the only piece of the puzzle. You'll also need to think through necessary collaboration or communication skills. Depending on what they are, there are plenty of ways test for this in your candidates.
Will they need to conduct code reviews? Let them do one live. Give them realistic parameters and let them ask questions to get context and then give their recommendation.
Will they need to architect a system? Ask them about previous codebases they've worked on. Dig into various details to understand the depth of their knowledge in those areas. Do not press too far! If it's clear they were less comfortable with a particular piece of the codebase that's reasonable. We all work on teams. You're looking for opportunities to see what they know, not what they don't.
This is a two way street
A significant portion of your interview should be set aside for the candidate to ask questions. There are a couple reasons for this.
You want a mutual fit. Onboarding is resource intensive and you want someone who is going to stick around for a while. Let them have the opportunity to ask in-depth questions to people they'll be working with directly.
Questions candidates ask are often just as illuminating as those you ask. Are they asking about opportunities to grow? Are they worried about the balance of certain responsibilities? Do they prefer a certain collaboration style?
What does success look like?
I have two goals for every interview. Did the candidate come out feeling positive about the experience? Did both myself and the candidate learn something new?
If I check both those boxes it was a great interview. And ALL interviews should meet this bar whether I feel the candidate passed or not.
Technical interviews do not need to feel like a midterm exam. And I hate that I have to say this, but interviewers should never be intending to prove their intelligence. Learning something new as an interviewer is a great sign!
But you didn't include algorithms
I've reached the end of this post and not once mentioned binary search trees. 😱 gasp
There are roles that work on scaling and may require extensive knowledge of algorithms. But if that isn't the job you're hiring for why include them?
The interview should match the job. That's genuinely the best advice I have.
It takes more work to build interviews like this up front. But watching someone do the job you want to hire them for is more than worth it.