How to run a technical interview that predicts real performance

Most technical interviews measure the wrong thing. They reward candidates who have recently grinded algorithm puzzles and punish strong engineers who happen to freeze on a whiteboard. The goal is not to find someone who can reverse a binary tree under pressure — it is to predict how someone will perform on your actual work.

Here is a framework we have found produces better signal and a better experience for both sides.

1. Prepare before the call

Walking in cold wastes the most expensive resource in hiring: everyone's time.

• Know what you are testing for. Pick two or three concrete competencies — say, breaking down an ambiguous problem, writing clear code, and reasoning about trade-offs. Write them down. Everything in the session should ladder up to one of them.
• Re-read the candidate's context. Their résumé, the role, the level. An interview calibrated to the level is fairer and more informative.
• Have the problem loaded and tested. Solve it yourself first. If you cannot finish it cleanly in the time you are giving the candidate, it is too big.

2. Choose a problem that mirrors real work

The single biggest lever on interview quality is the problem itself.

Prefer problems that resemble the work: parse a messy input, model a small domain, extend an existing function, debug something that is almost right. These surface the skills you actually hire for — decomposition, naming, handling edge cases — instead of memorised tricks.

Avoid puzzles with a single "aha" insight the candidate either has or does not. They convert your interview into a coin flip.

3. Structure the session

A loose 45-minute round tends to fall apart in the last ten minutes. Timebox it:

1. First 5 minutes — put them at ease. Explain the format, that they can ask questions, look things up, and think out loud. A calmer candidate shows you more.
2. 5 minutes — frame the problem. Let them ask clarifying questions. How they scope an ambiguous prompt is itself signal.
3. 25 minutes — build together. Let them drive. Nudge when they are stuck; do not grab the keyboard.
4. 10 minutes — extend and discuss. Add a follow-up constraint, talk trade-offs, and leave time for their questions.

4. Read signal, not syntax

You are watching a process, not grading a final answer. Strong signals:

• They restate the problem and check assumptions before coding.
• They start simple, get something working, then improve it.
• They notice their own bugs and reason about edge cases unprompted.
• They communicate what they are doing and why.

Do not over-index on a forgotten standard-library method or a small syntax slip. On the job they would have a language server, documentation, and thirty seconds to look it up.

5. Reduce bias

Structure is the best debiasing tool there is.

• Ask every candidate for a level the same core questions, so you are comparing like with like.
• Score against a rubric written before the interview, not a gut feeling after it.
• Separate observation from judgement. Note what happened during the session; decide what it means afterward, ideally alongside other interviewers' notes.

6. Ask follow-ups that reveal depth

Follow-ups are where a good interview earns its keep. Instead of moving on when something works, go one layer deeper:

• "What breaks if the input is ten million rows?"
• "How would you test this?"
• "What would you change if this had to run concurrently?"

You learn far more from how someone reasons about their own solution than from whether they reached it.

7. Wrap up and score consistently

Leave real time for the candidate's questions — they are evaluating you too, and it is often the deciding factor for the people you most want to hire. Then, while it is fresh, write up your notes against the rubric and give a clear recommendation. Vague notes a day later are worse than no notes.

Make the mechanics disappear

The best interviews are the ones where the tooling gets out of the way — the candidate joins in one click, you both work in the same room, and you are free to focus on the conversation instead of screen-sharing and setup. That is exactly what Pairlyx is built for.