Katkat
Back

How do you conduct a code review exercise?

AirbnbSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSoftware Engineering Fundamentals

Last updated

This question tests a software engineer's ability to conduct structured, high-signal code reviews under time pressure and limited context. It evaluates judgment in prioritizing correctness issues over style, communicating feedback clearly, and handling ambiguity — core competencies in software engineering fundamentals interviews.

In a live interview, you are shown a short code change — a diff, a pull request, or a standalone function — and asked to produce written code review comments with minimal back-and-forth. The interviewer may share their screen, give you a few minutes to read, and then largely go quiet, expecting you to think aloud and type the comments you would leave on a real PR.

Walk through your structured approach to producing high-signal review feedback under these conditions. Concretely cover:

  • The categories of issues you scan for (e.g. correctness, edge cases, concurrency, security, performance, readability, testing, API design, observability) and the order you apply them in.
  • How you prioritize and label comments so the author knows what is a blocker versus a nit.
  • Examples of well-written review comments — the exact text you would type, including how you phrase a blocker, a suggestion, and a nit.
  • How you handle missing context or requirements when you cannot interrogate the author.

Constraints & Assumptions

  • Format: This is a written review with little dialogue. You should narrate your reasoning aloud but the deliverable is the set of comments themselves.
  • Time-boxed: Assume ~20–30 minutes total — enough to read the change carefully and leave a focused, prioritized set of comments, not an exhaustive line-by-line audit.
  • Limited context: You usually do not have the surrounding codebase, the ticket, or the author available to answer questions. Make assumptions explicit rather than stalling.
  • Language-agnostic: The principles should hold regardless of the language shown; adapt concrete examples to whatever code you are given.

Clarifying Questions to Ask

A candidate should briefly confirm scope before diving in:

  • What is the goal of this change — is there a linked ticket or intended behavior I should review against?
  • What is the expected style of feedback — line-level comments, a summary, or both? Do you want me to also propose tests?
  • Are there non-functional requirements that matter here (latency budget, security/PII sensitivity, backward-compatibility guarantees)?
  • Is this change on a hot path / public API, or internal and low-traffic? (This calibrates how strict to be.)
  • What is the team's bar — must everything be perfect to approve, or is "approve with comments" acceptable?

Hints

Hint 1

Where to start: Treat it like a real review, not a bug hunt. Before reading line-by-line, reconstruct **intent**: is this a feature, bugfix, or refactor, and what is it *supposed* to do? Everything you flag is relative to that intent.

Hint 2

A scanning framework: Apply a **fixed checklist** so you don't miss a category under pressure. Prioritize correctness over polish — severity tends to fall as you move from logic issues toward style.

Hint 3

Make your comments actionable: Each comment should be **specific, severity-labelled, and propose a fix** (or ask a precise question). "This is bad" is low signal; "Blocker: empty `items` makes `items.get(0)` throw — return `Optional.empty()` instead" is high signal.

Follow-up questions

  • The author pushes back on one of your blocker comments, arguing the edge case "can't happen in practice." How do you respond?
  • You notice a deeper design problem that the diff exposes but doesn't introduce. Do you raise it in this review, and how do you scope it so the PR isn't blocked indefinitely?
  • How would your review change if this were a **junior engineer's first PR** versus a **staff engineer's change to a critical service**?
  • The change has no tests but is "obviously correct." Do you block on missing tests, and where do you draw that line?