A Complete Guide to Interviewing Candidates — From Competencies to Questions to Debriefs
Interviewing can be complex, and stressful. Here's a guide to doing it well.
Over 12+ years at Amazon as a Director and Bar Raiser Core member, I interviewed over a thousand candidates, and ran the debrief process for the majority of those candidates. I’ve helped shape interview policy, ran interview classes for new interviewers, and trained bar raisers.
All around, I think I’m pretty good at interviewing people. I’ve also written many articles on how to interview well. If you’re job hunting, I’m convinced that reading my articles is a good use of your time.
This time, I thought I’d shake things up! This article is for the interviewer. The person on the other side of the table. And it ended up being an extra long article. Sorry, turns out there was a lot to cover!
You see, many people don’t get training on how to be a good interviewer. That’s how you end up with those Reddit threads with everyone hating on the interviewer.
“That interviewer asked me this horrible question! And they didn’t give me enough time!”
”Oh dude, what a terrible human! You shouldn’t take the job even if they offer it to you!”
”Yeah! I’m glad I failed!”
Interviewing is legitimately hard. Those who are new to it can feel overwhelmed, and just as stressed as the candidate. I’m hoping that this guide can ease you into being a decent interviewer. And even those who have interviewed a few hundred candidates may learn a thing or two.
Welcome to those of you new to Scarlet Ink! Each week I send an article to all subscribers. Free members can read approximately half of each article, while paid members can read the full article.
For some, half of each article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
Summary of the Interview Process
Let’s walk quickly through a generic interview process. It feels like a good place to start. At least we can make sure we’re on the same page. Let’s start with after a candidate is identified as a potential hire.
First, A candidate is screened by someone.
Second, If the candidate passed the screen, an interview loop of a few people is created.
Third, You and a few others interview that candidate.
Fourth, A debrief happens. Which is a decision-making meeting to decide whether you should hire a candidate or not.
Ok, since we’re on the same page, let’s talk about those steps.
Screening Candidates — Why is it special?
Most interview processes have a screening step involved. Why is that?
Let’s assume your company is like Amazon, and they’d like 5 people to interview, and agree to hire a candidate. If it turns out that the person is completely clueless, that’s 5 hours wasted.
In fact, if you’ve done any amount of resume reviews, you’ll realize that the majority of candidates for your positions are not suited for those roles. They have the wrong amount or type of experience. They don’t speak your language, or aren’t eligible to work in your country. You can save 80% of your organization’s interviewing effort if you check some very basic things.
A key point to think about. Screens and interviews serve different purposes, so I’d argue that you should think about your vote on these candidates differently.
A screen is created to make certain a candidate is a "reasonable” option to hire for this role. I've often phrased it at Amazon as “They’re likely to get some yes votes.”
Your vote on a screen is not a “hire” vote, it is a “We are willing to interview this candidate.” That means the bar is drastically different. You don’t need to check if their coding is “good enough” (for example), you need to check that they’re not horrific at coding. Very different.
When you’re doing full interviews, your vote is “we should hire this candidate” (or not), which is why your questions and evaluation of those questions should be different.
If you are already doing a screen interview, why do you need more interviews? Why can’t you simply interview once, and hire? Two major reasons:
A single interview can’t possibly cover all the areas you want to check for a candidate (see covering competencies below).
You want more than one opinion because humans all see things differently. See debrief pointers below.
Considering the above, what types of questions would you want to ask in an interview screen? Questions which can be answered quickly, and would touch on the major areas you want to validate about the candidate’s resume.
“Could you briefly describe a recent project you worked on?”
“I see you listed both Android and iPhone experience. Could you explain some of the challenges of each platform?”
“You mentioned proposing multiple new products at your last company. Could you briefly explain a couple of them to me?”
This isn’t a time to get particularly deep, but to listen for warning signs. Did they lie on their resume? Can they communicate clearly? Do they feel like they have experience in the areas you’re interested in?
A couple of brief things to keep in mind.
Don’t let them ramble. You have 1 hour and a lot of ground to cover. “Terrific! Got what I needed on that one. Let’s move on.”
Don’t get distracted by going too deep. I’ve seen engineers get tangled up quizzing someone about memory management in Java, and neglect to verify anything else from their work history. You need to make certain they’re competent enough to be interviewed. That’s it.
Covering Competencies
Once a candidate is passed along to an interview loop, it’s time to verify that they’re a well-rounded future employee. So plan on somewhere between 3 and 5 (I can’t imagine more than 5 is ever needed) people asking questions. I think fewer than 3 risks too much randomness in your process. More than 5 feels repetitive, and I’ve seen convincing statistics demonstrating that there is no added data with more than 5.
Why can’t we randomly interview? Because I’ve seen what that does. You end up with 3 interviewers, and they all ask the candidate to explain their most recent position. Or 3 engineers ask similar algorithm coding questions. You get a strong signal on one thing, but zero signal on other important things.
What are the essential things? Let’s start with the job requirements, plus the ways that hires fail. Because what you want is someone who will not fail, and can meet your job requirements. Let’s start with a standard technical people manager.
People: They need to manage people competently.
Tech: They need to oversee technical decisions.
Projects: They need to keep their team’s projects on track.
Communication: They need to communicate upwards and outwards competently to represent their team.
Priorities: Generally important is having a good head on their shoulders for priorities (technical, financial, product, etc).
What doesn’t fall into the above? That feels like a few useful broad categories to start with.
Now, you don’t want a single signal on anything critical, so you do your best to pair up two of those categories for each interviewer.
Let’s say we have 4 interviewers.
Interviewer 1: People + Priorities
Interviewer 2: People + Communication
Interviewer 3: Tech + Projects
Interviewer 4: Projects + Tech
There we are. We have 2 people checking people management, project management, and tech. 1 person each checking Communication and Priorities.
You can repeat that process for any job position. For engineers, we often have something like 2-3 coding, a design interview, and various “leadership” style questions.
The key is to start by identifying what you want to check, and then spread those out among your interviewers.