"How Do You Disagree With a Senior Engineer?": Evidence, Proportion, and Knowing When to Commit

Architects spend a large part of their week disagreeing with people who outrank them, people who report to them, and people who own the roadmap. The interview question “how do you disagree with a senior engineer” is asking whether you can do that without either of the two failure modes: caving and resenting it, or fighting and losing the room. It is the companion to the decision-went-wrong post. That one tests ownership when you were wrong. This one tests judgment when you think someone else is.

By the end of this post you will have a two-sentence philosophy, a playbook that scales the pushback to the stakes, a way to choose a story that shows both backbone and humility, and the follow-ups that separate people who have done this from people who have read about it.

The Question

The direct forms:

• “How do you disagree with a senior engineer?”
• “Tell me about a time you disagreed with your tech lead or manager on a technical decision.”
• “Tell me about a time you were overruled. What did you do?”
• “A staff engineer wants to do X and you think it is wrong. Walk me through it.”
• “How do you handle conflict about a design?”

The variants lean different ways. “Overruled” is testing what you did after losing. “Walk me through it” is testing the playbook in real time. The direct form is testing whether you have a philosophy at all. One story, told well, covers all of them.

What They Are Really Asking

1. Will you say the thing? An architect who defers to seniority is not doing the job. The interviewer wants evidence that you have pushed back on someone with more rank and lived to tell it.
2. Can you make it about the decision and not the person? The word to listen for is “evidence.” Opinion versus opinion is decided by rank. Evidence versus opinion is decided by evidence.
3. Do you calibrate? A disagreement about a variable name and a disagreement about the primary data store deserve different amounts of energy. The interviewer wants to hear that you spend your pushback where the decision is hard to reverse.
4. Do you know when to stop? Once the decision is made, do you commit, or do you relitigate, comply maliciously, or wait to say “I told you so”? “Disagree and commit” is the phrase they are waiting for, and they want to hear that you actually do the second half.
5. Can you be wrong gracefully? The best stories include the moment you discovered the senior engineer knew something you did not. A candidate who is always right in their own stories is either lucky or lying.
6. Are you safe to promote? An architect disagrees with directors and VPs. The interviewer is picturing you in that room.

A weak answer is “I present my case respectfully and defer to their experience.” That is the answer of someone who has never changed a senior engineer’s mind and does not expect to. A strong answer has a playbook, a real story with stakes, evidence that changed the outcome, and a clear account of what you did after the decision.

The Gotchas

Gotcha 1: “I have never really had a disagreement.” Either you have not worked on anything that mattered or you are not telling the truth. Both are disqualifying for a role that is mostly disagreements.

Gotcha 2: The hero story. “They wanted X, I knew it was wrong, I proved it, we did it my way.” The interviewer hears arrogance and immediately wonders about the stories where you were wrong. Include the part where they had a point.

Gotcha 3: Going around them. Escalating before talking to them, lobbying peers in private, or raising it with their manager first. This is political, and interviewers have seen where it leads. The first conversation is with the person.

Gotcha 4: Disagreeing in the wrong room. Contradicting a senior engineer in front of their team or the executive they report to, before you have talked privately, turns a design question into a status contest. Venue and timing are part of the skill.

Gotcha 5: Opinion versus opinion. “I felt the event-driven approach was better.” So did they feel the opposite. Without a prototype, a number, a failure-mode analysis, or a document, you brought nothing that rank cannot override.

Gotcha 6: Confusing a preference with a risk. Pushing hard on a stylistic choice spends the credibility you need for the choice that loses data. Say out loud that you rank disagreements by reversibility and consequence.

Gotcha 7: Not asking what would change their mind. The single most useful question in a technical disagreement, and the one most candidates never mention. It converts an argument into an experiment.

Gotcha 8: Relitigating after the decision. Bringing it up in every subsequent meeting, or building the escape hatch quietly. That is the quiet version of “I told you so,” and everyone can see it.

Gotcha 9: Caving silently. The opposite failure. You stated your concern once, it was dismissed, you stopped. Then the thing you predicted happened and you had nothing on record. Disagreement that matters gets written down, with the reasoning, before the commit.

Gotcha 10: Making it about seniority. “Even though they were a staff engineer, I stood my ground.” The rank is context, not the story. The story is the evidence and the decision.

