The technical interview questions that actually predict performance

We run technical assessments for our own hiring and for client placements, which gives us an unusually direct feedback loop: we find out twelve months later whether the person we recommended is still there and how they are regarded. That loop has quietly killed several interview formats we used to believe in.

What stopped correlating

Algorithmic puzzle performance. It predicts how recently someone practised algorithmic puzzles. Framework trivia is worse — it selects for whoever last read the changelog. Whiteboard system design in isolation is the most seductive failure: it produces confident, articulate diagrams from people who have never had to operate what they drew.

What holds up

A broken system with a real stack trace. Give a candidate a small service that fails under a specific condition, access to logs, and forty minutes. You learn how they form a hypothesis, whether they read error output carefully or skim it, and — the strongest signal we have found — whether they narrow the search space or start changing things.

• Debugging with incomplete information (strongest single predictor)
• Code review of a deliberately flawed pull request
• A design conversation about a system they actually built, pushed until it breaks
• "Tell me about a technical decision you got wrong and what it cost"

The wrong-decision question

That last one does more work than any other question in our loop. Genuinely senior engineers answer it immediately, in specific detail, with the cost quantified and no defensiveness. People with senior titles and mid-level judgement either cannot produce an example or produce one where the mistake was someone else's. It is not a gotcha — it is a direct measure of whether someone has run their own decisions long enough to see them play out.

Keep the loop short

Four hours total, three touchpoints, a decision within five working days. Beyond that you are not gathering signal, you are losing candidates — and in our data, the ones you lose to a slow process are disproportionately the ones you most wanted.