In what order should you read a code change under review, and why does the order matter?
answer
- Cheapest mistake to undo goes last
- Judge the approach before the details
- Four widening passes, not one sweep
- Intent, contract, edge cases, tests
- Ask which test would fail
basics
~20 sRead the intent first — what problem the change claims to solve — then the contract it exposes, then the edge cases and error paths, then the tests. That order settles whether the change is right before you argue about how it is written.
solid answer
~40 sI read in decreasing order of how expensive the mistake would be to undo. **Intent first**: the change description, the requirement behind it, and whether this is the smallest change that satisfies it — if the approach is wrong, nothing below it matters. **Contract second**: the signatures, inputs, outputs, error results and stored shapes the change exposes to other code, because those are what callers depend on and the hardest thing to retract later. **Edge cases and error paths third**: empty and boundary inputs, partial failure, retries, two callers at once. **Tests last**: do they assert the behaviour that was actually claimed, and would any of them fail if the change were subtly wrong? Cosmetic remarks come after all of that, and most of them should not be a human's job at all.
go deeper
Be ready to describe your own reading order out loud and defend it. Interviewers mostly want to hear that you read what the change is for before you read how it is written, and that you open the tests rather than trusting a green result.
Explain why the order is what it is: reversibility. Show that you can say which parts of a change are expensive to retract later, and give an example of a defect that only an adversarial pass over the error paths would find.
Demonstrate that you adapt the order to risk. Say how you triage a change that is too big to read, how you decide which surfaces get a careful pass, and how you turn a vague worry into the concrete question of which test would fail if it were real.
Own the question of what human attention should be spent on at all. Be able to argue which review findings a team should stop producing by hand, and how the reading order changes when a change crosses a boundary many teams depend on.
## Why a review needs an order at all Reviewing is reading under a budget. Attention is finite and it decays fast, so whatever you look at first gets your best judgement and whatever you look at last gets a glance. A reviewer who opens the change and reads it from the first altered line to the last spends that best judgement on whichever file the diff tool happened to sort first. A deliberate reading order spends it on the parts where being wrong costs the most. The ordering principle is *reversibility*. Rank the aspects of a change by how expensive the mistake is to undo once it is merged, and read them in that order. ## Pass one — intent Before reading any code, read what the change claims to do: the description the author wrote, the requirement or defect it points at, and the conversation that produced it. Then ask three questions. Is this the right problem to solve now? Is this approach a reasonable way to solve it? Is this the smallest change that solves it, or has unrelated work ridden along? This pass is the only one that can save the whole change. A design decision caught here costs a conversation; the same decision caught after the code has been written, tested and read line by line costs a rewrite and a demoralised author. If the change has no intelligible description, that is the first finding — a reviewer who cannot state what the change is for cannot judge whether it works. ## Pass two — the contract Next read the surface the change exposes to everything outside it: function and message signatures, parameter and return types, the shape of persisted or transmitted data, error results and what a caller is expected to do with them, defaults, and units. This is the part with the widest blast radius and the shortest half-life of correction — an awkward internal loop can be tidied next month by whoever touches it, but a wrong parameter order, a nullable that should not be, or a stored field with the wrong precision spreads to every caller and then has to be unwound everywhere at once. Read the contract as a caller who has not read the implementation. If you cannot tell from the signature and its documentation what happens on an empty input, a duplicate call, or a downstream failure, that is a finding regardless of how the body is written. ## Pass three — edge cases and error paths Only now read the body, and read it adversarially rather than sequentially. Walk the boundaries: zero, one, many; empty, maximum, and just-over-maximum; absent optional values; a collection that arrives unordered. Walk the failure paths: what happens when the dependency times out, returns a partial result, or returns success but with nothing useful in it. Walk concurrency: what happens if this runs twice at once, or if a retry replays it after the first attempt already half-succeeded. Most of what review catches that a test suite does not lives here — not defects in the paths someone thought to write a test for, but the paths nobody thought about at all. A test suite can only assert what its author imagined; a second reader is a second imagination. ## Pass four — the tests Read the tests last, and read them as evidence rather than as code. Two questions do most of the work. Do these tests assert the behaviour the change claims in pass one, or do they merely exercise it — calling the new path and asserting something incidental like "no exception was thrown"? And, for each risk you found in pass three, would any existing test fail if that risk were real? If the answer is no, the useful review comment is not "add a test" but "which test would have failed if this were wrong?" — that question names a missing oracle instead of a missing file. Some reviewers deliberately read tests first when the intent is unclear, using them as documentation of what the author believes should be true. That works, at a cost: you inherit the author's framing of what matters and are less likely to notice the case they never considered. ## What the order is not The order is a default, not a ritual, and it interacts with size. Past a few hundred changed lines a reader cannot hold the contract in mind while walking the branches, and the passes collapse into skimming; at that point the honest review comment is that the change should be split. It also assumes the mechanical layer is already handled elsewhere — formatting and other machine-checkable properties should not be consuming a human's first pass at all. What a reviewer brings is judgement about intent, contract and the unimagined case, and the reading order exists to spend that judgement where it is scarcest.
- You have twenty minutes and the change is far too large to read properly. What do you actually do with the time?Spend it on the highest-risk surface rather than spreading it thinly: the contract, anything that writes or migrates stored data, anything touching money or access. Then say plainly in the review what you did and did not read, so the approval does not imply coverage it never had, and ask the author to split the remainder. An honest partial review is more useful than a full one nobody performed.
- Should you read the tests first instead, since they describe the intended behaviour?Sometimes — when the change description is thin, the tests are the clearest statement of what the author believes should be true, and reading them first orients you quickly. The cost is anchoring: you adopt the author's model of the problem and become less likely to spot the case nobody considered. A common compromise is to skim test names early for orientation and read the assertions properly at the end.
- What do you do when the change is correct but you would have designed it differently?Separate the two claims. If the difference affects the exposed contract or something expensive to change later, raise it as a design point with the reason and the cost. If it is an internal preference that a future reader could reverse cheaply, say so explicitly as a preference and let the change proceed. Reviewers who cannot tell those apart make every review a negotiation about taste.
It is the order a building inspector uses: does the building belong here at all, then is the structure sound, then do the fittings work, then is the paint tidy. Nobody argues about paint before checking the foundations.
saying these in an interview costs you the question
- Starts at the first line of the diff and reads straight through
- Treats formatting remarks as the substance of a review
- Approves without opening the tests at all
- Never reads the change description or the requirement behind it
- Assumes passing tests mean the behaviour is correct
- Critiques the implementation before deciding the approach is right