The skill isn't being right. It's disagreeing in a way that changes the outcome and keeps the relationship.
Student edition · understand, apply, verify
Disagree on a design using a shared problem, evidence, alternatives, and clear decision authority.
What you should be able to do: Make a concern actionable while preserving safety escalation and willingness to revise your view.
A context-dependent practice guide, not a universal policy or verified personal history. Examples and numbers are illustrative. Use genuine, authorized evidence; personnel/privacy/legal decisions follow applicable organization policies and qualified review.
Concepts explained in this guide
Read these definitions first, or use the linked terms as you go. The examples and limitations are local to this guide; companion pages are optional.
Decision records and reversible experiments
Record the problem, options, evidence, constraints, owner, chosen tradeoff, and reconsideration trigger. A reversible test reduces uncertainty before large commitment.
Example. Try one tenant with success/abort metrics and a data-safe rollback plan.
Boundary. Timeboxing does not bypass compliance/safety. Reversible means effects and data can actually recover, not merely that a flag exists.
Stakeholders and alignment
A stakeholder is affected by or able to affect a decision. Alignment means understanding goals, constraints, tradeoffs, and the decision process; it does not require unanimous agreement.
Example. Finance values cost predictability, customers migration effort, and operations safe recovery. State these criteria before choosing.
Boundary. Consultation is not an unlimited veto. Name decision authority, required evidence, deadline, and escalation.
SBI feedback and observable behavior
Situation–Behavior–Impact frames feedback around context, observed action, and its effect. Ask for perspective and agree a concrete change.
Example. 'In Tuesday's review, you interrupted two explanations; we missed rollback discussion. What was happening, and how can we finish those discussions next time?'
Ownership names who drives follow-through; accountability names who answers for outcomes. Decision rights specify who chooses/approves and who is consulted.
Example. A migration has a coordinating owner, service owners, and named release authority.
Boundary. DRI/RACI/DACI are local conventions, not guarantees. Role labels do not replace authority, capacity, and follow-through.
STAR and CARL interview structure
STAR means Situation, Task, Action, Result. CARL means Context, Action, Result, Learning. They distinguish conditions, responsibility, personal decisions, and outcomes.
Example. Describe the team's problem, your role, what you personally changed, and measured results; add a tradeoff and learning.
Boundary. Use genuine safe-to-share evidence. A framework does not authorize invented achievements or someone else's story.
This is the behavioral question in the code-review track, and it's really an influence question wearing a technical hat. Anyone can leave a “this is wrong” comment. The senior move is to disagree in a way that actually moves the decision, doesn't burn the author, and holds up when you turn out to be partly wrong yourself. The interviewer wants a real story where you pushed back on a design or implementation you believed was a mistake — and they're grading how you did it: whether you led with data, proposed alternatives, separated blocking concerns from taste, escalated cleanly when needed, and committed once the call was made.
How to disagree well: understand and steelman their view, lead with data over opinion, separate blocking from taste, propose alternatives, escalate cleanly when stuck, then disagree-and-commit — with the relationship intact.
What this question is really testing
Whether you can hold a technical bar without being a jerk or a pushover. It probes your ego, your judgment about which hills to die on, and your ability to build alignment rather than win arguments. The trap answers are the two extremes: the person who never pushes back (no bar) and the person who pushes back on everything and can't let go (no judgment, damaged relationships). The signal is a story where the process of disagreeing was clean, the outcome improved, and the working relationship survived — ideally got stronger.
How to answer
Understanding missing constraints may change your view. Do not attach an unsupported frequency to how often this happens.
Lead with data, not opinion. “I think” loses to “here's the load test / the projection / the incident.” Anchor the disagreement in evidence — a benchmark, a cost model, a past SEV, a scaling projection — so it's about the problem, not about whose taste wins.
Separate blocking from taste. Be explicit about what genuinely blocks (a correctness, reliability, or scale risk) versus what's preference. Spending your credibility on nits means no one listens when it actually matters.
Propose alternatives, not just objections. “This won't scale” is criticism; “this won't scale past 2x, and here are two options that do, with these tradeoffs” is leadership. Give the author a path forward, not a wall.
Escalate cleanly when stuck. If you and the author loop, take it to the code owner, tech lead, or a design review for a tiebreak — framed as “let's get another opinion,” not “I'm going over your head.” Letting a diff rot in a stalemate helps no one.
Disagree and commit. Once the decision is made — even against you — get fully behind it and support the execution. Re-litigating a settled call is how you lose trust.
Preserve the relationship. Critique the design, never the person; keep it in the open, not in back channels; and make it clear you're on the same side. The next hard conversation depends on the trust you build in this one.
What the interviewer is looking for
Data and reasoning over authority or opinion.
Alternatives offered, not just objections raised.
Judgment about which battles are blocking vs which are taste.
Clean escalation as a tool, and genuine disagree-and-commit.
A relationship that survived — or improved — and self-awareness about times you were wrong.
A worked example (CARL)
Practice draft: first-person narratives below are not independently verified autobiographical evidence. Use their structure, not their claimed results; replace with your genuine safe-to-share experience.
CARL = Context, Actions, Results, Learnings. Spend most of your words on Actions — the specific moves only you made — and never skip Results or Learnings.
Context
A senior engineer on a partner team proposed a redesign of our ad-events ingestion path to cut end-to-end latency. The core idea was good, but the design dropped the per-stage instrumentation and the dead-letter handling that the existing pipeline had, in the name of “keeping the hot path lean.” It also assumed the upstream producer delivered events exactly once, so it removed the dedup step. The design doc had momentum — a director had praised the latency numbers — and the author was well respected. I was the reviewer on the first implementation diff and I believed shipping it as drafted would trade a latency win for a reliability and debuggability regression we'd pay for in a SEV.
Actions
I steelmanned it first. In my review comment I restated their goal and agreed with the core architecture explicitly, so it was clear I wasn't attacking the redesign — only two decisions inside it. That framing mattered given the momentum behind the doc.
I led with data, not opinion. Instead of “we need dedup,” I pulled the duplicate-event rate from Scuba for the upstream producer — it was non-zero and spiked during producer restarts — and linked a prior SEV where an un-deduped path double-counted revenue. The “exactly-once” assumption was demonstrably false in our own data.
I separated blocking from taste. I labeled two comments clearly: blocking — the removed dedup (a correctness risk backed by the duplicate-rate data) and the loss of a metric on the new fallback branch (a 2 AM-debuggability risk); non-blocking nit — my preference on how the stages were named. That signaled I wasn't going to fight about everything.
I proposed concrete alternatives. For dedup, I showed that an idempotency-key check against a bounded cache added well under the latency budget they were targeting, so they could keep the win and the correctness. For instrumentation, I offered a lightweight counter + latency histogram on the two failure branches rather than the heavier per-stage tracing they'd cut, so the hot path stayed lean but wasn't blind.
I moved it off the diff thread when it started to loop. After a couple of rounds where we were talking past each other on latency budget, I set up a 30-minute call with the author and the code owner, framed as “let's align on the reliability bar for this path,” and brought the duplicate-rate numbers and a one-page tradeoff table. We agreed on the idempotency-key approach in that meeting.
Results
The redesign shipped with the latency win largely intact — the idempotency check cost a small, measured fraction of the budget — and it kept dedup and the failure-branch instrumentation.
A counterfactual incident is an estimated risk, not an observed fact. Report the actual replay/measurement result and the limits of attributing prevention.
The author and I ended up collaborating on the next two pipeline changes; they later told me the tradeoff table was what changed their mind, not the seniority of anyone in the room.
Learnings
Evidence helps constrain a disagreement, but interpretation, uncertainty, competing goals, and decision rights still matter.
Give people a way to keep their win. The disagreement resolved fast because I showed how to preserve their latency goal, not just why their approach was wrong. Pushback lands when it's additive.
Escalation is a tool, not a failure. Moving to a short call with the owner wasn't going over anyone's head — it was the fastest path to a decision, and framing it that way kept it clean.
Common follow-ups
Tell me about a time you pushed back and turned out to be wrong.
How to answer
Own it plainly. Pick a real one where the author had context you lacked, and show you updated fast once you saw it.
Highlight the process, not the verdict. Even when wrong, leading with questions and data surfaced the missing context cleanly.
Show the learning. It's why you now steelman and ask before asserting.
How do you push back on someone more senior than you?
How to answer
Same rules, more data. Seniority gap makes evidence and framing matter more, not less.
Ask, don't accuse. “How does this handle X?” invites reasoning and often surfaces you're missing context.
Escalate to a neutral forum. A design review depersonalizes it — the bar decides, not the title.
What if, after all that, the decision goes against you?
How to answer
Disagree and commit — for real. Support the execution fully; don't re-litigate or quietly sandbag.
Reserve the exception. Only refuse to commit for a genuine ethics/safety/legal line, and then escalate formally.
Leave a marker. If it's high-stakes, note the risk and the trigger that would revisit it — without “I told you so.”
How do you keep pushback from damaging the relationship?
How to answer
Attack the problem, not the person. Every comment about the design; never about their competence.
Be generous in public, direct in private. Praise the good parts openly; handle a persistent pattern in a 1:1.
Bank trust early. A reputation for being fair and often right is what makes the hard reviews land.
Evidence to collect with your approved tools
A decision/review record with the problem, constraints, options, and your contribution.
Relevant tests, dashboards, or measurements with definitions, denominators, dates, and uncertainty.
Incident or delivery records showing actual outcomes and unresolved limitations.
Stakeholder agreements and follow-up actions with owners and review dates.
Only authorized, minimized, safe-to-share evidence. Do not copy confidential personnel notes into a public story.
Worked example: a latency win removes dedup
This is an illustrative situation. The point is the reasoning and evidence, not copying the numbers or first-person story.
Sequence for this example. The table explains the evidence and decision at each step.
Step
Evidence, decision, and expected result
Restate the goal
The author wants lower latency. Confirm the true constraints and failure model before rejecting the approach.
Show a failure trace
A repeated event increments billing twice, or a separate seen marker can lose a contribution on crash.
Offer a safe alternative
Measure a transactionally coupled idempotent contribution or another supported design within the latency budget.
Record the decision and review trigger
Agree on owners/evidence; support an authorized safe choice while continuing formal escalation for unresolved material safety/legal issues.
Check your understanding: Does 'disagree and commit' mean ignoring new evidence?
No. Record reconsideration triggers and reopen when assumptions or material risk change. It does not override safety/compliance obligations.
Practice with your own situation
Choose one relevant real situation. Write its context, constraints, your role, considered alternatives, chosen actions, measured result, uncertainty, and follow-up. Explain one tradeoff and what evidence would change your decision.
Use genuine, safe-to-share evidence. Example numbers here illustrate reasoning; they are not claims about your work or a guaranteed outcome.
