Becoming a good technical interviewer

Things I wish I'd known when I started interviewing people. This article is part two in a two-part series.

This article is a continuation of my first guide: How to create a good problem-solving interview. It details some of the key elements needed to successfully conduct an interview with a software engineering candidate. Feel free to read that first, or jump right in. In this article we will focus on my tips to make the interview a pleasant experience for both the candidate and the interviewer.

Now that your team has prepared great technical exercises for the candidates, it’s time to get yourself ready to lead the interview. During the interview you will have a lot to do in a short amount of time: Evaluating a candidate, following their train of thought, challenging their decisions, paying attention to their behavior, forming your opinion of this person... Doing all of that in one hour requires strict concentration, which is much easier to achieve when you don’t have to think about the algorithm or exercise on top of everything else. 

Photo by Scott Graham on Unsplash

If you aren't familiar with the exercise that you'll be completing with the candidate, take at least one hour to do it by yourself. When I first started being an interviewer, my team had already chosen the exercise we use. Since I was new to this exercise, I really didn’t have a choice other than to sit down with a piece of paper and come up with a solution from scratch. Even if you participated in the selection of the exercise, I think it is still valuable to do the exercise by yourself, since it will help you follow what’s happening in the candidate’s head. 

While you come up with your solution, don’t rush for the algorithm. Instead, take the time to note the mistakes you made, the pitfalls you identified and the parts which feel tricky to you. Experiencing these things firsthand will help you identify when a candidate takes a wrong turn and, if needed, allow you to gently put them back on track. 

If you are in a team where people already interview candidates it’s time once again to rely on your teammates. Just like all other humans, we developers are social animals which means that we are very successful at learning through imitation. Leading an interview is no exception to this rule; you will learn a lot simply by shadowing someone who is comfortable leading an interview. So, before you take the big step of leading an interview on your own, make sure that you shadow at least two or three interviews, ideally led by different teammates. 

This will be a great opportunity to observe what your teammates do well, and what you think they could do better. Just because you are new to the topic doesn’t mean you can’t  provide useful feedback. Interviewers who conduct the same exercises day in and day out will naturally develop flaws or take shortcuts that they may not see on their own. Take particular note of several things when shadowing your peers:

After each interview you shadow, take 10 to 15 minutes to debrief what happened with your teammates. As a shadow, a great way to build your confidence for these debriefings is to try to give your opinion first and then discuss it with the lead interviewer to see what you agree on, what you could have missed or what they would consider important or not. That will force you to practice forming your own opinion, which will help you avoid just "going along" with your more experienced coworker's point of view. This often happens if they share their point of view first.

Shadowing the interview doesn't mean that you should only observe. First make sure the candidate clearly understands the situation: at the beginning of the interview, introduce yourself and let the candidate know that you are learning how to conduct an interview. During the session itself, try to ask at least one or two questions to the candidate. This will be good training to learn the right timing of when to prompt the candidate to get more explanations without disrupting their thought process. At first you may find yourself not understanding something the candidate is doing. In this situation, don't assume that it's because you are not smart enough. Most of the time it's because the candidate is having a hard time formulating clear explanations of what they are doing. Asking for clarifications will help both of you to continue the interview with a better understanding of what comes next.

Once you've shadowed a few interviews it’s time for you to take the lead. You might not feel ready—that's fine. That’s what makes it fun! To avoid completely missing an important point, and to feel reassured in your opinion, make sure to be shadowed by an experienced interviewer. They will be able to put you back on track if you get lost at one point and they will help you with the doubts you might have after the interview. Make it a point to ask them for precise feedback on topics you think you might have been unclear for the candidate. 

After a few more interviews you should start to feel confident leading interviews on your own. Congratulations on growing as an engineer! 

So, now you know what to look for during an interview, you are familiar with the exercise and you've shadowed a few interviews to experience the process. Now you have a candidate in front of you, a shadowing teammate behind you, and you start leading your first interview... How should you do that? 

A wise senior coworker of mine once told me, “No matter how good or bad they do, the candidate should end the interview feeling great about what they did”. This little piece of advice resonated greatly with me because I think it is so revealing about the culture we have here at Dashlane: we are not machines made to code. We are all humans with our strengths and weaknesses. The workplace should never be an environment where someone feels demeaned. The candidate is allowed to have a bad day, they are allowed to not be a good fit for the position, they are allowed to not be up to your expectations. None of this is their fault. 

Remember that if your candidate is performing poorly, you are not "wasting your time," in the interview. Rather, you are being presented with the opportunity to help another engineer get better and more experienced. Take a moment to bring your focus to the present moment and the task at hand. If you find your mind wandering and become stressed out by the feature you have to finish for tomorrow, it’s not the candidate's fault, and you should not punish them for it. Take a deep breath and bring on your positivity to make it a good moment for both you and the candidate. 

Recruitment is not an exact science. If you ever get frustrated because the candidates you interview are not good fit, you should not take it out on them. Instead, you should discuss with your talent team how to improve your pipeline. 

