Reading Code Like a Reviewer: Severity-Ranked Feedback

A different round than it looks like at first

Instead of a blank editor, you're handed an existing diff or file and asked what you think — sometimes it has obvious problems, sometimes it's intentionally ordinary but incomplete. This format tests something LeetCode-style prep does nothing for: reading unfamiliar code critically, identifying real risk (not just style nits), and communicating findings clearly — then, often, implementing the single highest-value fix, not a full rewrite of everything you noticed.

A consistent review order, so you don't just list observations randomly

The failure mode this round punishes hardest is an unranked stream of observations — some real bugs, some pure style preference, presented with equal weight, forcing the interviewer to do the prioritization you should have done yourself. A review order that scales down cleanly to interview time constraints, roughly following Google's engineering practices and reinforced by dedicated code-review-round prep guides:

1. Restate intent. What is this code trying to do, in one or two sentences, before you start finding fault with it? This anchors everything that follows and signals you read for understanding first, not just for problems.
2. Correctness and edge cases. Does it do what it's meant to for the inputs that actually matter — empty collections, null/missing fields, boundary values, the unhappy path?
3. State changes, side effects, retries, idempotency. Does this code do anything that's dangerous to run twice (a double charge, a duplicate email), and does it handle a partial failure safely? This category is disproportionately high-value to name because it's disproportionately easy to miss on a first read.
4. Authorization, privacy, and unsafe input. Is there a place a user could access or manipulate data they shouldn't? Is untrusted input trusted somewhere it shouldn't be?
5. Error handling and observability. Are failures surfaced usefully (to a caller, to a log, to a metric) or silently swallowed?
6. Performance, but only relative to the code's actual expected scale — flagging an O(n²) loop over a collection that's always three items long is noise, not signal; the same loop over a collection that can be a million items long is a real finding.
7. What tests should exist, if they don't already — naming the specific missing test cases is more useful than a generic "needs more tests."
8. Maintainability and style, last, and clearly marked as lower priority — following Google's convention, prefix pure preference with something like "Nit:" so the distinction from a real issue is unambiguous.

Prioritizing severity is the actual skill being tested

Given limited time, the strong move is naming issues in roughly the order above and being explicit about severity — "this retry logic has a real correctness problem: it isn't idempotent, so a retried request could double-charge; separately, this variable name could be clearer, but that's a nit" — rather than treating every observation as equally urgent. When asked to actually fix something, pick the highest-severity item that fits in the remaining time; suggesting a full rewrite when a small, targeted fix would resolve the actual risk reads as missing the point of the exercise (see the previous subtopic on why targeted changes beat rewrites generally).

Common ways this goes wrong

• Starting with style before behavior. Commenting on formatting or naming before you've said anything about correctness signals the wrong priorities, even if you get to correctness eventually.
• An unranked list of every possible improvement. Ten observations with no indication of which two actually matter is worse than three well-prioritized ones.
• Missing authorization/privacy and retry/idempotency issues specifically — these are the two categories interviewers report candidates skip most often, precisely because they require thinking about how the code could be misused or interrupted, not just how it behaves on the happy path.
• Being harsh about the code instead of being useful about the risk. "This is bad" is not feedback; "this can double-charge a customer on retry, here's why" is.

Being on the receiving end, briefly

The mirror image of this round — being handed feedback and asked to respond — rewards the same severity-first instinct in reverse: acknowledge the highest-severity point first, ask a clarifying question if a piece of feedback is ambiguous rather than guessing at intent, and it's entirely fine to push back on a genuinely low-priority nit as long as you're not dismissive about a real correctness or security concern in the same breath.