Technical interview – advice for technical recruiters

For the past few years I’ve been doing technical interviews for the companies I’ve been working with. I’ve always had a mission that I wanted to make a technical interview a good experience as I remembered some interviews that I had participated in as
a candidate. I wanted to have a good set of questions that would really verify if the candidate was a good candidate, and not if he or she knew all the irrelevant details or some tricky edge cases of the language. 

But when I’d started interviewing people I realized that it was not an easy task! Based on a one-hour discussion I had to decide whether the candidate would be a good fit and would know how to deal with challenges over the next couple of years. So I made a lot of experiments, trying different sets of questions and different approaches. Over time I accumulated multiple rules that I apply to the tech interviews and I wanted to share them with you:

Don’t ask theoritical questions

Instead show examples and ask for a result, and to describe why that is. It could be that the candidate has done multiple technical interviews and is familiar with all the “typical” interview questions you would get when typed in “software engineer interview” etc. And it could be possible that such a candidate knows the answers but doesn’t really understand where the answer comes from. 

You could even add a simple task to solve. For example, you would like to check if a candidate understands closures in JavaScript. Don’t ask the question “describe what is closure in JavaScript”. Show them the code

// how would you implement `counter` function
const add = counter(0);
console.log(add()); // 1
console.log(add()); // 2
console.log(add()); // 3

and after they implement it ask how it works.

Don’t ask too general questions 

“how would you write a web app?”, “what is your approach to stage management?”, “what code structure would you use for your code?”. These kinds of questions don’t have a good answer. And in my experience they won’t tell you much about the candidate either. Instead, the candidate will ask clarification questions, “what do you mean?”. They may even try to sense what you really want from them and try to answer to fit your needs instead of backing up the answer with their experience. I prefer to ask more detailed and specific questions, but still open-ended to let the candidate elaborate. I would rather ask “how would you choose a tool for stage management, describe your thought process” or “how would you design a web app that has both HTTP endpoints and event queue handlers”. 

The tech interview is usually short, and I find it useless to spend time with the candidate trying to figure out my thought process and what I mean with my questions.

Don’t be afraid of grumpy developers

From time to time you may come across a candidate that is going to undermine your questions. While giving the incorrect answer they may start to complain that the question is contrived, far-fetched and nobody uses this in real life. 

First of all, don’t be intimidated by such candidates. Remember that you’ve put effort in preparing the interview and finding the best questions. Don’t feel the need to accept the candidate just because you felt that your questions were wrong and the candidate exposed that. It can be their coping mechanism that they learned in childhood and keep using in adult life to achieve what they want. 

On the other hand, don’t try to fight them back either. The interview doesn’t serve as a place to improve the recruiter’s self esteem.

I would prefer explaining to them that the interview takes only 1 hour and real life problems are much more complex and take days if not weeks. The tech recruiter’s task is to prepare questions that would let them to extrapolate the candidate’s abilities in the future based on the results of the one hour interview. If the candidate keeps undermining your questions afterwards, it may be also a sign that they would do it as well within a team. 

Leave some space to follow up on related topics

Give the candidate a chance to show their skills in related areas. Let’s say a candidate solves a programming challenge in React. They start to write a list component. Ask why they used <li> instead of <div>. Maybe it will lead to semantic HTML, maybe it will show the candidate knows a lot about accessibility. Or maybe they know a lot about SEO. 

A tech interview shouldn’t be a checklist of required skills. Software engineering isn’t only about writing code, so the more the candidate knows about related fields the better. 

Always give a coding challenge

There’s always a chance that a candidate knows all the theory and still isn’t capable of writing a code. It doesn’t have to be a huge task, but also it can’t be a simple one liner. Treat it as a chance for them to prove that they really know what they’ve been talking about so far. 

Also, let the candidate know that it doesn’t have a huge impact on the final decision if they finish the task on time or not (unless this is crucial for the interview and the task itself). It’s good to give them some psychological safety considering that the interview itself can be a stressful experience. 

Give the candidate space to talk about themselves

Start the interview with some space when the candidate talks about his/her experience. Talking about their own experience is something they know the best so they may feel more comfortable. But remember about time boxing, because you still need to verify your assumptions. 

Leave space for questions

Don’t fill in the time slot completely with your questions and assignments. The candidates also want to know something about the company from the engineer’s perspective. Sometimes there are no questions, but sometimes there are a lot. 

Ask yourself if you would like to work with the candidate

One thing that I use to do when I have mixed feelings about a candidate is to ask myself if I would like to work with the person or not. Chances are a candidate could have gaps in the technical skills but has a huge amount of contagious enthusiasm. It could also surface that the questions that you asked are not as important as you initially thought. Or the opposite case – the candidate knows everything about the internals of the language, knows all the patterns, worked with all possible databases, and still you couldn’t imagine even a day working together.

And at the end a bonus tip for remote interviews:

Remote interview – Prepare a document to share in advance

prepare a document that you can share with the candidate in advance (and give the right permissions to access it in case your company uses GSuite). Google docs is the best tool for it as you immediately see what the candidate is writing. 

Conclusion

I’ve been trying to find useful rules that would help me run good interviews for quite some time. Ultimately I ended up using these:

• I try to avoid theoretical questions, and instead I focus on code examples and expect the candidate to explain them to me
• I avoid too general questions. I value each minute of the interview and ask my questions in a way that doesn’t leave any doubts
• I don’t get intimidated by and don’t take revenge on candidates that try to undermine my questions and tasks. I try to explain to them why I chose these questions. 
• I ask open-ended questions to let the candidate shine in other, not always obvious areas
• I always give a coding challenge to verify if the candidate really knows how to write code
• I start the interview with the candidate talking about his experience to make them feel more comfortable
• I always leave space for questions
• I ask myself if I would like to work with the candidate
• If I run remote interviews I prepare google docs in advance so I can easily share code snippets with the candidate