Stop Interactive Code Challenges During Interviews, Do This Instead

Interactive coding challenges during an interview are common place these days. The idea is that you’ll get an idea of the type and quality of work a candidate will produce by watching them code during an interview.

This is very wrong.

I’m going to break down what’s wrong with this and what you should do instead.

Live Coding Is Stressful

An interview is already stressful. The interviewer is attempting to find a good fit for their position. They’re spending lots of time and money now - and will continue to invest significantly in this new employee. They want to know they’re getting their money’s worth and that they’re not bringing on an anchor. On the flip side, the interviewee is stressed out. They want this new job, their well-being depends on it. They have to figure out how to properly impress the you and the interview staff.

On top of that, you say “do your work, let me stare at you.” Obviously I’m joking with the words, but it’s kind of the same thing.

With one of my teams, I had a famous “punishment.” If you had a second pull request rejected, I’d sit with you for the next 2 hours, watching over your shoulder, talking to you, commenting on your code. For most people this was stressful (but it also pushed them to become better programmers - not only did they experience consequence, I interactively shared things with them to help them become a better coder.) The reason this was a “punishment” is because they were doing their work while another person was staring at them.

Both of you are already in a stressful situation. You do no one any favors by ratcheting that up.

“But, Aaron, our work can sometimes be stressful! This prepares them for it.” No. I used to think this, too. Ashamedly, I admit I used to think stressing a candidate out during an interview would give me insight if they could handle the daily rigors. That was wrong.

Very rarely, do employees get fired after one mistake. However, you may likely not hire someone if they make one mistake. It’s not fair, but it happens. The stress you experience during the work is a different type of stress. It’s coming from a date-driven or a requirement-based educated point of view. The interview system is much more vague, so the stress is different. The only equivalent stress you could experience as an employee would be if the boss said “I’m expecting you hit this next thing out of the park” but then walks away. You have no idea what they’re talking about, which thing it is, and what that really actually means. Most often, work stresses have some sort of defined goal, so the stress is different. It’s not ok to equate these two types of stress.

People Code Differently

I tend to code my best work in my home office, wearing a t-shirt and listening to acoustic rock. Others might want to put on headphones. Some strange creatures like being in the mix of others while they code, like a coffee shop. Point is, everyone has a different environment that they code in. Even if you consider that your employee could work in an office, and you’re testing them in that same office, it’s not the same. After they have an office, a place to sit, they can make it their own, its much more comfortable and productive than just sitting down and working. People code differently - your desire to watch them code could be putting them in a situation where you’re getting their worst work, not their best.

Also, people execute the mechanisms of code differently. Do you care how they code, or do you care that the product is done, follows good design patterns and is on time and accurate? That’s how you should measure, then. Instead, let’s say you’re watching a candidate type and they keep making lots of typos. They correct them, but the damage is done. In your head, you’re seeing someone who makes mistakes and isn’t detail oriented. I’d say that you’re wrong, this person just works differently. For example, I’ve worked with people who type accurately and slowly. I tend to type swiftly, but have to beat the crap out of that backspace key (I have a very strong pinky finger). If the end product is good, does it really matter how they get there? I’d say it does in a macro sense, but during the interview, you’re going to get stuck on the micro sense. Don’t do it.

What to Do Instead?

One of the solutions that I’ve seen (and implemented) is a “take-home” code challenge. That’s a great solution, but it’s also ripe with pitfalls. First, how much time will the code challenge take? What if they’re applying three places? What if they shared the code between code challenges? How do you make sure they didn’t cheat? Point is, there are a lot of pitfalls in this. However, you do get to learn a lot about how they code and what their output will be.

The best solution I think, though, is to do an interactive pull request review or code walkthrough. Find a piece of code and pull it up and screenshare with the candidate. Ask them to give you real-time feedback. It’s best if this code isn’t written by you or any of your team. That way, they’ll feel free to give more honest feedback.

With this mechanism, you’re learning a lot about them. First, you get an idea what’s important to them when they review code. The fact that they review code in that manner probably means they feel strongly about writing code in that way, too. (No one ever says I can’t stand typos in comments in other’s code, but its ok in mine.) Second, you get to see how much they’ll dig in. The questions they ask, the way they think out loud, gives you an idea of to what level they analyze code. A junior, mid and senior developer will have different ways that they review the code. Finally, this is an open conversation. If the review is too short, you can find another piece of code. Or, you can cut it short if it goes too long. This time investment is in real time, so it can seem “scary” - but the more time invested by you gives you a better idea of that candidate’s quality. And for them, its probably less time invested than a coding challenge would be. Plus, since they’ve not had to write it, it should be much less stressful.

End Notes

I’m very much against interactive coding challenges. It took me a while to get past my frustration and anger at this - because it’s not an accurate measurement of skill and productivity - and boil down into a good entry. I wanted to make sure that, instead of just complaining, I have a solution. I think the solution is an interactive code review. If you really have doubts still, you could follow up with a code challenge. But, whatever you do, don’t try to stress people out on purpose. It serves neither of you.