Engineering Practice
Code review: multiple-choice review
Crux Multiple-choice synthesis across the code-review unit — what humans catch vs tooling, PR size and latency, feedback that triages, scaling the queue, and the anti-patterns that invert review's purpose.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a call you make as a reviewer or a tech lead under real pressure — not a definition to recite, but a tradeoff to weigh when a PR is blocking someone and the clock is running.
Goal
Confirm you can connect what review is for, why PR size sets both latency and detection, how to make feedback triageable, and how the queue and the anti-patterns reshape review at scale — the synthesis the five lessons built toward.
Quiz
Completed
A team wants reviewers to be more thorough, so they ask everyone to also flag formatting, import order, and naming-case issues in every PR. Why is this the wrong move?
Heads-up Skipping by convention is fragile — a tired reviewer still types the nit and style still lands in the diff. The fix is structural: make the decidable class impossible to reach review by blocking on a formatter/linter in CI, not relying on discipline.
Heads-up Speed isn't the criterion. Some human judgement is slow yet irreplaceable. The line is whether a rule can be evaluated mechanically with a stable answer — that is what belongs in a gate, regardless of how fast a human would be.
Heads-up Comment count isn't the metric in either direction. A diff can need many substantive design comments. The point is that no human should ever type a comment a machine could have made — not that comments are bad.
Quiz
Completed
Your team's median PR pickup is creeping toward a day and post-merge defects are rising as diffs grow. What is the single highest-leverage fix?
Heads-up An SLA on completion pressures the visible metric while harming the real one: it can't conjure a free 90-minute block for a 1,500-line diff, so the reviewer rushes and skims, trading the latency win for a detection loss. SLAs help on first-response, not on quality.
Heads-up Two reviewers on a 1,600-line diff still each face 1,600 lines past anyone's cognitive budget — two skims instead of one, plus double the pickup wait. Reviewer count doesn't change the per-person attention limit; diff size does.
Heads-up A summary can help, but the human still must reason about 1,600 lines of design to catch the real flaw, and the diff still queues for hours waiting for a block. It treats the symptom; the cause is batch size.
Quiz
Completed
Per Google's data, why do small changes get picked up in under an hour while very large ones wait around five hours?
Heads-up It's not a priority rule — it's queueing physics. The large CL's service time exceeds the free gaps in people's days, so it waits for a scarce block, not because anyone deprioritized it.
Heads-up It's a structural constraint, not motivation. Even a diligent reviewer can't read 1,500 lines in a five-minute window, so the large CL physically can't be served until a long block opens up.
Heads-up Small CLs are reviewed — often more thoroughly. They're just cheap to context-switch into, so they're picked up fast rather than skipped.
Quiz
Completed
A reviewer drops 'consider extracting this' on a function and the author can't tell whether it blocks merge. What does the comment fail to make explicit, and how do you fix it?
Heads-up The goal is less ambiguity per comment, not more comments. A label and a concrete action let the author act in one pass; piling on more vague comments only deepens the guessing.
Heads-up Sometimes a suggested edit helps, but the reviewer can't always know intent, and silently rewriting bypasses the knowledge-sharing the review is for. The durable fix is a tagged, actionable comment, not taking over the author's diff.
Heads-up Labels set severity, not reasoning. An actionable comment still needs the 'why' when it isn't obvious — the label complements the explanation, it doesn't replace it.
Quiz
Completed
The SmartBear/Cisco study found one author-side factor with a dramatic effect on defect density. Which is it, and why does it work?
Heads-up The standout finding was author-side, not reviewer count. Extra reviewers each still face the same diff under the same cognitive limit; the author's act of explaining is what shifts defect detection upstream.
Heads-up Comment length wasn't the lever. The dramatic effect came from the author annotating their own diff — the ego effect and forced re-examination — not from reviewers writing more.
Heads-up Pace matters (above ~450 LOC/hour detection drops), but the study's most under-appreciated result was author preparation driving density toward zero — an author habit, not a reviewer pacing rule.
Quiz
Completed
An org grows to 200 engineers; one staff engineer is sole CODEOWNER for payments with ~40 reviews/day, and quality is slipping into rubber stamps. What's the highest-leverage fix?
Heads-up An SLA on completion pressures the one overloaded person to go faster, which on a deep queue means skim and stamp — the exact failure you're fixing. SLAs help on first-response/pickup, not on quality, and can't conjure attention the bottleneck doesn't have.
Heads-up Post-commit removes pickup latency but is only safe on a high-trust base with a strong automated floor — and payments is money/security-sensitive, exactly where post-commit is the wrong default. You'd trade a bottleneck for unreviewed money-path changes on trunk.
Heads-up Comment count is a Goodhart trap: make it a target and reviewers manufacture nitpicks to hit the number, driving bikeshedding while design still slips — and it does nothing about the one-person bottleneck.
Recap
The through-line of the unit is one operating model: review exists for the undecidable — design, intent, correctness, knowledge transfer — so push every decidable check into a blocking gate before review. PR size is the master variable because it sets latency (pickup is a size-driven queue) and detection (attention is a fixed budget) at once, in the same direction; small and stacked PRs move both. Feedback works when it states severity and a fix, and the author’s own annotation finds defects no reviewer sees. At scale you route ownership to a team, time-box pickup (never completion), balance load, and sometimes change the shape — pairing or post-commit on a tested, high-trust base. Every anti-pattern is the same inversion: review stops being about design.