Why Your Developer Interview Process Is Shit

The year 2026 marks my 20th anniversary as a Software Developer. I started in 2006 at a company called TechnoPhobia in Sheffield.

My interview process there was interesting, to say the least. I was hired from a set of 2nd-year university students because I was one of the nerdiest-looking ones. I don’t actually remember much about that interview other than being warned by my housemate at the time that they ask you to tell a joke as the final question.

The early 2000s were a different time, but we still haven’t really figured out how to interview Software Developers well 20 years later.

Here are some of the “greatest hits” from terrible interview experiences during my career.

The Interviewers Have Never Met

This happens in large organizations where the responsibility of interviewing is shared across many in the Engineering department. People are thrown into interviews often without any real idea of how to interview people. In one case, I was being interviewed by people who had never met before. There was no chemistry whatsoever, and it ended up being a very painful experience all around.

This should go without saying, but technical interviews should be conducted by people who have at least met each other. Interview training and coaching should also be provided. Developers are awkward; don’t make it worse.

You aren’t Google

You're not working on cutting-edge technology; you're merely promoting unwanted advertising. Or you’re eroding society with gambling.

Never in my 20-year career have I needed to bust out any algorithms. You aren’t offering a seven-figure salary, and you aren’t working on anything that requires that knowledge.

This is wasting everyone’s time. You know the job doesn’t need it. I know the job doesn’t need it. You get to feel smug about rejecting people and then have an interview process that is more likely to hire graduates than an engineer with 10+ years of actual experience.

Looking for Unicorns

Someone in a senior position may not realize that not everyone shares their experience or has solved the exact problem your company faces.

Interrogating past experience to try and align it with your current problem is nearly always futile. The situations aren’t the same, and the context cannot be explained quickly enough; the technical landscape changes.

This approach is a giant waste of time—you will reject everyone who didn’t come to the conclusion you think they should have.

Ask the question you want answered. Don’t hope the candidate figures out the point you’re trying to make. Let the candidate use their experience to answer the hypothetical situation or question. Then if you don’t agree, question those decisions and approaches, and provide context.

Vague Bullshit

It's great that you want to see how candidates tackle big problems. But this is a tough one; giving vague problem statements or huge problems to dig into in a 1-hour interview is a bad idea.

“You should have asked more questions” - Some interview feedback once upon a time.

These interviews are usually between 60 and 90 minutes. You spend 5 minutes messing about at the start, and you want to do the candidate question charade at the end. So we’re down to 45 - 75 minutes realistically.

When you’re opening with vague problem statements, I’m just hearing that

1. You don’t value my time

2. You are bad at interviewing

3. You think your problems are special

Get to the point. If you want to see how I would tackle a bigger problem, brief me ahead of time. Give me time to prepare and think about it. If you’re going to drop it on me during an interview, focus, and get to the problem you want solving—what bit do you actually care about?