You probably know how stressful being interviewed can be for a candidate. Knowing what to expect will help them feel reassured. So even though our talent team at Dashlane does an amazing job at guiding the candidate and preparing them, I still always take a few minutes at the beginning of the interview to explain what will happen in our time together: 

Once everything is clear I can begin to show them the problem. Along the way I encourage them to ask any questions they may have, so they can completely understand what they are supposed to do. 

Photo by @kaleidico on Unsplash

You want to set your candidate up for success and sometimes this means gently pushing them in the right direction when you feel they are missing an important point or taking the wrong path. But doing that without giving them the solution is not always easy. Unfortunately, I think that finding the right balance here is entirely a matter of experience: It should come quickly after making mistakes a few times but that still means messing up before you find the right setting. 

One thing I observed when I shadowed new interviewers (and that I also did in my first interviews) is a tendency to search for the exact answer you are looking for. Here is an example: 

During an interview a candidate implemented an algorithm to iterate over a set of adjacent items in a two-dimensional grid by using a stack. In a follow up question my coworker, who was leading an interview for the first time, asked the candidate how they could have solved the problem another way. Knowing the exercise and the discussion I had with my coworker just before, I understood that he wanted the candidate to talk about recursive functions, but the candidate just didn’t have that in mind and couldn’t find that exact solution while my coworker was continuing to give him evasive clues. At that point I stepped in and casually asked the candidate if he was familiar with the concept of recursion. They immediately connected the dots and explained exactly how it could be used. If we had told the candidate from the beginning of the exercise to use recursion, we wouldn’t have been able to see their knowledge about stack data structures so it was great not to guide them too much. However if we hadn't mentioned the word “recursion” we would have moved on thinking they didn’t know this concept. 

The takeaway that I'd like to emphasize here is that you should give the candidate some leeway during your questioning, keeping in mind that there are always multiple ways to reach the same solution. 

An interview is, of course, a way for you to assess if you want to work with a candidate. Never forget that it goes the other way around too! A candidate has the choice of the company they want to join, and interviews with their potential teammates are one way to assess the culture and how they would feel in the team and in the company. It is important that you help your candidate to make up their mind about that. 

That is why earlier I mentioned that I always keep a buffer of time at the end of the interview for the candidate to ask me anything they want. I specifically state that their questions can be about the stack we use, our projects, our team, what I think of the company and I always make sure to give them honest answers. This allows the candidate to envision what their experience could be like when joining your company or team.  

Now you should feel pretty confident about doing your first tech interviews, but like most of the things in life, the first time can be scary. Here is a list of the questions I had when I was preparing my first interviews and the keys to solve them: 

That was something I was really afraid of: I would look like a fool if the candidate realized that I’m asking questions that I don’t know the answer to, right? 

The first thing to remember is that you are a developer who got hired to work in your company, and despite what your impostor syndrome could make you think, that means that you are qualified to do your job. As we discussed before, the best way to convince you of that is to do the exercise by yourself, several times if you need to. 

Actually, it’s not that important. After reading this article you should have realized that what matters is to check how the candidate approaches a problem. If they miss a particular edge case it doesn’t compromise their whole set of skills. Also, if they come up with a completely flawed solution you will notice. That’s why you want to prepare the exercise and shadow a few interviews. You will realize that there are usually only a handful different ways to reach the solution and a handful more of pitfalls. Because you've practiced, you will be able to identify them. 

First off, chances are it will not happen. Because someone is much more experienced than you are doesn’t mean they know some kind of magic tricks you never heard of. They probably will not invent a whole new kind of algorithm just for your problem. 

However, if it does happen it’s an excellent opportunity to evaluate how great of a senior developer they are. One of the key skills of a senior developer is their ability to communicate and to pass through their knowledge to junior members of the team. A developer with 20 years of experience who doesn’t do that is not much more valuable than a junior with good technical skills. And if they can’t show this skill during an interview, then they probably won’t do it in their day-to-day job. 

Another fear that I had was that a very strong candidate would find a solution in the first ten minutes of the interview and that I would have to somehow fill the rest of the time. Here again, chances are that it will not happen. However, if you do end up in this situation it’s the right time to use all your follow up questions and to dig into them as much as you can. Maybe the candidate just happened to do the same problem just the day before and got lucky. Following up on asymptotic complexity or by adding more challenges to the problem is a great way to double check that the candidate understood the problem and their solution well.

Also, if the follow up questions confirm that they are just a really good candidate, it’s a great opportunity for you to learn new things! Ask them about what they are currently working on, what was the most challenging algorithm they had to write, what was the last interesting programming trick they learned, what was the last interview where they really felt challenged. Never miss an opportunity to learn from someone more knowledgeable than you. 

Gif on giphy

Doing tech interviews has been a valuable experience for me because it is a unique way to see how other people think and solve problems and that is always an opportunity to learn something new and to mature as an engineer. If you had doubts before reading this article, I hope that you now feel confident that you have what it takes to become a great interviewer too. Remember that your candidate is probably as stressed out as you but they don’t know that you are, so just go for it and try to have a good time. 

Happy interviewing! 

Adrien Fabre

Read more