Are coding interviews necessary?

Hiring good software developers is hard. Getting them to apply to your job listings is hard. Getting them to agree to an interview is hard. And of course, once you interview them, deciding if they are worth an offer is hardest of all. Can they write good code? Do they even know the programming languages that they claim to know? What is their experience level really? And it’s not just about the code—developers also have to communicate well and keep up with an ever-changing ecosystem. That’s all hard to measure in a few short interviews.

And the stakes are high. Making a mistake and hiring the wrong person can be costly, both in terms of lost time and in terms of poor code quality.

One of the ways many organizations attempt to answer these challenging hiring questions is by having candidates code during interviews. A lot of ink has been spilled over whether this is a good idea, and I am about to spill some more.

The stress test

The first attempts at having candidates code were right there in the interview on a whiteboard. You’d give the developer a mind puzzle: “Write a routine to reverse a linked list” or “Do a binary search in a sorted array.” The big tech companies became so famous for asking these questions that websites popped up to help candidates learn how to solve these problems. Places like LeetCode and AlgoExpert have dozens of such questions to practice on.

The temptation is strong to create more creative and challenging puzzles, but it can also create a culture of trying to create “gotcha” moments that aren’t fair to the candidates.  Developers don’t write code on whiteboards—they use IDEs. The awkwardness of coding with a dry-erase marker gave way to doing so on a shared screen with development tools, but even taking that step often results in pressure that leads to inscrutable results.

I’ve done a lot of whiteboard coding interviews, and I came to be very unsatisfied with the results. In my experience, it is hit or miss. Some candidates do well, and some struggle.  Generally, I found that being a good whiteboard coder was a good sign. After all, being able to think on your feet and under pressure is a valuable skill.

At the same time, I suspected that floundering on such a test didn’t mean the developer wasn’t skilled. I’m sure that I passed on some good candidates because they didn’t do well on a “gotcha” problem at the whiteboard. Plus, if your interview process feels like a snare waiting to trap a candidate, what message does that actually send?

Not all good coders can think well on their feet. I’m not even sure that “thinking fast under pressure” is a skill that should be filtered for. “Delivers an excellent solution after methodically tackling the problem” is a vastly better trait in a developer, no?

The take-home test

We then started giving candidates a take-home test. The problems became a bit deeper and wider: “Build a simple traffic light system” or “Create a simple meme generator.” The idea is to have the developer put a bit more time and effort into the project, including basic design skills. The candidate would then return with a solution, demoing their program and explaining the code. 

I like this method a whole lot better. It is a much better simulation of how a developer actually works. In the real world, we don’t ask developers to knock out solutions off the top of their heads. We want them to research and ruminate on a problem and toss around solutions in order to arrive at the correct design. Giving a developer a week or so to work on a problem is a much better measure of their capabilities.

Now, the objection I hear to the notion of a take-home test is that they’ll just “Google a solution or get AI to solve the problem for them.” To this, my response is “Okay, that sounds fine to me.” I don’t care how a developer arrives at a solution; I just care that they are able to. I’m less concerned about the origin of the code and vastly more interested in how the candidate takes ownership of the code. If the code they present to the coding challenge is well-written and includes unit tests, and they can explain what it does and how it works, why would I care how they came up with the code?

Shoot, if you aren’t using AI these days, then you are falling behind. I want my development team using every tool in the tool belt to get the job done quickly and correctly. I’d look askance at a developer who didn’t use AI and other resources to solve a take-home coding project. The success of a candidate depends not on how they completed the project, but on their ability to present and explain a solution to the problem they were given. If they can do that, why do you care how they arrived at the solution?

The interview process should answer the question, “Can this candidate do the job we need them to do?” If they deliver clean, working code that meets requirements, and they can communicate their thinking and adapt their solution as needed, who cares how they got there? That’s the developer you want on your team.