Hiring a backend engineer without asking them to invert a binary tree

I have never had to invert a binary tree in production. I have often had to understand why a query took eight seconds, and fix it without breaking everything else.

Those are two different skills. Only one of them predicts what happens once the person joins the team.

What an algorithm test actually measures

It measures preparation. Someone who spent three months on practice platforms will pass; someone who has maintained code for five years might not.

So the signal is inverted for a role where maintenance experience is precisely what you are looking for.

The exercise I use

A problem actually encountered, cut down to four hours. For example:

Here is an API exposing a list of invoices. It takes 8 seconds to respond in production on an account with 40,000 rows. The code, the schema and a dataset are provided. Find the cause, fix it, explain your reasoning.

What that reveals, and an algorithm does not:

• Does the person measure before changing, or do they guess?
• Do they look at the query execution plan?
• Do they fix the cause or add a cache on top?
• Do they write a test that fails before their fix?
• Can they say "I don't know, here is how I would find out"?

The last one matters most. A developer who bluffs in an interview will bluff in code review.

Four hours, paid

The exercise is capped and paid. Two reasons, neither of them moral.

First: an uncapped exercise favours those with free time. You then select on personal circumstances, not on skill.

Second: a paid exercise is one you can demand seriously. You do not ask for free work and then act surprised by a rushed submission.

The grid is written first

Before the role is published, I write down what will be assessed and how. Five criteria, each scored 0 to 3, with a description of what each level means.

Writing the grid after reading the submissions amounts to picking the person you preferred, then justifying it. That is exactly how you end up hiring people just like yourself.

Two reviewers, separately

Every submission is reviewed by two people who do not talk before scoring. When the scores differ by more than one point, the conversation that follows is the most useful part of the process: it reveals a disagreement about what the role actually needs.

The final question

I always end with the same one:

"Tell me about a technical decision you regret."

An honest answer describes a context, a trade-off and a consequence. An evasive answer — "I should have documented better" — signals either little experience or little perspective. Both matter.

What it costs

This process takes about six hours of my time per candidate reaching the final stage. That is expensive.

It is still cheaper than a failed hire, which costs three to six months between onboarding, realisation and separation — not counting what it does to the team.