Interview as audition

We finished a round of hiring a few weeks ago. As at the other small companies where I've worked, I participated in the interview process. I've found that with several interviewers each interviewer can develop an individual interview style with the confidence that other interviewers will discover or delve into candidate aspects that may be missed by his or her own interview. When I interview I focus on relatively high-level architecting and designing skills. I believe I've been more successful the more I've run the interview like an audition.

Lots of companies interview engineers and they do a fine job finding qualified candidates. If you think your interviewing skills are fine, then this article isn't for you. If you think you are mostly fine and just want two tips to improve, here they are.

1. Use Behavioral Interviewing techniques. For example, instead of asking the closed-ended question "Do you work well in teams?" which gets a "Yes" from almost everybody, ask a question which requires the candidate to give examples. "Tell me of a time when your team worked really well." Asking the opposite question is also fruitful: "Tell me of a time when your team completely failed." Follow-up if the candidate doesn't go into sufficient detail: "What made that team work? What made that team not work?" Specific examples can be checked with references if you have doubts about their accuracy.
   
2. When asking an candidate to produce code, require the candidate to solve at least one of the problems while you watch. Ask questions about the design and ask the candidate to demonstrate the solution.
   

The rest of this article is about the second tip.

Long before I was a professional engineer I was an amateur actor and occasional director. I wasn't a very good actor or director, but I learned how to audition from both sides of the proscenium arch. When I auditioned actors I wanted to see basic technical skills and the ability to use those skills in a variety of situations. Including, of course, the role being auditioned.

Many of the engineers with whom I interview focus on technical knowledge questions. Usually the interviewer asks several questions on a technology that the candidate can get either right or wrong. These are fine things to ask in an interview, but I find the overall whole lacking the part of seeing the candidate put them in practice. This is where I bring my acting/directing experience to the interview process.

The software engineering equivalent of performing a scene is designing a solution to a problem. I like algorithmic problems, but you should pick something you understand well and can realistically apply to your company's product. Try to find problems that can be solved within 20 minutes but aren't trivial.

I tell the candidate that the problem is difficult and I'm not expecting a perfect answer right away. I ask the candidate to use the whiteboard and think aloud as much as possible because I'm evaluating the candidate's thinking and problem-solving skills and not just the finished design. Most people don't know how to think aloud so I also ask questions while the candidate works if the candidate forgets to talk.

Most candidates arrive at a first answer that is simple and wrong. Instead of telling the candidate that the answer is incorrect, I ask the candidate to demonstrate the design using input I specify. The candidate obliges and we walk through the algorithm. At some point the algorithm doesn't behave as desired and the candidate realizes there is a problem.

This is an important point to reach. I re-iterate that I don't expect a perfect answer immediately and that mostly I want to see the candidate's thinking process. Sometimes the candidate understandably pauses quietly to think deeply. I ask the candidate what did he or she learn while running the design. I repeat my request that the candidate continue thinking aloud.

What remaining self-consciousness or interview-nervousness existed usually evaporates. Most candidates drop all pretense and enter raw problem-solving mode. I get to see if they tweak a pretty-good design or throw it out completely. I get to see if they cooly evaluate options or wildly try everything. I get to interact with them under pressure. Many solve the problem on their own. Some need guidance. A few never find a solution. But in each case I got to see the candidate be an engineer rather than just talking about being one.

I don't think this interview style is for everyone. Admittedly it requires a lot more improvisation than just going down a list of pre-written questions. If you invest the time, I think you will find this an invaluable technique.

Image © iStockphoto.com / John-Francis Bourke

Follow me on Twitter @jsjacobAtWork.