How to Run a Technical Interview That Predicts Performance

Most technical interviews measure the wrong thing. They test whether a candidate can recall an algorithm under pressure with someone watching — a situation that resembles almost no real engineering job. If you want a technical interview that predicts performance, you have to test work that looks like the work.

This is how to design one, and the traps that quietly tank your signal.

Start from the actual job

Before writing a single question, list the three or four things this person will spend most of their time doing. Debugging unfamiliar code? Designing an API? Reviewing pull requests? Your interview should sample those activities directly. A test that has nothing to do with daily work cannot predict daily work, no matter how clever it is.

Prefer realistic tasks over puzzles

The strongest signal comes from tasks that mirror reality:

• Debug a small broken program. Hand them code with a real bug and watch how they diagnose it. This is what the job is.
• Extend existing code. Add a feature to a small codebase. Reading and modifying others' code is most of engineering.
• Review a pull request. Ask what they would comment on. It reveals judgement, not just syntax.
• Design discussion. Talk through a system at a level appropriate to the role. Probe trade-offs, not memorised patterns.

Notice what is absent: no obscure algorithm puzzles, no whiteboard trivia. Those select for people who recently studied for interviews, not people who ship.

Make it collaborative, not adversarial

Let candidates use documentation, ask questions, and think out loud. You are simulating a workday, and on a normal workday people look things up. Watching how someone uses help, recovers from a wrong turn, and communicates while doing it tells you far more than whether they froze under silent scrutiny.

You are not testing whether they can perform without resources. You are testing whether they do good work with the resources a real job gives them.

Score it like everything else: structured

Define what you are measuring before the interview and rate against anchors:

1. Correctness — did they solve the actual problem?
2. Approach — was the process methodical or flailing?
3. Communication — could they explain their reasoning?
4. Code quality — readable, sensible, maintainable?

Write each score down during the session, before discussing with anyone. Independent ratings beat a debrief shaped by whoever speaks first.

Common traps

Three failures recur. The first is time pressure that tests panic tolerance rather than skill — give enough room to think. The second is the one-question gamble, where a single hard puzzle decides everything and a strong engineer who has not seen that exact trick fails. The third is letting the interview drift into trivia because it is easy to grade; easy to grade and predictive are rarely the same thing.

Aim the interview where the gaps are

Generic technical interviews waste time covering ground a resume already settled. Talent Tick scores each candidate against a transparent rubric and generates personalised questions — five theory and five coding — pointed at each person's specific gaps, so your technical round digs exactly where the uncertainty is instead of re-confirming the obvious. The scoring is deterministic and explained in plain English, so you always know why a candidate ranked where they did. Start a free 21-day trial and make your next technical interview earn its hour.