Russian Roulette of Technical Interviews
Illustration by Anna Golde from Ouch!

Russian Roulette of Technical Interviews

What's wrong with the tech world regarding technical interviews.


I've conducted hundreds of technical interviews, been working as a developer since 2007, I was lucky enough to be part of so many interview processes. In all honesty, nowadays going into a technical interview feels like you're playing Russian Roulette.

I'll be using a fake name for a company so it's easier to talk about it, picking Lemon Co.

One major subject I would like to approach is the fact that most tech interviews have nothing to do with what you'll be doing on a regular day while working for Lemon Co. Especially when you apply for a Vue role but the code challenge is about PHP.


I completely understand when Lemon sends you a take-home code challenge, totally fine, it's part of the process, although most of those challenges are either to write JavaScript functions, that the only purpose is to then roast you during the third phase of the interview, or even worse, they'll don't even talk about the code challenge, they'll just throw another challenge at you, a challenge that they already know the answer.

I've been there, I've created hundreds of these live code challenges, it's easy for me, I know the answer, I know how to deal with the solution, it's hard for a candidate, especially a person that doesn't perform well under pressure.

It hurts when it's too much

Another kind of code challenge is the ones where you almost need to create a full application, they want frontend, they want backend, they want a design, they want you to light some candles, make dinner, do the dishes and be in bed by 10 pm.

Companies out there, understand that a person spending more than 4 hours in a code challenge is way too much, to what end? To be rejected because a button has a 4 of border-radius instead of 6px?

Be specific

If you're sending code challenges to candidates be specific about what you want, candidates don't need to guess what's the output of a code challenge. If it's to 100% match a design, say it. It's to put the design aside and focus on functionality, say it. Want to focus on performance, say it.

Saying here's a code challenge and a design without any specifications, makes it hard for a candidate to score 100% on a code challenge.

I'll go a little deeper, if a candidate fails a code challenge, especially when it's design-related, cut them some slack, take into account they don't know how your company works, what's the process of design — code. They just don't.

What's the best approach?

In my honest opinion the best approach, both for the candidate and the company is to hire them on a 3—4 week basis, work with them, pay them, make sure they're a good fit for the company, make sure they learn how the company works.

Even if a company picks any other approach than this one, and you end up getting the job, I guarantee the first week will be learning processes, how the company approaches a design — code. Will you use Scrum, KanBan, etc;

Now, if a candidate you'll have to learn all of that in the first week or so when joining your company, why on earth do you expect them to know that already during an interview process?

This said, if you're looking for a job I wish you all the luck in the world, remember that most likely the decision is 99% out of your hands. Most of the time you just need to click with the person that's interviewing you.

Illustration by Maria Shukshina from Ouch!