In a code review interview, you get a pull request (often deliberately flawed). The interviewer asks what you would flag before you approve it. LeetCode has a single correct answer to submit. This round does not. The interviewer grades what you catch, what you miss, and how you explain it.
What interviewers grade
Most candidates put too much focus on style: naming, formatting, minor refactors. Interviewers mostly do not care about style. They listen for these items:
- Correctness under concurrency: race conditions, lost updates
- Idempotency: what occurs on a retry or a duplicate delivery
- Failure modes: what occurs when a downstream call times out
- Security: auth bypass, injection, data exposure
- Whether your comments are actionable, not only observations
Common code review interview questions
"Explain how you would review this PR."
Say your process aloud. First, read the diff for intent. Then follow the change through its failure paths. Then check the tests. Interviewers want to see a repeatable process, not a lucky catch.
"This function is not thread-safe. How would you flag it?"
Name the specific race (two requests that read and then write the same state). Do not only say "this could have concurrency issues." Then say what you would ask the author to change: a lock, an atomic operation, or a different data structure. Do not only say that it is wrong.
"How do you review code in a language that you do not know well?"
Say that you would focus on the language-agnostic parts of a review: control flow, error handling, edge cases, API contracts. Also say that you would want a second reviewer for idiom-specific concerns.
"What would you NOT block a PR for?"
This question is a trap for over-eager reviewers. The answer: style preferences, minor naming, and refactors unrelated to the change. Senior reviewers unblock fast. They leave non-blocking comments for the other items.
How to structure your review comments
Interviewers consistently reward comments with this structure:
- What is wrong, stated specifically (not "this looks risky")
- Why it is important: the concrete failure scenario
- What you would change, in one sentence
Compare two comments. The first: "This retry does not check idempotency. A duplicate request after a timeout will double-charge the customer. Add an idempotency key keyed on the request ID." The second: "retry logic looks risky." The first comment is better every time.
Worked example: a review of a real snippet
This small payment-retry function is the type of code that occurs in a real loop:
async function chargeCustomer(orderId, amount) {
try {
return await paymentGateway.charge(orderId, amount);
} catch (err) {
return await paymentGateway.charge(orderId, amount); // retry once
}
}A junior review stops at "there is no error handling if the retry also fails." That is true, but it is not the interesting bug. A senior review starts with the bug that costs money: the retry has no idempotency key. Sometimes the first call succeeds and only the response is lost (a timeout, a dropped connection). Then the retry double-charges the customer. The fix is not "add a try/catch." The fix is an idempotency key derived fromorderId, so that the gateway can dedupe the second call. This difference separates the levels below: you find the state-consistency bug, not only the visible bug.
How the bar increases by level
| Level | What the interviewer grades |
|---|---|
| Mid-level | Can you find the planted bug when the interviewer points to it or when it is fairly obvious? Examples: a null check, an off-by-one, an unhandled exception. |
| Senior | Do you find the non-obvious failure mode without a prompt, for example a race condition or a missing idempotency key? Do you explain the concrete consequence, not only that something "looks risky"? |
| Staff | Do you prioritize correctly across several issues? Do you decide what blocks the merge and what is a follow-up? Do you reason about blast radius: who else calls this code, and what breaks downstream? |
Practice with real, graded PRs
To read about code review questions helps only a little. The skill is pattern recognition under time pressure. Senior Loop's code review catalog has 15+ hand-written PRs across payments, distributed systems, and APIs. Each PR has planted, specific bugs. A rubric-based AI grader scores what you caught and what you missed. Three reviews are free, with no card required.
Frequently asked questions
The questions that candidates ask most often about code review interviews.
What is a code review interview?+−
In this round, you get a pull request or a code snippet, often with deliberately planted bugs. You review it as you do on the job: flag issues, explain why they are important, and say what you would change. A coding round asks you to write an algorithm from scratch. Here, you evaluate the code of a different engineer.
What do interviewers grade in a code review interview?+−
They grade correctness under concurrency and failure (races, retries, timeouts) and security (auth, injection, data exposure). They also grade whether your comments are specific and actionable, not vague. And they grade your judgment about which issues must block the merge and which are nits. Most candidates put too much focus on style and naming. Interviewers care least about those.
Is the bar different for senior candidates?+−
Yes. Junior loops mostly check whether you can find an obvious bug. Senior and staff loops also expect you to compare tradeoffs and to prioritize which issues block a merge. They also expect you to write feedback as a tech lead does. The leveling breakdown below shows the details.
How long does a code review interview usually take?+−
Most interviews take 30-45 minutes. You use a few minutes to read the diff. You use most of the time to say aloud what you would flag. Then the interviewer asks follow-up questions about your reasoning or a hypothetical variant of the bug.
How should I prepare for a code review interview?+−
Practice on real pull requests with planted bugs. Do not only read about the format. The interview tests pattern recognition under time pressure. A checklist does not build that reflex. Reviews of graded PRs do.