When you’re hiring software developers, it’s vital to assess that they can actually solve problems with code. In my experience, this is harder to get right than you may think. Let’s take a look at four popular solutions to this problem, and try to work out the best option.

A quick chat

Most interviewers first try a general, fairly freeform conversation about code and technical matters. As they talk, they’ll use their intuition, experience and common sense to get a feel for how experienced and competent the candidate is. I’ve been on both sides of this kind of interview and seen them produce mixed results.

The first problem with the unstructured chat is that you’re not assessing the most important thing. You’re not hiring this person to talk about code, you’re hiring them to write it. You run a high risk of striking a false positive and hiring someone who knows all the buzzwords but can’t actually apply the concepts in practice. Worse, you’re likely to produce a lot of false negatives. You may pass on people who get anxious or flustered when discussing abstract technical concepts in a high pressure interview situation, but could produce excellent work in the actual job.

These kinds of interviews are susceptible to interviewer bias. There is never a fair comparison between two different candidates because the conversation is steered by the interviewer. We all have cognitive biases and the bias towards tribes or in-groups is especially deeply rooted. These discussions often end up down a rabbit hole of some esoteric technical detail that is important to the interviewer, foreign to the candidate, and has little or nothing to do with the job at hand. This is also more likely to happen when the interviewer and candidate have less in common.

Complete a Questionnaire

A common attempt to avoid the problems of the above method is a checklist-style questionnaire. The interviewer seeks to reduce the opportunity for bias by asking the same set of questions to each candidate and then giving them each a score or ranking based on the results.

This throws the baby out with the bathwater. A qualitative approach is critical in interviews, as no two candidates compete along exactly the same vectors. There is usually a description of the role, but the ultimate goal is to hire someone who will make the company more successful. You need to be open to explore the particular strengths of the individual. No two candidates are exactly alike and you must be prepared to recognise all of the skills, talent and experience that they could bring to the role.

Discuss Their Code

The most effective interviewing tool I’ve come across is to get a sample of the candidate’s work. What better way to see how well they build something than by looking at something they’ve built? What better way to guide a technical discussion than by having some actual technology to discuss?

To do this, you could look at some of the candidate’s past work, but this is often a non-starter as all of the candidate’s previous meaningful work is owned by former employers.

Some developers have open source portfolios you can draw upon. However, this is often in a different language or framework and almost certainly built to solve a totally different problem than the one you’re hiring for. So it’s of limited use, aside from showing their commitment to coding outside work.

Complete A Code Challenge

The code you discuss should be as close as possible to the kind of work you would actually like them to do. Once you have this, you no longer need an abstract conversation about whatever is on your mind or a preconceived list of questions. You can talk to them about a real sample of relevant work.

This lets you ask more interesting, helpful questions:

  • Why did they make a given set of trade-offs?
  • Why did they choose a given abstraction over another?
  • How would they write this code differently for performance optimisation?
  • What would they change if the requirements were different?

In this way, you can see what they are really capable of. You can gauge their experience and their technical values. You can see how flexible they are in the face of shifting requirements. You can see how well they’re likely to do the job by simulating them doing the actual job.

The gold standard would be to put them in your actual team, doing actual work, for a meaningful period. Ain’t nobody got time for that. Your team doesn’t have the time to on-board that many people. Your candidates – in-demand developers – have other interviews and probably an actual job.

The more manageable solution is to get the candidate to write some code specifically for this interview process. The project requirements should be as similar as possible to what they’ll actually be asked to do in a normal day on the role. You can ask them to build out the solution using tools and approaches that match what your team is using. You can give each candidate the same set of requirements in order to establish a baseline.

I’ve hired a lot of software developers, with both good and bad results. This is why I use code challenges, and this is why I built Takehome. If you’re sold, now learn what makes a good code challenge.

— David Banham, Takehome