Gotcha 11: Not closing the loop. What happened? Were they right, were you, was it mixed? What did you learn about how that person thinks, and how did that change the next disagreement? Without the ending, the story is a complaint.

How to Answer

Step 1: State the philosophy in two sentences

Lead with this, before the story. It tells the interviewer you have thought about it as a practice, not an incident.

I treat disagreement as something I owe the decision, not a contest with the person. I make it about evidence rather than opinion, I push harder the less reversible the decision is, and once it is made I commit to it fully and write down what would make us revisit.

That is four ideas in two sentences: duty to the decision, evidence, proportionality, and commitment. Everything after it is illustration.

Step 2: The playbook

Step	What you do	Why it matters
Understand first	Restate their position better than they did. Ask what constraint or history they see that you might not	Half of disagreements dissolve here. The other half get sharper, which is also progress
Locate the real disagreement	Is it about facts, predictions, priorities, or risk tolerance?	Facts and predictions can be tested. Priorities belong to whoever owns them. Risk tolerance is a conversation about consequences
Bring evidence	A number, a prototype or spike, a failure-mode walkthrough, a one-page document	Opinion loses to rank. Evidence does not have a rank
Ask what would change their mind	And say what would change yours	Turns an argument into an experiment with agreed success criteria
Choose the venue	Private first. Then the design review with the document. Escalate only transparently, and tell them you are doing it	Nobody changes their mind while being embarrassed
Calibrate to reversibility	Two-way door: say it once, clearly, and let it go. One-way door: insist on a written decision, propose the cheapest experiment, and escalate if the risk is unacceptable	This is the same one-way and two-way door framing as the decision post, from the other side
Decide and commit	Record the decision and the dissent in an ADR (Architecture Decision Record) with a revisit trigger. Then execute as if it were your idea	The written dissent is not for “I told you so.” It is so the revisit trigger is objective
Close the loop	When the trigger fires or the outcome is known, say so plainly, either way	This is what makes the next disagreement cheaper

Step 3: Choose the story

Criterion	Why it matters
Real stakes: a data store, a boundary, a vendor, a launch	Preference disputes do not show judgment
You brought evidence that changed something	Proves the playbook is real
The senior engineer had a point you initially missed	Shows you can be wrong and still hold a position
The decision was made explicitly and you committed	Proves the second half of “disagree and commit”
You know how it turned out	A story without an ending is a complaint
No villains	The senior engineer in your story is competent and acting in good faith. If they are not, pick another story

Prepare two. One where evidence changed their mind. One where you were overruled, committed, and it worked out, or it did not and the revisit trigger fired and you handled that too. Interviewers often ask for the second after hearing the first, and having it ready answers “can you be wrong gracefully” before they ask.

Step 4: Tell it in six beats

Beat	What to say	Time
1. The disagreement	One sentence: what they wanted, what you thought, what was at stake	15 seconds
2. Understanding their view	What you asked, what you learned, what they were optimizing for	30 seconds
3. The evidence	What you built, measured, or wrote, and what it showed	40 seconds
4. The decision	How it was made, by whom, in what forum, and what was written down	30 seconds
5. After the decision	What you did once it was settled, especially if you lost	30 seconds
6. The outcome and the lesson	Who was right, what you learned about them and about yourself	30 seconds

About three minutes. Then stop and let them ask.

Step 5: A worked example

An illustrative composite, not a specific real project.

The disagreement. A staff engineer wanted the order service to call the inventory service synchronously to reserve stock during checkout. I thought it should be asynchronous through an event, because I was worried about the failure modes of a synchronous chain under load. The stake was the checkout path of the main product before a launch.

Understanding their view. I asked what they were optimizing for. Two things I had underweighted: the team had never run an event-driven flow in production and had no tooling for it, and the product needed the buyer to see “reserved” before paying, which is awkward with an asynchronous reservation. Those were real.

The evidence. I wrote a one-page failure-mode walkthrough for both options: what happens when inventory is slow, down, or returns an error, in each design. I also spent a day measuring the latency budget: the synchronous call fit inside the checkout target with margin, which I had not expected. And I asked what would change their mind. They said: show me the operational cost is manageable. I could not, honestly, for that team at that time.

