← Back to Blog | You're interviewing wrong

Most technical interviews ask the wrong question.

Companies think they're asking: "Can this person do good work here?" But what they're really asking is: "Can this person perform under artificial pressure while being watched by a stranger?"

These are not the same thing.

The Real Test

A Microsoft study (Behroozi et al., 2020) found that candidates were half as likely to solve an interview question when a proctor was in the room versus solving it alone.

Think about this study for a moment. Are you the type to get nervous when someone's watching you work? You might think a 1-hour coding interview is "just" checking if you can solve a problem in a short time. But think of all the other questions you're actually being asked:

Can you talk at the same time you write code? Can you do it well, without tripping over your own words?

Can you talk through a curveball question you didn't expect? Can you do it even when you're sweating bullets because you really want this job?

Can you be in the same room as a stranger you've never met before for an hour, and make them leave with a positive impression of you?

These are implicitly the questions companies are asking of you as a candidate, whether they intend to or not.

The Alternative

The research study above might lead you to think that we should just do all interviews in a quiet room alone. I think that might be worse for everyone!

The goal of a technical interview should be to judge how good of a coworker you'd be if you were to join the team. Collaboration is a necessary part of that judgement.

So instead of approaching the interview like a pop quiz, treat it like a pair programming session. You're not being examined. Let the nerves go. You're coworkers, and you've got a problem to solve together. Can you do it?

Here is how I'd approach a technical interview:

Show the interviewer how excited you are about the problem. All the best companies I've interviewed with have taken the time to build really interesting coding challenges that were related to the company's work. If they can't take the time to give you an interesting challenge, is this even a place you want to spend your time with?

Ask a lot of questions. You shouldn't be afraid of "losing points" for asking too many questions. A good interviewer will know how to give you clarification without giving away the answer.

You'll save a lot of time this way by making fewer mistakes, and you'll get to evaluate the interviewer on how well they can clarify a topic for you. An important skill if they're going to be your teammate or supervisor!

Next: as you work, note where you're taking shortcuts and where you're really focusing hard. I will even write comments like // this is bad after certain code segments if I'm moving quickly. It's okay to write bad code in an interview!

This helps the interviewer judge your skills better. You can probably describe the "right" or "optimized" way to do something faster than you can code it. So just stick to describing it and finishing the challenge, and maybe they'll prompt you to go back and "do it the right way" if it's important to the interview.

Last, make sure you're including your interviewer as you debug. You'll inevitably hit a test case that fails or some behavior you didn't expect.

Practice noting what you expected to happen, and what actually happened. Say it aloud, and make sure the interviewer agrees. I have seen many candidates misread an error message and go off chasing a bug that doesn't exist. I would've told them they were reading incorrectly, but they never made it clear what they were doing! You'll save yourself a lot of headache this way.

When you put it all together, this really makes the interview feel like a conversation. It opens up much more space for you to express yourself, and to "reverse interview" the company to see if you really do want to work there.

See how different this is than just coding away in a quiet room?

(inspired by some tweets here)