Pushing Back on a Design or Implementation
The skill isn't being right. It's disagreeing in a way that changes the outcome and keeps the relationship.
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.
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- Understand and steelman first. Before disagreeing, state their design back to them accurately and assume there's context you're missing. Half the time the “pushback” dissolves once you understand a constraint you didn't know about.
- 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.
- 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)
CARL = Context, Actions, Results, Learnings. Spend most of your words on Actions — the specific moves only you made — and never skip Results or Learnings.
ContextA 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.
- 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.
- Two months later a producer restart caused a duplicate spike; the dedup path absorbed it and the new counters showed exactly what happened. That would have been a revenue-miscount SEV under the original design.
- 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.
- Data ends debates that opinions extend. The single most effective move was replacing “I think this is risky” with the actual duplicate-rate graph. Pre-loading evidence is worth more than being senior.
- 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.
- Phabricator — the review thread where you pushed back, labeled blocking vs nit, and proposed the alternative.
- Design-review docs — the doc and comments where a disagreement was resolved, and the tradeoff table you brought.
- Scuba / ODS / Unidash — the metric (duplicate rate, latency, cost) you used to turn opinion into evidence.
- SEV / postmortems — the incident that either validated your concern or taught you the context you'd missed.
- GSD — the project/milestone the disagreement affected, to show the stakes and the outcome.