Interviews for software development positions are often terrible and there are lots of articles explaining how. The history of one of the more popular questions demonstrates how reason is often left behind in interview design. Google, one of the more famous users of complex coding problems and whiteboard interviews, found their interview process no better at predicting success than random chance. In other words, choosing randomly from all the resumes would have gotten them just as many successful employees as the interview process did. It is quite clear we waste lots of time and money to get at best middling results from our interview processes in general.

Thankfully, it’s not all hopeless. In addition to the many that have written about the problems with interviews there are lots of people trying to find better ways to choose successful coworkers. In his book Joy Inc. Richard Sheridan talks about the interview process that they use at Menlo Innovations. It focuses on creating a simulation of how real work at Menlo is done. Also, the interview process at Menlo requires that the candidate interact with their actual perspective coworkers. Then those same coworkers are the ones to decide if they want to make the candidate an offer.

The Simulated Work Interview

Having spent hundreds of hours interviewing software developers for positions both junior and senior I have come to the conclusion that using a simulation of the work in the job interview is a excellent technique. To that end this article will describe some of the practices that seem to have worked well for me. A lot of what I think makes an effective interview is related to how the work is done in the team that is hiring. That being said, take the method described in this article as an example to get you started and not a prescription.

Interviews serve several different primary purposes:

  • Evaluating the candidate’s ability to do the core work
  • Evaluating the candidate’s ability to work well with their prospective teammates
  • Selling the candidate on wanting to take the job

A great way get started meeting all three of these purposes is to have the candidate do some sort of simulated work activity with their prospective team members. This serves both to help the team evaluate the candidate but also to give the candidate a realistic impression of what working on the team will be like. Remember: the candidate is under the stress that we all face when we know we are being evaluated, so judge their performance and reactions appropriately.

Ideas for Simulated Work Activities

My favorite simulated work activity for teams that pair program is to conduct a pairing interview. If possible, the best way to do this is to have the candidate pair with one or two members of the team on actual work the team is doing at the moment. If having them work on actual production code would be problematic then create a task or series of tasks just for interviews. It is very important that these tasks are not brain teasers disguised as programing problems. However, it should be something with a bit of meat so no Fizz Buzz either.

If possible, break out some task the team has done in the past and find a way to make it possible in a stand-alone environment. If that does not work for the team there are many code katas available that could serve as the basis for a pairing interview. Remember that the candidate is dealing with working with new people and on potentially new things.

However, if your team doesn’t pair program you should not include pairing in the interview as it does not give the candidate a realistic portrayal of the job. Other options include giving the candidate a short non-essential contract(which you should pay them for) then evaluate and discuss their work the same way the team would if they were already a member. If that is not possible, another option I have explored is to have the candidate review code(either real or created for the purpose). Ensure that you discuss not just the issues but also how they would deal with them. This is an example of a code review exercise Anthony Sciamanna and I created in the past. It is taken from this repository we created for the purpose.

The common theme of all of these suggestions are that they allow the candidate to experience the real work or as close to it as the team can make possible while allowing them to interact with actual team members during the interview. This serves to educate the candidate on the position, provide a realistic opportunity for the team to evaluate their work, and provide for interaction with the team.

What Else Should be in the Interview

The rest of the interview should consist of helping the candidate understand what the position is, making them comfortable, answering any general questions they have about the organization or job, and trying to learn what they value in a position and organization. These parts are already fairly common in interviews so I will not go into detail about them in this article but remember that the purpose is as much about learning about the candidate as it is about teaching them about the position and why they should be interested in it.

Obligations to the Candidate

Regardless of exactly how the interview is structured the candidate should be informed in advance what the process will be. This allows them to prepare and potentially ask questions about how the interview will work. As interviewers this is to your benefit as it will reduce nervousness caused by the interview process and lead to better conversations. It may also lead to some candidates self-selecting to not continue but this is preferable to blindsiding them with an interview they are uncomfortable with.

Lastly, you should make a decision on the candidate in a timely manner and allow the candidate to know the results as soon as possible. Candidates that don’t hear back in a timely manner will often assume that the result of the interview was a no and that the company does not respect candidates enough to communicate that. This can lead to having a reputation as not valuing the time of candidates which many people will also take to reflect.

Final Thoughts and the Future

This style of interviewing has worked really well for the teams I have been part of. However, we should continue to study the possibility that certain types of interviews may be biased against certain type of candidates that would otherwise be awesome for the position. This is a very serious concern and requires hard work from the industry to learn how to do better. I believe that making interviews more like the work is a way to do this but more study would be required to demonstrate that.