Tell me about a time you blocked a teammate's pull request in code review.
answer
- name the change and the risk
- what I verified before blocking
- the block: one reason, one alternative
- moved it off the thread
- how it merged, relationship intact
basics
~20 sTests whether you hold a line on risk without making it a contest. Answer with one change you refused to approve, the concrete harm you named, the alternative you offered, and where the code and the relationship both ended up.
how to answer
5 beats- the change and why it matteredSet up the change in two or three sentences and name the stake in terms someone outside your team would feel. Keep this to roughly fifteen to twenty percent of your airtime; the setup is not the story.
- what I verified before I blockedSay what you checked — a reproduction, a measurement, a prior incident, a written agreement. This beat is what turns your block from an opinion into a finding, and skipping it is the commonest way this answer downlevels.
- the block itself: one reason and one alternativeQuote or paraphrase what you actually wrote, and include the way out you offered. Along with the next beat this should carry about sixty percent of your airtime.
- how the disagreement resolvedCover the pushback honestly, including anything the author was right about, and the moment you moved off the written thread. Name who else you pulled in, if anyone, and why that was not an escalation over the author's head.
- result and what changed afterwardsClose with how the change eventually merged, one number if you have one, and either a prevention step or a line showing the relationship held. Budget about twenty to twenty-five percent here — a strong middle with no landing is the classic failure.
your answer
5 story prompts- Pick a review where you refused to approve and the change still merged.
- Find the evidence you had at the time, not the evidence you have now.
- Name the alternative you offered the author, or admit you offered none.
- Choose a block from the last eighteen months you can still quote.
- Note whether that person sends you reviews now.
draft and rehearse your own answer in a learn session
go deeper
Blocking is the one routine moment where an engineer stops a peer's work, so it exposes how you exercise authority you were merely handed. Interviewers weigh the evidence you required of yourself against the force you applied, whether you left the author a route to done, and whether the working relationship survived. It also reads your judgment about what genuinely warrants a block.
Three of us held the test infrastructure for a startup's main product, and we'd just come off eighteen days of chasing an outage our nightly suite should have caught and didn't. A week after that, a teammate put up a change pointing the integration tests at the shared staging database instead of the per-run container. It made the suite about four minutes quicker, and honestly it was tempting. I blocked it. Before I did, I went and got the evidence. Two of the three worst false-greens we'd logged that month were runs where staging data had drifted underneath the test — the same shape as the thing that had just cost us eighteen days. So my comment was one reason and one alternative: blocking, because shared state here is the failure mode that hid the outage from us, and if the four minutes matter I think we get most of them back by reusing the container image rather than rebuilding it. I offered to do that half myself. He pushed back once, saying container startup was the real cost. That's when I stopped typing and asked for fifteen minutes. On the call we measured it — he was right about startup, I was right about the data — and we shipped his speedup with isolation kept. The suite ended up two minutes faster than his original version, and false-greens went from three that month to none across the following two. He still sends me his risky changes, which I count as the actual result.
The evidence beat does the work here: two logged false-greens with the same signature turn a preference into a finding. Conceding the startup point on the call, and the merged-faster ending, keep it from being a vindication story. Without the offer to do half the work himself, it would read as pushing cost onto the author.
As the senior on a quality platform team at a startup, I block maybe one review in thirty, so when I do it has to be worth the spend. The change was to our release gate. After an outage we'd taken real heat for, someone proposed auto-retrying any failing test up to three times before failing the build, because releases had got stuck twice that week. The pressure behind it was legitimate. I blocked, and I was deliberate about how. First, one comment naming the cost in the language the team already cared about: a retry-until-green gate cannot tell a flake from a regression, so the number we watch stops meaning anything and the next bad build ships looking clean. Second, I said in the thread that I was blocking and that I would own unblocking releases another way, so nobody was left sitting on a stuck deploy while I made a point. Then I took it off the change — fifteen minutes with the author and our engineering lead — and we landed on a quarantine list with a seven-day expiry and a named owner per entry. I wrote that up and approved his retry code, scoped to quarantined specs only. Over the next couple of months flake rate on the release suite dropped from 19.6% to 5.8%, and the argument stopped recurring because the gate stopped lying. He ran the quarantine review after that. I wanted the mechanism not to need me.
Senior signal sits in three places: the explicit cost of blocking under delivery pressure, taking responsibility for unblocking releases rather than just refusing, and ending with a mechanism plus a handoff. Losing the handoff sentence would drop this to a well-argued individual block.
A small blocked change is fine, and so is having asked someone more experienced to sanity-check your read first. What must be there is the verification step: you reproduced or measured something before you objected.
Own the block end to end. Name the risk in the team's own terms, propose the alternative yourself, and be able to say how the change eventually merged rather than stopping at the standoff.
Expect production stakes in the story and a second half about prevention: what you changed so this class of risky change gets caught by a gate or a convention rather than by you happening to be on the review.
Talk about where blocking authority sits and how disputes resolve without you in the room. The strong version ends with a norm that outlived the incident and cost the team less than your personal vigilance did.
saying these in an interview costs you the question
- Blocks on formatting or structure and calls it a defect
- Never offers the author any path forward
- The story's climax is who turned out to be right
- Escalates to a manager before talking to the author
- No outcome: we never learn whether the change shipped
- Describes the author as careless rather than describing the code
- What if the author had insisted and the release was going out that day?Don't claim you would have held the line unconditionally — that reads as inflexible. Show the time-box: what mitigation would let it ship (a flag, a limited rollout, a revert plan), what you would need to see before the next release, and who you would tell. Naming the conditions under which you would have approved is the answer they want.
- Have you ever blocked something and turned out to be wrong?Say yes and have one ready. Describe how you found out, how quickly you said so in the thread, and whether you unblocked yourself or waited for the author to argue you down. Candidates who cannot recall a wrong block usually are not reviewing much, or are not listening in reviews.
- How long did the thread run before you took it off the pull request?Give a real threshold rather than 'when it got heated'. Two exchanges with no new information is a common and defensible line. Say what the conversation was for — usually establishing which facts you actually disagree about — and confirm that the outcome went back onto the change so the decision has a written home.
This prompt is a favourite because blocking is the only moment in ordinary engineering work where you unilaterally stop a colleague from finishing something. Everything about how you handle **authority**, **evidence** and **repair** shows up in about ninety seconds. ## Wording variants you will hear - 'Tell me about a time you disagreed with a code review you were doing.' - 'Describe a review where you would not approve.' - 'When was the last time you told someone their approach was wrong?' They are the same prompt. A trickier variant inverts the seat — 'tell me about a review that turned into an argument' — and there you should still narrate from the reviewer's chair unless the interviewer explicitly asks about being the author, because the signal they are after is your use of the block. ## Weak versus strong The **weak answer** is a righteousness story: the code was bad, I said so, eventually they saw sense. It fails on three counts: - It gives no evidence beyond the speaker's judgment. - It offers the author no route to done. - It ends on vindication rather than on a merged change. The **strong answer** usually inverts the emphasis — a short account of the risk, a long account of the mechanics of resolving it, and a closing line about the working relationship that implies you will be able to do this again next month. ## The evidence that earns a block Interviewers grade the ratio between how hard you pushed and what you had. 1. The **strongest currency** is something the author can reproduce: a failing run you can point at, a past incident with the same signature, a written team agreement. 2. **Next best** is a named consequence they had not considered — data loss, a silent failure mode, an on-call cost that lands on someone else. 3. **Weakest**, and often a downlevel, is architectural preference stated as fact. If your story's evidence is preference, either pick another story or be explicit that you eventually dropped it, which is its own good signal. ## Offer the alternative A block that hands back only a problem shifts your work onto the author. Strong answers almost always contain a sentence like 'and I said I would do that part myself' or a concrete cheaper option. This is also the beat that shows you understood the pressure the author was under, which is what stops the story reading as ivory-tower. ## Know when to leave the thread Written disagreement escalates because tone is invisible and every reply is public. Have a threshold and say it out loud. What happens in the conversation matters too: you are usually not there to win but to find out whether you disagree about **facts** or about **risk appetite**, which need different resolutions. ## How the bar moves - **At mid level** a clean episode with a merged outcome is enough. - **Senior answers** add the second half — the check, convention or gate that means the next such change does not depend on you being the reviewer. - **Principal answers** move up again: who is allowed to block, how a stalemate gets resolved when the two parties are peers, and what it cost the org when that was unclear. If you only have the episode, tell the episode well; a padded systemic claim on a small story is easier to spot than a modest scope honestly owned.