A code review interview hands you a pull request — often deliberately flawed — and asks what you'd flag before approving it. Unlike LeetCode, there's no single correct answer to submit. You're graded on what you catch, what you miss, and how you explain it.
What interviewers are actually grading
Most candidates over-index on style — naming, formatting, minor refactors. Interviewers mostly don't care. What they're listening for:
- Correctness under concurrency — race conditions, lost updates
- Idempotency — what happens on retry or duplicate delivery
- Failure modes — what happens when a downstream call times out
- Security — auth bypass, injection, data exposure
- Whether your comments are actionable, not just observations
Common code review interview questions
"Walk me through how you'd review this PR."
Say your process out loud: read the diff for intent first, then trace the change through its failure paths, then check tests. Interviewers want to see a repeatable process, not a lucky catch.
"This function isn't thread-safe — how would you flag it?"
Name the specific race (two requests reading-then-writing the same state), not just "this could have concurrency issues." Then say what you'd ask the author to change — a lock, an atomic operation, or a different data structure — not just that it's wrong.
"How do you review code in a language you don't know well?"
Say you'd focus on the parts of a review that are language-agnostic — control flow, error handling, edge cases, API contracts — while flagging that you'd want a second reviewer for idiom-specific concerns.
"What would you NOT block a PR for?"
This is a trap for over-eager reviewers. The answer: style preferences, minor naming, and refactors unrelated to the change. Senior reviewers unblock fast and leave non-blocking comments for the rest.
How to structure your review comments
Interviewers consistently reward comments with this shape:
- What's wrong, stated specifically (not "this looks risky")
- Why it matters — the concrete failure scenario
- What you'd change, in one sentence
"This retry doesn't check idempotency — a duplicate request after a timeout will double-charge the customer. Add an idempotency key keyed on the request ID." beats "retry logic looks risky" every time.
Practice with real, graded PRs
Reading about code review questions only gets you so far — the skill is pattern recognition under time pressure. Senior Loop's code review catalog has 15+ hand-authored PRs across payments, distributed systems, and APIs, each with planted, specific bugs and a rubric-based AI grader that scores what you caught versus missed. Three reviews are free, no card required.
Part of the Senior Backend Engineer Interview Prep guide.