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. ```hint 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 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 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. ``` ### 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? ### What a Strong Answer Covers The interviewer is evaluating judgment and communication, not whether you can list every category. A strong answer demonstrates: - **A repeatable framework** — a named, ordered checklist applied deliberately, with correctness prioritized over style. - **Severity discipline** — clear separation of blockers (correctness, data loss, security) from should-fix items from nits, with explicit labels. - **At least one real catch** — identifying a genuine correctness or edge-case bug in the change, not just stylistic nits. - **Comment quality** — comments that are specific, kind, actionable, and propose a fix or ask a precise question; phrasing that assumes good faith. - **Handling ambiguity** — stating assumptions explicitly and framing uncertainty as questions rather than blocking on missing context. - **Coverage of non-obvious categories** — tests and observability, not only logic and formatting. ### 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?