Walk me through this one. In your repository 38% of pull requests are approved with no comments within two minutes of being opened, and the change failure rate has not moved in a year. Is that a problem how would you find out and what would you change?

What the interviewer is testing

Whether you treat review as a control with evidence behind it rather than a ritual to be defended or abolished. The trap is answering immediately. 38% of approvals in under two minutes is consistent with a healthy team and with a team whose review step has quietly become a signature, and the data in the question does not distinguish them.

The clarifying questions that change the answer

• How large are those changes? A 12-line configuration bump approved in 90 seconds is correct behaviour and the fast path should be made official. A 900-line change approved in 90 seconds was not read.
• What class are they? Dependency bumps, generated code and codemods dominate the fast bucket in most repositories. Those should be reviewed by their generator and their test, not line by line.
• Is it the same approver every time? Reviewer concentration produces both symptoms at once: a bottleneck for the changes that need attention and reflex approvals for the rest.
• Is the approval also a compliance control? If an auditor tests that every production change was independently reviewed, a two-minute approval of a large diff is a control failure, not a preference, and the conversation moves from quality to evidence.
• What do the automated checks already cover? If formatting, lint, types and migrations are gated in CI, the comments a reviewer does not leave may simply have moved.

What I would measure

Join three fields that most tooling already stores: change size, time to first review, and comment density (comments per 100 changed lines), split by change class. Then:

• Look at escaped defects over the last two quarters and ask, for each, whether reading the diff could plausibly have caught it. Most teams find a small number that were reachable and a majority that were not - wiring, configuration, integration, data.
• Look at the large tail: changes above roughly 400 lines with zero comments. That is the bucket where the control is failing, and it is usually small enough to fix without a policy change.

Bacchelli and Bird's study of code review at Microsoft (ICSE 2013), which combined observation, interviews, a survey of developers and managers, and manual classification of hundreds of review comments, is the grounding worth citing in that conversation: the top stated motivation is finding defects, but reviews turn out to be less about defects than expected, delivering code improvements, knowledge transfer and team awareness instead - and understanding the change is the central activity. An unread large diff delivers none of it.

What I would change

1. Route by risk, not by uniform policy. Size times blast radius decides whether a change needs an owner's review, a second pair of eyes, or an automated path.
2. Make the mechanical classes explicit - a codemod carries its script, a dependency bump carries its changelog diff and test run - so that the fast approval is a documented decision rather than a lapse.
3. Cap review size instead of raising approval counts. A 400-line ceiling with stacked changes beneath it does more for defect detection than a second approver on a 900-line diff.
4. Give the large tail a named owner - the person who owns the touched code, not whoever is free.

Common weak answers

• "Require two approvals." Doubles the waiting and does not make anyone read more carefully. If one reviewer did not understand the change, two reviewers who did not understand it is not an improvement.
• "Set a comments-per-pull-request target." You will get comments. They will be about naming.
• "Approvals under two minutes should be blocked." A timer treats the fast path as the disease. The mechanical changes are exactly the ones that should be fast, and blocking them teaches people to wait two minutes.

What a strong answer adds

That review latency and review quality trade against each other only when the queue is undifferentiated, and that the cheapest intervention is almost always shrinking the unit under review rather than adding reviewers. And the organisational point: if the approval is a regulatory control, the fix has to produce evidence, so the fast path needs a recorded justification an auditor can sample.