A couple of days before I’m writing this, a post from a “senior” engineer came across my feed in twitter. In it, he was talking about an interview he gave less than 24 hours before, and about how the candidate couldn’t figure out how to close a tag in markup after he told the candidate that they weren’t allowed to use a library that they were going to leverage.

He used this as an argument for “this is why we need interviews. ‘Senior’ developers can’t even use markup properly” (paraphrase).

Thankfully, the people that I follow who were responding to this were taking this person to task for his behavior, though far too many people in the thread were jumping to his defense.

Let’s get the obvious (to me, at least) part of this out of the way – there is no way that I would want to work with/for a person that might drag me in public after I interview with them. That’s a huge red flag and I think the candidate dodged a bullet there.

Now that I’ve gotten the “Don’t be a shite person” thing covered, I’d like to talk about why coding interviews aren’t a good indicator of a candidate’s abilities.

The ability to interview well and to actually do the job are two distinct skillsets and have very little to do with each other. Daily work (in theory, at least) is a relatively psychologically safe situation in which you are able to leverage your knowledge, skills, and ability to learn in order to solve problems. An interview is a contrived stress test largely designed as a hazing ritual to make the interviewer feel smart and/or superior.

I say this as someone who interviews people regularly and tries to break this cycle.

My daily work involves spending time thinking about problems, looking things up, asking people questions and writing short, experimental pieces of code under test to fulfil the use cases that are going to provide value to a business.

In a live-coding interview, I’m going to have a problem dropped in my lap with no time to think about it, with a development environment that I haven’t customized (or worse, a whiteboard), while being watched and judged by people that I don’t know and don’t feel safe around so that I can “prove” that I am “worthy” to work with them.

Anybody see a difference here?

Work is filled with considered, largely unpressured choices. The interview is filled with snap decisions about a thing I have not had time to think about in a hostile environment (and don’t pretend that live coding interviews aren’t a hostile environment. You’re putting someone’s livelihood on the line. The list of things more hostile than that is fairly short).

That’s not getting to know someone and their abilities. That’s an unnecessary stress-test. And it’s especially going to work against people in marginalized communities – everything from BIPOC to people with PTSD to people with autism and countless others.

It’s not due diligence. It’s needless cruelty. (And I can speak as a Native person who has PTSD. Interviews as most people conduct them suck and make me want to crawl under a rock).

Want to know another secret? I’ve been writing code professionally for about 20 years now and it’s generally agreed upon that I do, in fact, know what I’m doing (most of the time). That said, I make plenty of stupid mistakes even when I’m not under pressure. We all do and we need to admit it.

I can’t tell you the number of times that I’ve forgotten to initialize a List<T> and then spent time trying to figure out why the code blows up when I do something with that list. Granted, TDD and improved IDE tooling have helped me spot those mistakes faster now, but they still happen.

John Peel may have been able to say “I never make stupid mistakes – only very, very clever ones” but I’ll tell you here and now that I am quite capable of making stupid mistakes. Sometimes I’ll cringe at them in the moment, but I’ve gotten better about laughing instead (which is something that an actual senior developer should be able to do, in my opinion).

If I, a senior+ developer (my current title is Architect), make mistakes like this in a no pressure environment, imagine what live coding in a high-pressure situation is like. Now ask yourself what that situation is like for someone with less experience or who has experienced more trauma than I have.

Don’t do that to people. Just don’t. There are better ways to figure out if someone is a good fit for your team.

And for the love of everything decent, even if you are still giving live-coding interviews (for whatever reason), don’t publicly drag the person the next day. I don’t care how bad you thought they did from a technical standpoint.

For the people out there who are being interviewed – if you see your interviewer speak badly about other candidates (or, even worse, if they do it in the interview – and I’ve been in a few of those as a candidate), consider if you want to be exposed to this on a daily basis.

Provided that you are able to cover your bills, you have options and you should be someplace where you can grow and thrive. If you can’t cover your bills and need the job, take it and keep looking. The saner people and companies will understand.