Tell me about a change of yours that got stuck in review going back and forth.
answer
- how long it sat, how many rounds
- real disagreement versus preference
- the move that changed the medium
- who decided, and where it was recorded
- the delay cost, and your rule now
basics
~20 sTests whether you can end an unproductive review loop instead of waiting it out. Answer with how long it stalled, how you separated real disagreements from preferences, the move that broke the loop, and what the delay cost.
how to answer
5 beats- how long it sat and how many roundsOpen with the concrete shape of the stall — days open, rounds of comments, how many reviewers. Numbers here do the work that adjectives cannot, and this beat should stay short.
- the sort: real disagreement versus preferenceShow the triage explicitly. Most stuck threads are a couple of genuine design questions buried under naming and ordering, and separating them is the judgement the interviewer wants to see.
- the move that ended the loopName the change of medium or format — a summary comment listing open questions, a short call, a written decision. This beat and the previous one carry most of your airtime.
- the decision, written back into the threadSay who decided and where the outcome was recorded. Resolving something on a call and leaving no trace in the review is a common half-answer.
- what the delay cost, and your round limit nowClose with the concrete cost of the delay and the durable rule you now apply, such as a round limit before switching to a call. Roughly the last twenty percent of the answer.
your answer
5 story prompts- Pick a change that stalled for days, not one that merged after a slow afternoon.
- Count the rounds and the days before you draft anything — those numbers open the answer.
- Sort the comments from memory into blocking, preference, and follow-up.
- Name the exact move that ended the loop and who made the final call.
- Quantify what the delay cost: work queued behind it, or a metric that drifted.
draft and rehearse your own answer in a learn session
go deeper
This probes ownership and pragmatism: whether a stalled review is something you drive to a decision or something that happens to you. A strong answer shows you triaged the thread, moved the unresolved part into a faster medium, recorded the outcome, and can name what the delay cost the team.
During the credentials migration I had a change to the deploy pipeline's secret injection sit open for nine days across four rounds of comments. Two reviewers were arguing with each other in my thread about where injection belonged, and I was rewriting to match whichever of them had commented most recently. Round four had more comments than round one, which is when I admitted this was not converging. I stopped replying and sorted what was open. Of about sixty comments, three were genuine design disagreements and the rest were naming and ordering. So I posted a summary comment listing those three questions, marked everything else as either accepted or moved into a follow-up ticket, and asked for twenty minutes with both reviewers on a call. On the call the disagreement collapsed in roughly eight minutes: they held different assumptions about whether the pipeline or the runtime owned the lease, which no comment thread was going to surface. I wrote the decision back into the review so there was a record, and it merged the following morning. The delay had a price. Rotation lag on the services queued behind that change drifted from twelve days to twenty-seven while it sat. My rule now is that a third review round means I stop typing and ask for a call — it is a rule, not a judgement call I make when I am already frustrated.
The triage of sixty comments into three real questions is the beat that carries this, followed by changing medium and writing the outcome back into the review. Naming the drift cost is what stops it reading as a story where nothing was at stake.
Running that migration, I noticed the stalling was not one change, it was the pattern. Three of my team's four open changes were each on their fourth review round, and mine was one of them. We were four engineers and the reviewers sat in two other groups, so every thread was a slow negotiation with nobody empowered to end it. I took my own stuck change first, because I was not going to propose a rule I had not paid for myself. I closed it, reopened it in two pieces, and moved the design question that was actually blocking it out of the comments and into a one-page doc with two options. Then I proposed three things to both reviewing groups: every comment is labelled blocking or non-blocking by whoever writes it, non-blocking never holds a merge, and after a second unresolved round we default to a fifteen-minute call. I asked for it as a trial for the remainder of the migration rather than as a policy, which is why it was agreed instead of debated. Median time to merge went from six and a half days to a day and a half, and rotation lag across the thirty-one migrated services held under five. The labelling convention outlived the migration. The call rule mostly stopped being needed once comments were labelled, which told me the real problem had been ambiguity about what blocked.
The senior signals are treating review latency as a system problem, paying the cost on your own change before proposing a rule to others, and framing the mechanism as a time-boxed trial. The closing diagnosis of why the rule stopped being needed shows the intervention was understood, not just adopted.
Show you noticed the loop and asked for help rather than quietly rewriting for a second week. Asking a reviewer which comments block the merge is a completely acceptable junior move.
Triage the thread yourself — sort comments into blocking, non-blocking and follow-up — then change the medium to a short call and write the outcome back into the review.
Own the throughput problem, not just your own change: name the pattern across the team's reviews and the convention you introduced, and be honest about what it cost while it was stuck.
Frame it as review latency across groups with competing mandates, and describe a lightweight mechanism others adopted — labelling, defaults, escalation timeboxes — rather than a one-off intervention.
saying these in an interview costs you the question
- Blaming the reviewers for being slow and stopping there
- Waiting passively and calling patience a strategy
- Merging over the objections or finding an approver who would rubber-stamp
- Treating every comment as equally blocking, then complaining about volume
- No cost named, so the stall sounds harmless
- Rewriting to whichever reviewer commented last, presented as flexibility
- Whose job was it to unblock that?Answer that the author owns it, then show why: you have the full context, the change is yours, and reviewers are context-switching. Mentioning a manager or lead as a later escalation path is fine, but claiming it was someone else's responsibility is the answer this probe is hunting for.
- What if the call had not resolved it?Describe the next rung honestly: a written decision with the options, then a named decider or the owning group, with a deadline attached. Say what you would have shipped in the meantime — a smaller slice, a flagged-off path — so the answer shows the work moving even while the argument continues.
- How do you keep your own reviews from doing this?Turn it into author-side habits: smaller changes, stating the decision under debate in the description, marking which comments you consider blocking, and setting a round limit before you switch to a call. Two concrete habits beat a general commitment to communication.