Tell me about a time you approved a pull request you had reservations about.
answer
- the reservation, said out loud
- what blocking would have cost
- blast radius and reversibility
- conditions attached in writing
- did the follow-up actually close
basics
~20 sProbes judgment about when not to block. Answer with the reservation you put in writing, why the risk was acceptable that day, what made the change reversible, and how you made sure the follow-up actually happened.
how to answer
5 beats- the change and the reservation I hadSay concretely what you did not like, in one or two sentences. Vague discomfort makes the rest of the answer unassessable — the interviewer needs to judge whether your concern was real.
- the pressure on the other sideName what blocking would actually have cost: a stalled release, a team blind to something, another day of someone's time. This is the beat that makes the decision a trade rather than a preference you abandoned.
- why I approved instead of blockingGive the reasoning in the terms you would use with a peer — blast radius, reversibility, whether the failure mode is loud or silent. Spend the bulk of your airtime here and in the next beat.
- the conditions I attached, in writingDescribe what you recorded and where, so the reservation outlived the conversation. Include the owner and the date if there was one; a follow-up nobody owns is the beat interviewers dig into.
- what happened, including the follow-upClose with the outcome and whether the debt actually closed. Then add the line about what would have flipped you to a block — it is the sentence that proves this was judgment and not conflict avoidance.
your answer
4 story prompts- Pick a change you approved while still uncomfortable, and say why.
- Check whether the follow-up ticket actually closed, and when.
- Write the one-line rule that separates your blocks from your nits.
- Find where you recorded the reservation, or note that you didn't.
draft and rehearse your own answer in a learn session
go deeper
Reviewers who block everything are as expensive as reviewers who block nothing, so interviewers probe whether you can price risk instead of applying taste uniformly. A strong answer shows a deliberate trade — reversibility and blast radius against the cost of delay — a reservation recorded where others can see it, and ownership of the follow-through rather than a promise that quietly expired.
Mid-incident, our nightly suite had been dark for two days — every run red for tangled reasons — so nobody could tell whether the fix we were about to push was safe. A teammate put up a change that got the signal back by copying the fixture setup into six spec files and bypassing the shared helper. I didn't like it. It's duplication that will drift, and I'd have written a scoped helper instead. But I asked what blocking would actually buy. The change touches test files only, one command reverts it, and what it unblocks is our ability to see whether production is broken. That's a poor trade for a day of my preferences. So I approved, and I put the reservation on the change rather than leaving it in my head: one comment saying I was approving with a known cost, that the six copies would drift and whoever edits one will miss the others, and that I'd own collapsing them. Then I made it real — a ticket with my name and a date on it, said in standup so it wasn't a private promise. I collapsed them nine days later, once the incident was closed. Flake rate on the nightly went to 5.1% during that week and settled at 3.2% after. If the change had touched the release gate rather than fixtures, I'd have blocked — reversibility was the entire reason I didn't.
The trade is stated in checkable terms — test-only, one-command revert, versus two days of no signal — and the reservation is recorded publicly rather than swallowed. The closing sentence naming what would have flipped it to a block is what makes this judgment rather than conflict avoidance.
A newer engineer on my team spent a sprint rewriting our end-to-end harness. The change was large, and my honest first read was that I'd have structured about a third of it differently. The context mattered. Flake rate on the checkout suite was 21.4% and people had stopped believing red builds, which is how the failure we shipped the month before got past everyone. Her rewrite was measurably better than what we had, and my restructuring would have cost her another sprint plus whatever it cost her to be told her sprint was wrong. So I did two things. I found the one issue that genuinely blocked — the new runner swallowed setup failures and reported them as passes, exactly the failure mode that had already bitten us — and I said so plainly with the log line that proved it. Everything else, around thirty comments' worth, I re-tagged non-blocking, with a line at the top of the review saying so: one blocking issue, the rest are mine to live with. She fixed the swallowing, I approved, and I booked forty minutes the following week to walk through the three patterns I'd have reached for, framed as what I'd want next time rather than as a redo. That suite sat at 7.5% six weeks later. What I'd defend is the ratio — one real objection, all my credibility spent on it, instead of thirty objections and none of them landing.
Senior signal is the deliberate spend of review capital: one blocking issue proved with evidence, everything else explicitly downgraded and announced. Teaching the patterns afterwards, outside the review, keeps the author's ownership intact. Without the log line, the block would rest on authority alone.
It is fine that a more experienced reviewer's read on the risk carried the decision. What must be yours is the reservation itself — say what you saw, and where you wrote it down so it was not lost.
Reason out loud about the trade: blast radius, reversibility, and what a day of delay would have cost. Then show you tracked the follow-through instead of trusting a ticket to look after itself.
Own the risk explicitly. You approved, you set the conditions, and if it partly went wrong you carried that rather than pointing at the author. Say what you would block on in the same situation today.
Frame it as a bar rather than a favour: how the team decides what is worth blocking at all, so that approving imperfect code is a known standard other reviewers can apply without asking you.
saying these in an interview costs you the question
- Approving framed as avoiding conflict rather than as a judgment
- The reservation existed only in your head
- A follow-up ticket with no owner and no date
- Insists nothing may merge with any concern outstanding
- Cannot name what would have made it a block instead
- The debt never gets revisited and the story moves on
- What would have made you block it instead?Answer with a line, not a feeling. Usually it is blast radius (test-only versus customer-facing), reversibility (one command versus a data migration), or whether the defect can fail silently. Being able to state the threshold is what proves the approval was a decision rather than a shrug.
- Did the follow-up work actually get done?If it did, say when and who did it. If it did not, say so plainly and what you learned about how your team lets debt tickets rot — an honest no with a lesson beats a vague yes. Either way, describe the mechanism that made the promise visible outside your own memory.
- How do you keep approving-with-reservations from becoming approving everything?Talk about frequency and record. Reservations that are always written on the change, and a follow-up that is actually tracked, make the pattern auditable — including by you. Some reviewers keep a rough count of what they let through and revisit it; anything that shows you notice drift works here.