There are several things I do in my technical interviews which I think make the experience quite a bit better than your average interview.

The first step comes before the actual interview in selecting the technical question. I have a few which I’ve created myself based upon actual problems I faced as a professional developer. They are, of course, somewhat simplified to be able to fit into an interview time slot, but they have the ring of a “real” problem rather than some annoying “toy” problem. Each question is intended to have multiple “extra features” you can add to it, so every candidate is able to complete at least part of it, and exceptional candidates can complete several. Only once have I had a candidate who completed all of the sections I had prepared.

Second, as the interview starts, I deliberately adopt a fairly casual, friendly, outgoing attitude, and chit chat. If possible, I try to crack jokes, and put the candidate at ease. I try to get them to tell me stories about something which will give me a sense of whether they’d be a good culture fit with the company and our team.

Then, as I introduce the technical question, I make a few points right up front to try to take some of the anxiety out of it:

1. This is a pair-programming exercise, and the primary point is to see how well we like working together.
2. I’m not particularly interested in seeing how much of the language you’ve memorized; if you’re uncertain on something, just ask, and we’ll look it up, if necessary.
3. I’m not as much interested in how quickly you solve the problem, but how you approach the problem, and how you think it through.

At this point, I turn my laptop around for them, and either project the screen or slide my chair around so I can see what they’re doing. On the laptop is a basic IDE already set up with a “hello world” program and a simple test case. There’s also a browser with Google brought up.

I think this is the most important part.

I want to make the impossibly contrived interview situation as close to actual working conditions as humanly possible. Starting with a simplified, but realistic problem, continuing with real tools (i.e., IDE and Google), and ending with us looking at the same screen, side-by-side, I’ve tried to emulate, as closely as possible, a situation developers find themselves all the time: pairing up to write a piece of code.

As we start to work on the problem, I try to strike a balance between being a helpful part of the pair programming team, and leaving enough of the problem for the candidate to solve that I can evaluate their performance. The more junior the candidate, the more helpful I am. The more senior, the less. If a candidate seems to be stuck at any point, I’ll suggest a possible solution.

During this process, I will deliberately probe a candidate to see how they react when:

• I suggest something which isn’t the best solution.
• I directly contradict a course they had chosen.
• I point out a minor typo or error in their code.
• I press them to justify a design choice.

I never interrupt the natural flow of the conversation to do these things, but I always have my eyes open for an opportunity to slip them in. In all of them, I’m looking for the candidate to have the best possible answer in mind, and to neither try to boost their own ego or mine.

As we get to the end, I keep my eye on the time (easy, since we’re looking at my laptop where I keep it up in the corner), and let them naturally stop when we get to the end of a part with somewhere between 5–10 minutes left. At this point, I let the candidate ask me questions for the remaining time.

✧✧✧

I think the important take-away here is to try to make the interview feel as much like a pair-programming session on a real problem as possible. Pick a problem which isn’t directly from an algorithms textbook. Set up a real development environment for the candidate (for coding questions). Sit next to the candidate and look at the same screen, just as you would for a pair-programming session (or stand at the whiteboard with them, for a more design-y, less code-y question). Finally, don’t interrogate the candidate, or just let them squirm if they’re stuck; be a good member of the “pair” and help them along.