Practical interviewing guide
How to run a code review interview
A code review interview asks a candidate to inspect a prepared pull request, leave review comments, and discuss their reasoning. It tests how someone reads and judges unfamiliar code—not how quickly they can produce code from a blank editor.
01 · Start with intent
What a code review interview measures
Reviewing a pull request combines code comprehension, technical judgment, prioritization, and communication. The candidate has to build a mental model of code they did not write, decide which problems matter, and explain feedback another engineer could act on.
Useful signals
- understanding unfamiliar code and its surrounding assumptions;
- finding correctness, security, reliability, and maintainability risks;
- separating blockers from suggestions and stylistic preferences;
- asking for missing context instead of inventing certainty;
- explaining trade-offs and offering constructive alternatives.
Signals it does not replace
- the ability to design and implement a complete change;
- hands-on debugging in a running environment;
- deep system design for senior architecture roles;
- team history, delivery habits, or long-term ownership.
Treat the review as one structured source of evidence. It is strongest when the role genuinely involves reading other people's code and giving feedback.
02 · Build the exercise
Choose a small, realistic pull request
The best code review exercise looks like work the candidate might encounter after joining. It should be understandable without private company knowledge and rich enough to support a discussion beyond spotting syntax errors.
| Prefer | Avoid |
|---|---|
| A focused change with roughly 80–250 changed lines | A whole repository or an enormous feature branch |
| One clear business goal and enough surrounding context | Trivia that depends on an obscure framework detail |
| Two or three meaningful risks at different depths | Twenty planted mistakes competing for attention |
| Some correct code, reasonable trade-offs, and ambiguity | A caricature where every line is obviously broken |
A git patch contains only changed lines and their configured context. Generate it with
more context when the exercise requires nearby code—for example, git diff -U10.
03 · Decide before meeting
Write the findings and rubric first
Do not decide what counted only after hearing the candidate. Before the first interview, document the expected findings, why each matters, acceptable alternatives, and how much weight each deserves.
-
1
Rank by impact
A correctness or security defect should normally outweigh naming and formatting.
-
2
Describe the evidence
Record what observable behavior demonstrates understanding, not a secret phrase the candidate must guess.
-
3
Allow sound disagreement
Give credit for a defensible trade-off even when it differs from the author's preferred fix.
Keep private interviewer notes beside the relevant lines. Good notes explain when to wait, when to offer context, and which follow-up question reveals depth without giving away the answer.
04 · Let them review
A practical 60-minute interview plan
Set expectations
Explain the fictional change, what context is available, and that prioritization and reasoning matter more than finding every planted issue.
Independent review
Let the candidate navigate and comment. Answer genuine context questions, but avoid steering them through the files or telegraphing findings.
Discuss the review
Ask the candidate to rank their concerns, explain likely consequences, and compare possible fixes. Explore one important finding in depth.
Candidate questions and close
Leave real time for questions. Complete the rubric immediately afterward while the evidence is fresh.
05 · Score evidence
Evaluate consistently without automating judgment
A numeric rubric supports consistency; it should not pretend that interviewing is a fully objective calculation. Record what the candidate noticed, how they explained it, and how they responded when new context changed the problem.
- Use the same exercise, instructions, timebox, and core follow-ups for comparable roles.
- Score observable review behavior rather than confidence, speed of speech, or familiarity with your internal style.
- Do not award full credit for naming a category without explaining the concrete risk in this change.
- Do award credit for valid findings you did not anticipate; improve the rubric after the interview cycle, not midway through one candidate's score.
- Keep written evidence with the decision so the hiring panel can distinguish signal from impression.
06 · Know the boundary
When this format is inappropriate
Do not use a pull request interview merely because it feels more realistic than live coding. Skip it when code review is peripheral to the role, when the exercise depends on undocumented domain knowledge, or when you actually need evidence of implementation, debugging, or system-design skill.
It is also a poor choice when interviewers cannot agree on the important findings in advance. Fix the exercise before asking candidates to absorb that inconsistency.
See the complete exercise
From pull request to scoring rubric
Walk through a sanitized Flask example with its planted risks, interviewer prompts, expected findings, and an 11-point rubric.