In the last 2 years I've hired and interviewed dozens of candidates. With the support of recruiting professionals, senior software leaders and developers that have previously worked at places such as AWS I was able to design a hiring process that works both for the candidate and the hiring manager.
How do I know that it works? Because 100% of candidates that I've made an offer to in the last year have accepted it and were very happy. And many of those that I didn't make an offer are still keeping in touch.
The 5 Step Interview Process
As a hiring manager, I'm directly involved in 5 steps of the process. But it starts one stage earlier.
Step 0: Interest Based Recruiting
The very first step is made by my recruiting partners. They reach out to developers and show a genuine interest in helping these people figure out what they want to do next. The recruiters ask about interest and what items are important in a new job. If the candidate's profile matches what I'm looking for and the job description matches their preferences, we proceed with the next step.
Step 1: Get to Know The Candidate (20-30 mins)
I want to get to know the candidate and also want to offer insights into the company and what I do at the company.
A candidate will be eager to join a team if the hiring manager establishes a certain level of trust during the interview process. Similarly, the hiring manager needs to trust a candidate in order to feel enthusiastic about the potential hire. As a hiring manager, building that trust is what I'm looking for in this 20 minute interview.
My interview consists of 4 sections
- I give a short pitch about the company and my history at the company (~5 min)
- The candidate presents what they have recently been doing, mentioning some examples (10-15 mins)
- Together we explore what is important to the candidate and what the company is able to provide. (2-5 mins)
- The candidate is encouraged to ask questions (3-7 mins)
I've found a total of 20 minutes to be enough to cover all of these topics if you're meticulous. Sometimes it feels like time flies or there are many questions and it's easy to spend more time, so I like to have the option to extend to 30 mins if necessary.
I've also found that asking Do you have any questions? only rarely produces any actual questions, while asking What questions do you have, for example questions about the company, the team, their working process or the role? and nearly every candidate has an important question on their mind. As managers in our every day job, it's our duty to show our active listening skills and ask specific questions that will provide us with good information. It makes sense to apply these techniques also to hiring. There is lots of info out there on how to ask better questions.
Step 2: Assess Technical Skills (60 mins)
As a manager, I've stopped leading the technical interview. Instead I will ask a senior developer to conduct it, while I sit in and take notes. For 1h we will try to dive deep on all topics that will affect the day-to-day job that we're interviewing for. We care in particular about the topics & skills which the candidate has mentioned on their CV. It is well understood that everyone has different experiences and strengths, so we try to focus on the candidate's strengths as well as covering the basics such as working with source control & in an agile process.
In a successful interview, I have learned something new from the candidate. If they have used a specific library or concept that they feel comfortable explaining, that is almost guaranteed to win this round of the interview and it can easily outshine deficits in other areas.
Step 3: Witness The Applied Skill (2-3 h)
Explaining a concept and being comfortable using it are two sides of the same coin – yet both should be checked. We like to conduct pair programming interviews at this stage, because it resembles how we work in a realistic environment. A senior developer (usually the same person who did the technical interview) will spend about 2h with the candidate to build something from scratch or bug-fix an existing open source project.
At this stage you see how a candidate handles feedback, how much you enjoy working with them and what kind of work they prioritise, given the 2h time limit.
The session ends with the candidate presenting what they were able to accomplish and what they would have done next if they had more time. During the pair programming session, the senior developer acts as a collaborator, not an interviewer. We've done the technical interview already before, so what we primarily want to know is what it feels like to work with this person every day in a realistic environment.
Step 4: Establish Cultural Aptness
Next, the candidate will meet the entire team (sometimes part or all of this happens before step 3). They get to know the people that they will work with moving forward. This is the first step to on-boarding them to the team.
I tend to have this structured as 20 mins with the designer, 20 mins with the product manager, 30 mins with the remaining developers (that haven't been involved so far) and 1h of lunch with the whole team.
Why not Cultural Fit? Because in an industry that's so dominated by white males, it's easy to fall for biases that end up with hiring more white males. To build a diverse team, you have to hire people that don't look and act the same as your existing team and focussing too much on fit you may end up favouring the wrong items. Instead cultural aptness makes sure that hiring this candidate leads to the right cultural mix.
What I'm looking for is to connect people in a way that allows them to judge: is this someone that I would like to spend 8h of my day with, 5 days of the week? The candidate as well as the team profits immensely from such a session. The candidate can fully picture the team and environment in which they will be working while the team gets excited about a new person joining, too.
Step 5: Making The Offer
Finally an offer should be extended to the candidate. If you're truly excited about someone (as you should be), then as the hiring manager you should be the one to reach out with the offer. This can be a short 3 sentence email, stating the salary, vacation policy and any core benefits. But an email from the hiring manager shows how much you care, because it's not your job to message the candidate.
If you're rejecting a candidate that has spent significant time interviewing with you, I also find it important to give details what went wrong. You don't need to mention every detail, but honesty is appreciated and candidates will be thankful. You may want to work with HR on this, since there can be legal implications when you mention why someone was rejected.
How To Ask Good Questions & What To Look For
It's become apparent that asking good questions is core to give meaning to the interview.
Allow The Candidate To Present Their Best Self
A candidate that has already done exactly what you're asking them to do will be bored in this job. So allow the candidate to present what they did, rather than what you want them to do. It will be easy to see similarities and differences, so that you can judge if they will be able to learn quickly enough. Only if you allow them to present their best self can you truly see the potential of the candidate.
This also means that you need to put effort into creating an environment that is realistic. Whiteboard interviews are very far removed from the every-day situation that a candidate will be in. You will test a candidate's nerves, but not their actual productivity. Through things like pair programming you see how comfortable they are in their own editor. Of course using Google/DuckDuckGo is allowed! More senior candidates know what to search for more easily, that's what makes them senior.
Always Ask For Examples
Candidates tend to sense what the interviewer is looking for and give the "correct" answers. This makes it difficult to judge if someone has learned their lessons through experience or simply read a few good articles on the internet. Being able to apply the theory and put it into action is a core competency to look for.
By asking for examples you will find out how a person really reacts in certain situations. The conversation will also be a lot more engaging if I ask you about the last time you had to optimise an SQL query, rather than when I ask questions about how PostgreSQL indices work.
Gently Test The Depth Of Knowledge
This applies in particular to senior candidates with 10+ years of experience. They will have seen a lot of different technologies & problems and will be able to scratch the surface on almost any technical topic. What helps is to ask for follow-up questions to explain more details. E.g. when we're talking about PostgreSQL optimisations, why did adding an index work? What kinds of indices do exist for SQL databases and how are they different? What is a btree anyways? And what's a scenario where this kind of index would not work?
With such a line of questioning you'll quickly find out how deep a candidates knowledge is. When they have extensive knowledge of the topic, they will be able to explain with a whole lot of context. It is often easier to ask these questions with superficial knowledge than to answer them.
But this is also where an interview can quickly become very uncomfortable. Remember that you are trying to allow the candidate to present their best self, so if you see that you've hit a dead end, move on to the next topic.
Good Talent Moves Quickly (And So Should You)
It is tempting to think that as a hiring manager you don't want to seem needy and shouldn't reply too quickly. You may also want to be able to compare a candidate to others and those people still need to move to the next stage.
Don't do that. Great candidates have long found another job by the time you can compare them to 2 or 3 others. Allow them to move to the next hiring stage as quickly as possible. If an interview went well, spend the next 5 minutes providing feedback (I usually communicate that via the recruiter) & figuring out when to schedule the next step. There is no feeling that's greater than being needed by the company you're interviewing with.
Sometimes it's not possible to move quickly – you may have doubts about an unusual candidate's profile and you may need to sleep over your decision or there may be budgeting questions that need to be clarified first. In those cases you can usually provide a timeline for when you'll be following up with a candidate to manage expectations appropriately.
Once you have found the right candidate and they did accept an offer, on-boarding begins. I've written about that before.
Latest comments (2)
Looks nice , I didn’t see anywhere where you talked about whiteboard interview !
What is wrong with that approach ?
I heard that many big companies use whiteboard interviews to assess candidates problem solving skills..
Thanks for the great question! I've expanded the section on Allow The Candidate To Present Their Best Self to talk about that. It's true that some big companies may use that approach, but I haven't heard anything to suggest that that's a good approach.
Writing code on a white board is so far removed from your actual daily coding, that I doubt you will gain any insights into somebody's real skill.
However a whiteboard can be great to discuss a problem, describe an architecture, explain SQL joins, etc. as those things may happen on a whiteboard also in your actual working life. So using it for those kinds of interview questions makes a lot of sense to me.