18 November 20258 min read
Most technical interviews were designed for a room with a whiteboard and were never redesigned when they moved to video. The result is a format that now tests two things at once: whether the candidate can solve the problem, and whether they can solve it while talking to a slightly delayed video feed of a stranger who is silently taking notes. Only one of those is part of the job.
The fix is not to lower the bar. It is to test the thing you actually need, in the medium the work will happen in.
Test the work, not the recall
The most predictive format is dull to describe: a small change to real code, made live, with the candidate using their own editor, their own search habits and their usual tools. Forty-five minutes, one bounded task, in a codebase they have never seen.
It is predictive because it is the job. Every remote engagement begins with someone unfamiliar opening an unfamiliar repository and having to become useful in it. That is the skill. Reciting an algorithm from memory is not, and it never was, but the pretence was easier to maintain in person.
How to prepare the exercise
Take a small open-source project or a stripped-down copy of your own, with the sensitive parts removed. Prepare one task that a competent person can finish in half an hour and one extension they will not reach, so nobody sits in silence at the end and strong candidates still have somewhere to go.
- Send the repository fifteen minutes before, so setup problems do not eat the interview
- Say explicitly that searching the web and using their usual assistant tooling is allowed, then hold to it
- Make the task change existing behaviour rather than write something from nothing; reading is most of the job
- Have a working solution yourself, so you know what the traps actually are
What to watch while they work
The output matters less than the route to it. Watch for how they orient in an unfamiliar codebase: do they read before typing, do they find the relevant file by structure or by flailing search, do they run the thing to see what it does now.
Then watch what happens at the first surprise, because there will be one. Strong candidates narrate it, form a hypothesis and check it. Weaker ones change something and re-run, repeatedly, without a theory. That difference is visible to a non-specialist observer and it is one of the more durable signals available in an hour.
The debugging half-hour
If you only have time for one exercise, consider making it debugging rather than building. Hand them a failing test or a reproducible bug and watch them close in on it.
Debugging is harder to prepare for, closer to the median day of real work, and much less sensitive to which frameworks someone happens to have used. It is also the fairest exercise across educational backgrounds, which matters when you are hiring internationally and CVs are not comparable.
Take-home tests, and when they are defensible
Take-homes give quiet, careful people a fair showing and remove the video-call performance tax. They also cost the candidate unpaid evenings, and a long one filters for people with free evenings rather than people who are good.
A defensible take-home is capped at about two hours, stated in the instructions and meant honestly; is not a piece of work you would otherwise pay for; and is followed by a short call where they walk through what they built and what they would change. That call is the important half. It makes outsourced or borrowed submissions obvious, and it is where you learn what they were thinking.
The design conversation
For anyone senior, add twenty-five minutes on a system they have not seen: describe a real problem you have, and talk it through as colleagues. Ask what they would need to know before choosing, what they would build first, and what they would deliberately leave crude.
You are testing whether they design for constraints or from habit. Watch for someone who asks about scale, team size and deadline before proposing an architecture, and be wary of a confident answer that would suit a company a hundred times your size.
Scoring it without pretending it is a measurement
Write down before the loop what you need this person to be able to do, in four or five plain statements, and score against those. Elaborate rubrics create a false impression of precision; no rubric at all means the last interview wins the argument because it is freshest.
Insist on written notes from each interviewer before the debrief rather than during it. Live consensus conversations converge on the most confident voice, which in a remote setting is usually whoever has the best connection.
Adjust for the time zone, not the standard
Schedule inside the shared working day rather than at the edges of it. A candidate interviewing at nine in the evening after a full day is being tested on stamina. With Beirut an hour or two ahead of most of Western Europe, there is no excuse for an inconvenient slot, and a provider proposing one should be asked why.
Beyond that, do not soften the bar for distance. The whole argument for hiring across a border is that the work is the same standard at a different cost, and every concession you make in the interview is one you will spend twice over later.