The decision. We took it to the design review with both documents. The decision was a hybrid: synchronous reservation, because it fit the budget and matched the product need, with a short timeout and an explicit fallback that lets checkout proceed and reconciles afterward, which was the part I cared about most. Everything after the reservation went asynchronous through an outbox. The staff engineer wrote the ADR and recorded my concern about the synchronous chain with a trigger: if the p99 of checkout crossed a threshold or inventory caused more than a set number of incidents in a quarter, we would revisit.

After the decision. I built the fallback path and the outbox, and I did not bring the topic up again. When a junior engineer asked me later why we had not gone fully asynchronous, I gave the staff engineer’s reasons, not mine.

The outcome. The synchronous reservation held through the launch. Two quarters later the incident trigger fired, and because it was written down the revisit was a fifteen-minute conversation instead of a fight. We moved reservation to an asynchronous hold with a pending state at that point, when the team was ready for it. Both of us were partly right, and the thing I learned was that “operationally ready” is a real constraint that belongs in the failure-mode analysis, not a soft objection to argue past.

Notice: the senior engineer is competent and right about two things. The evidence is concrete. The decision is explicit and written. The commitment is demonstrated by a specific behavior, giving their reasons to the junior engineer. The revisit trigger did its job. And the lesson is about the candidate, not about the other person.

Step 6: The language

Phrases that work, because they separate the decision from the person and invite evidence:

• “Help me understand what you are optimizing for.”
• “What would change your mind? Here is what would change mine.”
• “I might be wrong about X. Here is the test that would tell us.”
• “I disagree, and I will commit. Can we write down the trigger that would make us revisit?”
• “Let me make your argument back to you and you tell me if I have it right.”

Phrases that lose, because they make it about rank or about being right:

• “With all due respect.” Everyone hears the opposite.
• “I have been doing this for years.” So have they.
• “As I said before.” You are relitigating.
• “I told you so,” in any of its forms, including the quiet ones.

Step 7: Say how you receive disagreement

Architect interviewers are also asking the mirror question. Close with a sentence about being the senior person in the room:

The other half of this is making it cheap for people to disagree with me. I ask for the strongest counterargument before I share my view, I write decisions down so they can be challenged on the merits, and I make a point of saying publicly when someone junior changed my mind.

That sentence converts “can you disagree upward” into “can you run a team where disagreement is normal,” which is the job.

Follow-Up Questions to Expect

• “What if they are wrong and will not budge?” Two-way door: commit and set a trigger. One-way door with unacceptable risk: tell them you are going to escalate, escalate with the document, and accept the outcome. Never escalate silently.
• “Have you ever been wrong in one of these?” Yes, and have the story ready. The senior engineer knew something about the team, the history, or the product that you did not. Say what it was.
• “What if it is your manager instead of a peer?” Same playbook. The venue matters more and the written record matters more. Managers appreciate being disagreed with privately, with evidence, before the meeting where it counts.
• “What if it is about priorities, not facts?” Name it as a priorities question and route it to whoever owns the priority. Engineers arguing about product priorities in the guise of a technical debate is a common waste, and recognizing it is a senior skill.
• “How do you disagree with someone junior?” More carefully, because the power difference makes your disagreement heavier than you intend. Ask more, assert less, and make sure the decision is theirs when it is in their scope.
• “How do you make it safe for others to disagree with you?” Ask for the counterargument first. Write decisions down. Thank people specifically and publicly when they change your mind. Never punish a wrong prediction that was made in good faith.

Key Takeaways

• Disagreement is owed to the decision, not aimed at the person. Say that first.
• Evidence beats rank. Opinion does not. Bring a number, a spike, or a document.
• Ask what would change their mind, and say what would change yours.
• Calibrate to reversibility. Spend your pushback on one-way doors.
• Private first, then the design review, then transparent escalation if the risk warrants it.
• Once decided, commit fully and record the dissent with a trigger. No relitigating, no quiet escape hatches.
• Choose a story where the senior engineer had a point. Prepare a second where you were overruled.
• Close with how you make it safe for others to disagree with you.

Further Reading

• Jeff Bezos, 2016 shareholder letter (the origin of “disagree and commit” as most engineers use it)
• Amazon, Leadership Principles: Have Backbone; Disagree and Commit
• Kim Scott, Radical Candor, on caring personally while challenging directly
• Google re:Work, Understand team effectiveness (psychological safety, from Project Aristotle)
• Michael Nygard, Documenting Architecture Decisions (where the dissent and the trigger get written down)