Welcome to our tech interview

comments

I constantly meet interviewers wondering why so many programmers, including experienced ones, fail even the simplest coding tests. But it’s not programmers that fail the tests. It’s tests fail programmers. This is how it usually happens:

Welcome to our technical interview!

As part of our assessment process, we give candidates a stupid simple coding test. Here it is. (hands you a sheet of paper).

Your coding challenge.

“… It’s so simple that every good programmer should be able to complete it. Don’t worry. You’re allowed to ask questions, use Google and IDE of your choice. John, Bob, Sergey, and Gleb just want to see how you approach problem solving. We’ll be watching you from the back. No pressure.”

A senior developer and four juniors are watching you writing code.

In theory, all good programmers should do well. Those who failed a simple task are bad programmers. But…

Due to basic psychology, even the best programmers often have difficulties with the simplest coding tasks. Not at work. But in a specially crafted “test” environments. Such test environment are very different from production environment because:

1️⃣ You’re locked in a meeting room surrounded by a group of strangers.

2️⃣ You’re on foreign territory.

3️⃣ You know you’re going to be observed and assessed.

If you’re party animal, you’ll be fine. But most engineers are not like that.

That causes stress.

📈 The level of stress hormones in your blood increases. Excessive adrenaline and cortisol turn on fight-or-flight mode, which, in turn, awakens and intensifies your reactive thinking (System I) and shuts down your analytical thinking (System II). In other words, you become dumb. Much dumber than you normally are at work. Without even acknowledging it.

And start making stupid mistakes everywhere. Even in areas you’re exceptionally good at.

“… Okay, it looks like things aren’t going so smoothly for you. That’s unexpected. You said you like pair programming and working in a team. But don’t worry, you still have a chance. We have another exercise for people like you. If you can’t work in a team, you should at least know how to invert a binary tree…”

Inverted binary tree.

But that’s too late. The point of no return has been reached. A self-reinforcing “dumbification” loop has been set in motion, fueled by your own awareness that you are failing.

Only after you get few miles away from the “predator territory”, do you begin to recover and the process reverses: stress level goes down and hormones get back to normal. Suddenly, you become smarter, think clearer, memory improves, you can code like a pro, and the world belongs to you. Unfortunately, that happens only after the interviewers have made wrong conclusions about your performance, you got a blow to your self-confidence, and both sides wasted hours of precious time.

Conclusion

If you want to assess someone’s coding skills, you should let that person code in a safe environment. The required degree of safety varies depending on our individual differences. For the vast majority of engineers, coding in their comfy home office, when Big Brother is not watching, is the best way to show off their skills. Therefore a well-crafted homework – not too hard yet not overly simplistic – is probably the most effective and inclusive of all testing approaches.

💡 Few remarks about a homework:

You may also consider personalizing the process and ask people what they prefer: a homework assignment, pair programming, or something else. Such personalization gives people with different needs and life circumstances equal opportunity to show their best.

But, most importantly, you should constantly ask candidates what they like and dislike about your process, and integrate that feedback back into your process. Winning the battle for the best talent is not that difficult. Just listen carefully to what the talent says.

Thank you.

🚀 P.S. if you want to improve and accelerate your hiring process, join my upcoming Principal Dev masterclass.