Tell me about a time you disagreed with a reviewer's comment and pushed back.
answer
- name the comment and what it demanded
- state their concern fairly, out loud
- the evidence, not the opinion
- what you conceded, said explicitly
- the decision that landed and its result
basics
~20 sProbes whether you can hold a technical position without making it a contest. Answer with one comment you genuinely disagreed with, the reviewer's concern stated fairly, the evidence you brought, and the decision that landed.
how to answer
5 beats- the change and the comment that blocked itSet up in two or three sentences: what you were shipping and exactly what the reviewer asked you to do differently. Keep setup and stakes to roughly fifteen to twenty percent of the answer.
- their concern, stated fairlySteelman it out loud. Saying what was genuinely right about the objection before you argue with it is the single strongest move in this answer, and it inoculates you against sounding defensive.
- the evidence you brought backName the number, benchmark, incident history or reproduction that the disagreement actually turned on. Opinion against opinion is the failure mode this beat exists to avoid.
- what you conceded and what you heldBe explicit about both halves. Together with the previous beat this should carry about sixty percent of your airtime, because it is where judgement is visible.
- the decision that landed, and the resultClose on the actual outcome — often a third option neither of you started with — plus what it produced in production. About twenty percent of the answer, and never leave the decision unnamed.
your answer
5 story prompts- Choose a disagreement where the reviewer had a real point, not one where they were simply wrong.
- Write the reviewer's concern in one sentence they would agree with before you write yours.
- Find the number, benchmark or incident history the argument actually turned on.
- Name the exact thing you conceded — an answer with no concession sounds rehearsed.
- Note whether the landed decision was yours, theirs, or a third option.
draft and rehearse your own answer in a learn session
go deeper
This probes conflict resolution and technical judgement together: can you defend a position with evidence, absorb the part of the objection that is right, and reach a decision without turning the thread into a status contest. A strong answer proves your disagreements produce better designs rather than stalled changes and bruised reviewers.
Part-way through moving our enterprise services onto a managed secret store, I put up the change that decided what a service does when the store is unreachable. My reviewer wanted a hard fail-closed: no secret, no start, no requests served. I thought that traded one risk for a worse one. I did not argue in the thread first. I pulled the store's availability history for the previous quarter — three brownouts, the longest of them nine minutes — and worked out what fail-closed would have done to us: every service in that tier restarting into a crash loop during a nine-minute blip, which is an outage we would have caused ourselves. I posted that with the numbers and said explicitly that I agreed with their threat model and disagreed on blast radius. They came back with the case I had not weighted: a compromised credential staying live in memory for as long as the process runs. That was fair. We landed on a bounded grace window instead — keep serving on the cached lease for ninety seconds, alarm the moment the store goes unreachable, hard-fail after that. Neither of our opening positions. Fourteen services cut over on it with no auth-related incident, and the rotation cadence held at seven days. I still use that move: bring the number the disagreement turns on, and name the part of their argument I accept.
What carries this is bringing outage history rather than a preference, and saying aloud which half of the objection was accepted. The landed design is a third option, which is the outcome interviewers reward. Replacing the numbers with 'I explained my reasoning' would downlevel it immediately.
I was accountable for the credential migration across the estate, and the design I circulated had the rotation orchestrator rotate on a schedule with no human in the loop. A principal engineer in the security group blocked it in review: every rotation should require an explicit human approval. My first move was to check I had their reason right, so I restated it back to them. They had been burned by an automated job that revoked something live, and they wanted a person between the tool and production. I said the concern was legitimate and that my objection was cost, not principle — fifty-eight services on a weekly cadence is roughly two hundred and fifty approvals a month, and approvals at that rate get rubber-stamped, which buys the appearance of control rather than control. Then I stopped doing this in comments. I wrote a two-page decision record with three options and what each cost in toil and in exposure, and asked for twenty-five minutes with them and our operations lead. We agreed on tiering: automatic below tier one, manual approval plus a paired change for the two tier-one systems, an audit trail either way. Median rotation lag across the estate went from forty-six days to six, with those two staying manual by design. I also wrote in a date to revisit the tiering — conceding a point is cheaper when the concession has a review date.
The senior moves are restating the objection before arguing, quantifying the cost of the reviewer's proposal rather than dismissing it, and changing medium from comment thread to written decision plus a short call. The revisit date is what makes the compromise durable; without it this reads as a one-off negotiation.
Pushing back at all is the signal — show you asked a real question rather than silently complying, and that you accepted the answer when it came with a reason you could follow.
Bring a number, a benchmark or a reproduction to the thread, and name explicitly which part of the reviewer's argument you accepted. Compromise designs beat clean wins here.
The disagreement should be about a decision with production consequences, and the answer should show you moving it out of comments into a document or a short call once it stopped converging.
Show disagreement across an organisational boundary — a security, platform or architecture group with its own mandate — resolved by a written decision and a review date rather than by who outranked whom.
saying these in an interview costs you the question
- Straw-manning the reviewer so your position wins easily
- Winning by seniority, tenure or 'I owned that service'
- No evidence — just two preferences and a louder voice
- Conceding nothing at all, which reads as unable to update
- Escalating to a manager as the first move rather than the last
- Leaving the outcome vague so no decision is ever named
- What would you have done if they still said no?Answer with the disagree-and-commit position: you would implement it, record the objection in writing so it is revisitable, and name what evidence would reopen it. Interviewers are checking that you have a ceiling on your own persistence and that a blocked change still ships.
- Have you ever pushed back and been wrong?Say yes and give the short version — the assumption you had, what disproved it, and what you told the reviewer afterwards. A candidate who cannot produce one of these looks like someone who never updates. Keep it to thirty seconds and do not fold it into a second full story.
- How did that reviewer treat your next change?Use this to prove the disagreement was about the work rather than about you. Concrete evidence works best: they reviewed faster, they pinged you on a related design, the two of you set a convention together. Avoid the empty claim that there were no hard feelings.