Technical interviewing is broken. We all know it. As interviewers, we frequently pass on candidates who end up excelling elsewhere. As candidates, we spend demeaning hours trying to solve brain-teaser data structure traversal problems on whiteboards, and then don’t get an offer.

This is so bad that there are libraries full of books dedicated to how to pass a programming interview. There’s that thick green one, ‘Cracking the Coding Interview,’ which I worked through last summer. A candidate brought that in his backpack, actually, and it came up in conversation with one of the other interviewers… who was horrified that that’s how things are. “Do you study for an interview in any other job? You think the sales guys go home and memorize the stuff from college? No! You just talk about the things you did at the last job!”

Honestly, it seems much of the time like we’re not so much trying to determine whether the candidate is going to be able to perform the job duties correctly (which is the goal of a technical interview) but rather to show off our own prowess in choosing a clever interview problem, the hope being that if the candidate can’t solve the question they’ll be impressed with how we the interviewers are such sorcerers of code that we’re able to traverse a Luxembourg-Schnauzer tree in log(sqrt(log(n))), and that if they can solve the problem they’ll respect us for the low-grade telepathic exchange that’s just taken place.

Now it’s supremely important that we filter out candidates who can’t code from a software development position. If you hire a non-FizzBuzz developer, you’re doing neither the developer nor your firm any favors; the ultimate frustration and non-productivity will not be worth the temporary social kindness of receiving the job offer.

Depending on the nature of the role, it’s also important that we filter out candidates who can program successfully in a competitive programming setting but can’t bootstrap the understanding of our tech stack. If the role requires a deep understanding of the Spring framework for dependency injection, or a whole lot of ORM work, or immediate productivity with Angular 5, whether the candidate could successfully navigate your favorite whiteboard question is almost totally irrelevant.

But how can we test for that in a timely fashion? We can’t rely on spinning the candidate up to fix a bug on our production system, because we’re not guaranteed to have a suitable bug (or a suitably small feature) that we could reasonably expect them to fix in a day, and we can’t necessarily spin them up on the development environment either. We can’t give them a take-home problem, because developers have better things to do with their time, like finding another job and getting paid.

If it was entirely up to the employer, we’d contract-to-hire all the time; let the engineer work with us for 3 months, and if it doesn’t work out, no harm and no foul. That’s not ideal for us as candidates, though, because we might end up building some really great software with no job or equity to show for it at the end of the contract.

In any case, I think this is broken to the point of being stupid. The interview process is a hazing ritual and it allows the employees (who explicitly passed or implicitly would have passed) to be members of an exclusive in-group, and we get to regularly torment total strangers and see some objective proof that we are smarter than they are.

But I also think that this is okay!

“Now wait just a minute, Kaiser, you’re okay with tormenting strangers?”

-you, probably

YES! I am okay with tormenting strangers. I am okay with hypothetically being a tormented stranger again in the future – with enduring back-to-back interviews on consecutive days in which interchangeable 24-year-olds in hoodies asks me about function currying in JavaScript and silently judge my hairline.

I’m okay with this for one reason: If you endure enough interviews with 90% false negative rates, eventually, you will pass one.

In smaller markets, this means that we as candidates might have to move for work. That’s emotionally and financially draining. It’s also one of the best ways we can undergo personal growth.

Furthermore, there’s not really an alternative. Employers can’t pull the rug out from under the engineers in your organization and say “no, this interview process which we used to select you was fundamentally flawed, we are going to be kinder and gentler to the new hires,” because then they don’t get to ask the cool Schnauzer tree question any more and that’s demoralizing. Furthermore, there might not actually be an alternative to whiteboarding (or the equivalent of whiteboarding, but with a laptop), because otherwise somebody probably would have figured it out and we’d all be doing it out of economic necessity.

So yeah, interviewing is broken. And it will be for the foreseeable future.

Do you have a better idea?