I have written about how tech interviews are too much like auditions.

If you want to be in an orchestra, you need to audition. That makes sense because an audition is close to what the job actually is—a performance. This also makes sense for actors, comedians, dancers, etc.

A typical tech job is not a performance. For one, there is no audience. And, unlike a performance, we make tons of small mistakes and corrections along the way. Imagine a band performing a song like we usually program—it’d be a mess and not very entertaining (or very entertaining if you think of it as avant-garde).

But, I do think there is value in seeing a candidate actually do the job you are hiring them to do, so what I have tried to do is to simulate work as much as possible.

Here is what I recommend:

• Describe it as pair programming. Unlike performances, this is something programmers actually do. Tell them that they are driving, and that you will be a helpful pair. This means that if you correct something, that that isn’t bad—it’s expected. You should correct things you don’t care about (and let them find the things that you do care about). Set up an expectation that mistakes are are ok.
  
• Start with working code, not a blank slate. Send them a small working project that is like your actual code. For me, that was a working iOS app with one screen (all code was in one file). Run the code and show them what it does. If you don’t require a specific language/framework, then this is harder, but perhaps you could prepare more than one. We had both Objective-C and Swift versions of the interview app when Swift was still new.
  
• Tell them what to expect beforehand. Before the interview, tell them exactly what the interview is going to be. “I will send you a project that does XXX using (language, framework, etc), you need XXX to run it, and then we’re going to add small features and do other things to it.”
  
• Ask a question that makes them read the code. The first question should be to do something extremely easy with the code that makes them have to read a good portion of it.
  
• Set an expectation that the code they write is a first draft, not production. Tell the candidate that this is “interview code”, not real production code, and we don’t have time to do everything that they would do. But, ask them to tell you what they would do if they had more time. If you want to see them do it (i.e. it’s part of the interview), ask them to do it—otherwise, consider it done.
  
• Answer any question that they would normally google. Tell them that you don’t expect them to have memorized everything, so if they would normally google something, to just ask you and you will tell them. This is just to speed things up.
  
• Remember that coding is one-dimension of the candidate. Being able to code is important, but it’s not the only thing that will determine success at the job. Pay close attention to collaboration and preparation (since you told them what to expect) and other aspects you find important.
  
• Don’t treat the coding interview as a gate. If you give a coding interview first and immediately reject people, then you are going to miss out on a lot of good candidates. Make the goal to rate them on a few dimensions and pass them if they could do the job. Then, later in the process, compare the candidates on all dimensions of the job that you tested.

The goal of the technical interview is to find out if the person can do the coding aspects of the job. So, to the extent that you are doing what the job requires, the better the interview is at answering that question.