Running technical interviews

Getting your interview process right is one of the most important decisions you’ll make when it comes to growing your engineering team. It’s important to be thorough in your technical screening, but not at the expense of time efficiency.

One size doesn’t fit all.

Don’t slip into the mindset that there’s only one best way to evaluate your candidates. Interviewing tactics used by companies like Google and Apple, while rigorous, may not actually be effective for your organisation.

Why?

For one thing, adding many stages to your interview process will extend the length of your time to hire, putting you at risk of losing candidates to other offers. Amazing candidates are, well, exactly that: amazing. Which means that when they’re ready to poke their head into the market, they’ll be snatched up quickly.

Second, a candidate’s ability to answer mind-bending puzzles is not necessarily indicative of their ability to 1) dig into your code base and solve everyday technical problems, or 2) become an engaged and participating member of your team. This doesn’t mean you should never ask them these kinds of questions; rather, we’d recommend that you take a considered approach when choosing puzzle-type questions. Make sure that you’re evaluating for a candidate’s ability to effectively analyse and communicate, rather than raw knowledge of abstract topics.

With that in mind, here are some ideas you can think about when developing the format of your technical interview process.

Technical chat

Some of our clients believe that if you can hold your own in a free-flowing and in-depth conversation about technical topics, then that’s enough for them. It’s an opportunity to probe into the limits of their knowledge, see how they respond to feedback or questions they don’t know how to answer, and get a general sense of their approach to problem-solving. Others ask for candidates to come with a piece of code they’ve written (warts and all) to serve as the basis for a lengthy technical discussion about that code.

Take-home assignment

This is pretty self-explanatory – give candidates a small project or exercise that requires them to demonstrate what they know and creative solutions to what may seem like cut-and-dry problems. Some of the best challenges we’ve seen have come from mobile development teams (for SaaS companies) that ask candidates to recreate a simplified version of their own app using defined sets of data provided to them. Bear in mind that not everyone has loads of spare time to devote to a coding challenge or may not be able to drop everything to complete it immediately. Also keep in mind that if a candidate is juggling multiple job interviews, they may prioritise applications with companies that don’t require a take-home test over ones that do. A good rule of thumb is to allow a week for completion of the exercise, but make sure the candidate knows not to spend more than three or four hours actually working on it.

Pair programming

If you’re a team that does a lot of pair programming, it might be a good idea to integrate this into your interview process. It’s a good way of recreating real-world working experiences with candidates, giving them an opportunity to see how your team does things. It’s important to note that some developers just don’t enjoy pair programming. They may find it awkward or stressful, or that it infringes on the personal space they need to think creatively. It doesn’t mean they hate collaboration (we think everyone can agree this is super important no matter how you do things.) It just means that this kind of programming isn’t their cup of tea. This part of the process will ensure that candidates are aware of and comfortable with your actual working environment, setting them up for success later on.

Whiteboarding

For a long time, whiteboarding was seen as the popular choice for seeing how people think on their feet and approach high-level design problems. That’s changed, and for good reason. Candidates are usually extremely nervous already and adding stressful conditions where they’re not able to use their everyday development tools doesn’t help. At the end of it all, you’re probably not going to get an accurate representation of how someone actually writes code. If you’re looking for syntactically-correct code that runs, reconsider the whiteboard and consider opting for some of the methods we mentioned earlier.

Code review

For more senior candidates, a coding challenge may not provide enough insight into the kinds of qualities you need to evaluate. In these cases, why not have them review someone else’s code? Their responses can give you valuable information about their approach to providing feedback, mentoring, and the kinds of practices and habits that they consider to be indicative of good code. A session devoted to a code review would also be a shorter time commitment than a full take-home test.

These are some approaches we’ve seen used to great effect in successful companies. Remember: there’s no single right way to run technical interviews. But whichever you choose, it’s important to keep the balance between efficiency and rigour in mind. If you’d like some feedback on your interview process, get in touch and we’d be happy to brainstorm with you.

‍