Code Review Interview Questions and Answers

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:

1. What's wrong, stated specifically (not "this looks risky")
2. Why it matters — the concrete failure scenario
3. 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.

Worked example: reviewing a real snippet

Here's a small payment-retry function, the kind of thing that shows up 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's no error handling if the retry also fails." True, but not the interesting bug. A senior review leads with the one that costs money: the retry has no idempotency key, so if the first call actually succeeded and only the response was lost — a timeout, a dropped connection — the retry double-charges the customer. The fix isn't "add a try/catch," it's passing an idempotency key derived fromorderId so the gateway can dedupe the second call. That distinction — spotting the state-consistency bug versus the visible one — is exactly what separates levels below.

How the bar rises by level

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.

Related reading

• Senior Backend Engineer Interview Prep
• System Design Interview Questions
• Practice graded code review PRs