Interviewing a developer by having them review code
Reading a candidate's public code is a weak signal and worth saying so plainly. Most professional work is private, side projects are written without constraints or reviewers, and a contribution graph mostly measures free time. The format that does work runs the other way: give the candidate a real pull request from your own codebase and read what they say about it. Reviewing is harder to fake than writing, because a review exposes what someone notices.
Why is a candidate's public code a weak signal?
Because the constraints that produce good professional code are absent from it. Side projects have no deadline, no legacy, no reviewer and no consequences, so they show what someone does with total freedom rather than what they do inside your situation. Both are interesting; only one predicts the job.
Open source contributions carry a second distortion. Meaningful contribution requires spare time and a tolerant employer, so it selects heavily on circumstance. Excellent developers with caring responsibilities have nothing to show, and treating that as a gap is both unfair and inaccurate.
There is one exception worth keeping: a candidate's own code becomes useful when they walk you through it and answer why questions. At that point you are assessing their reasoning rather than the artefact, which is the thing that transfers.
What does reviewing reveal that writing does not?
What the person notices without being told to look. Writing code shows you their habits inside a problem they control; reviewing shows you their attention inside somebody else's, which is most of the actual job on any existing product.
It also exposes calibration. A review is a set of judgements about what is worth mentioning, and the ratio of significant comments to trivial ones tells you whether someone can distinguish a naming preference from a data loss risk. That distinction is the difference between a reviewer who improves a team and one who slows it down.
Finally it shows tone under mild social pressure. The candidate is commenting on code written by someone who might be in the room, and how they phrase a disagreement in that situation is exactly how they will phrase it in month three.
What should you have them review?
A real pull request from your own product, between roughly two hundred and four hundred lines, that was merged and later turned out to have a problem. Real is important: synthetic exercises with planted bugs have a tidiness that experienced candidates recognise, and they start looking for the trick rather than reading the code.
Include enough surrounding context that the code can be judged. A diff alone is not reviewable, so give them the ticket it came from, access to browse the repository, and permission to ask you questions as though you were the author.
Then tell them the honest framing: you want to know what they would say to a colleague, not what they can find. Candidates who believe they are being scored on defects found will produce a long list of trivia, which measures your instructions rather than their judgement.
What separates a strong review from a weak one?
The categories of comment, and the order they arrive in. A strong reviewer opens with whether the change does what the ticket asked, then moves to consequences, then to details, and says so explicitly. A weak reviewer starts at the details because that is what is visible without understanding.
| Comment type | Weak version | Strong version | What it tells you |
|---|---|---|---|
| Correctness | Silent, or repeats the code back | Names a specific input that produces the wrong result | Whether they can hold the code in their head |
| Failure handling | Add error handling | Asks what happens if this call times out halfway | Whether they have operated something in production |
| Data and migrations | Ignored entirely | Notes the change is not backwards compatible during deploy | Experience of releasing without downtime |
| Style | Many comments, first | Few, last, flagged as optional | Calibration, and whether they will slow the team |
| Questions to the author | None, or rhetorical | Specific, answerable, and genuinely uncertain | How they behave in disagreement |
| Scope | Suggests a rewrite | Separates what to fix now from what to note | Judgement about shipping |
What does this format miss?
Whether they can build. Reviewing is a reading skill, and a small number of people read code far better than they write it. If this is your only technical session you will occasionally hire someone who describes excellent work and produces average work, so pair it with something where they type.
It also misses stamina and independence. A forty-five minute review says nothing about what someone does across three weeks of unglamorous work, which is why references and a real conversation about their last project remain worth the time.
And it advantages candidates who have worked somewhere with a genuine review culture. That is a legitimate thing to select for, but be aware of it: a strong developer from a team that never reviewed will underperform in this format for reasons unconnected to their ability.
How do you run it in forty-five minutes?
Send the pull request and the ticket twenty minutes before the call and say plainly that you expect them to have read it. Then spend the session talking rather than reading, which doubles the useful time and removes the awkwardness of watching someone scroll.
Open by asking whether they would approve it, and require an answer before any detail. That single question forces a judgement rather than a list, and everything after it becomes an explanation of the judgement, which is what you want to hear.
Close by telling them what actually went wrong with the change in production and asking whether they would have caught it. The good answers here are often no, followed by a precise account of what would have caught it, and that answer is worth more than a lucky guess.
Common questions
- Is a developer's GitHub profile useful for hiring?
- Weakly. Most professional work is private, side projects are written without deadlines, legacy or reviewers, and a contribution graph largely measures spare time and employer tolerance. That selects on circumstance rather than ability. Public code becomes useful only when the candidate walks you through it and answers why questions, at which point you are assessing reasoning rather than the artefact.
- How do you interview a developer using code review?
- Give them a real pull request from your own product, roughly two hundred to four hundred lines, that was merged and later caused a problem. Send it with the ticket twenty minutes before the call. Ask first whether they would approve it and require an answer before any detail, so the session becomes an explanation of a judgement rather than a list of observations.
- What does a strong code review comment look like?
- It names a specific input that produces the wrong result, rather than restating the code. It asks what happens when a call times out halfway rather than saying add error handling. It notices whether a data change is safe during a rolling deploy. Style comments appear last, are few, and are marked as optional, which shows the reviewer can tell a naming preference from a data loss risk.
- Should you use a real pull request or a made-up one?
- A real one. Synthetic exercises with planted defects have a tidiness that experienced candidates recognise immediately, so they start hunting for the trick instead of reading the code as they would at work. A genuine merged change that later caused a problem produces honest behaviour, and it lets you close the session by saying what actually went wrong and asking whether they would have caught it.
- What does a code review interview fail to measure?
- Whether the candidate can build. Reviewing is a reading skill and some people read code better than they write it, so pair this format with a session where they type. It also misses stamina across unglamorous weeks, and it advantages candidates from teams with a real review culture, which means a capable developer from a team that never reviewed may underperform for reasons unrelated to ability.
