Engineers disagree about designs all the time, and interviewers know it. So when they ask you to describe a disagreement with a teammate, they aren’t checking whether you have conflicts. They’re checking how you have them, because they’re picturing you in their next design review. The tempting answer is a story where you were right and everyone eventually came around. It feels like a good answer, and it usually isn’t: interviewers aren’t scoring who won.
What the interviewer is listening for
A strong disagreement story has four things in it:
- A shared goal. You and the other person wanted the same outcome and disagreed about how to get there.
- A fair account of the other view. You can explain their reasoning in terms they’d recognize.
- A decision process. Criteria, evidence, and someone who made the call.
- What happened after. Especially how you behaved if the decision didn’t go your way.
Missing the second one is the most common failure. If the other engineer comes across as foolish or stubborn, the interviewer wonders what they’d say about you.
Worked example: two ways to cache a product page
Here’s an illustrative scenario. The details are invented to show the structure; your own story will have different specifics.
Your team’s product detail page is slow, around 900 ms at the 95th percentile against a 200 ms target, mostly because each request calls the pricing service. You propose a shared Redis cache with a five-minute expiry. Another engineer on the team proposes an in-process cache on each server, cleared whenever a price-change event arrives. Their worry is stale prices; yours is twelve servers each holding a slightly different copy. The pull request thread gets longer and sharper over two days.
Weak version (illustrative):
A colleague wanted to use an in-memory cache, which obviously doesn’t scale across servers. I explained why Redis was the better choice, showed them some articles, and eventually they came around and we went with my design.
The colleague is a prop, the “decision” is them giving up, and the interviewer learns only that you like being right.
Stronger version (illustrative; replace with your own disagreement):
Our product page was missing its latency target, and another engineer and I disagreed on the cache design. I wanted a shared Redis cache with a five-minute expiry; they wanted an in-process cache cleared by price-change events, because they were worried about customers seeing stale prices. After two days of increasingly long PR comments, I suggested we stop writing and talk for twenty minutes.
On the call I started by summarizing their concern back to them, and they did the same for mine, which took some of the heat out. We realized we’d never agreed on how stale a price could be. So we asked the product manager, who said the listing page could be up to a minute behind, as long as checkout always used the live price. That ruled out my five-minute expiry.
We then ran both designs against a staging load test for an afternoon. Both met the latency target. The in-process version showed servers disagreeing on a price for several seconds after each change, which the product manager didn’t want. We ended up with a shared Redis cache using a sixty-second expiry plus their event-driven invalidation, so a price change cleared the cache immediately. I implemented the cache; they wrote the event consumer. The page came in under target, and that design is still running.
The colleague’s concern shaped the final design, the disagreement was resolved by requirements and data rather than by persistence, and the candidate’s role (proposing the call, the summarizing, implementing the cache) is clear.
Criteria before solutions
The turning point in that story is the question about staleness. It’s common for two engineers to argue for days about designs when what they actually disagree about is an unstated requirement. One of them assumes prices can be a few minutes old, the other assumes they can’t, and every argument about Redis or in-process caching is really an argument about that.
So a useful move, in real life and in your interview answer, is to list the criteria before comparing options: the latency target, the staleness tolerance, the operating cost, and who decides if the criteria conflict. Once those are written down, many disagreements resolve themselves, and the ones that don’t become a smaller question that someone with authority can answer quickly.
A small experiment is the other tool worth mentioning. An afternoon of load testing is cheaper than a week of comments, and it changes the conversation from opinion to evidence.
When the decision goes against you
Some of the best conflict stories end with the candidate losing. Amazon’s leadership principles describe the expected behavior as “Have Backbone; Disagree and Commit”: challenge a decision respectfully when you disagree, and once it’s made, commit to it fully.
In an interview, committing means you show what you did after the decision. Suppose the team had chosen the in-process cache. A strong ending might be: “I still had concerns about servers disagreeing, so I said so once, clearly, and then built the event consumer with them. I also added a metric for price mismatches between servers so we’d see it if it became a problem. It stayed low for the three months I was on the team.” That shows conviction, cooperation and judgment, without any “I told you so.”
Red flags in disagreement answers
- The villain. “They were being difficult” makes the interviewer side with the absent colleague.
- Victory as the outcome. “I convinced them” with no change to your own view suggests you don’t listen.
- Escalation as the first move. Going to the manager before talking directly to the other person reads as conflict avoidance.
- A personal conflict. Disputes about desks, schedules or personalities are harder to tell well than disagreements about work.
- “I don’t really have conflicts.” That suggests either low involvement or low self-awareness.
Follow-up questions to expect
“What would you have done if they still disagreed after the load test?” A good answer names a decider: agree together to take a short written summary of both options to the tech lead, and accept their call.
“How is your working relationship with them now?” Be honest. If it was strained for a while, say what you did to repair it.
“What did you learn about how you argue?” Something specific works best, like “I now ask what the requirement is before defending a design.”
Interview practice: disagreeing with someone more senior
A harder variation: “Tell me about a time you disagreed with your manager or a more senior engineer.” How does the answer change?
Answer and reasoning
The structure stays the same, but the interviewer is now also watching how you handle a power difference. They want to see that you raised the disagreement rather than complying silently, that you did it respectfully and with evidence, and that you accepted their authority to decide.
A reasoned answer covers three points. First, how you raised it: privately or in an appropriate forum, with data rather than in front of the whole team as a challenge. Second, how you framed it: in terms of the shared goal (“I’m worried this rollout date puts the migration at risk, and here’s why”) rather than “you’re wrong.” Third, what happened: if they changed their mind, what persuaded them; if they didn’t, how you committed and what you did to reduce the risk you’d raised.
What hurts the answer is either extreme: never pushing back on a senior person, or a story where you went around them to get your way. The interviewer wants someone who will tell them uncomfortable things and then help carry out the decision.
Related guides on working with others
- Behavioral and HR interview questions
- Behavioral and HR multiple-choice questions
- Behavioral: Working with a Difficult Stakeholder
- Behavioral Interviews: Receiving Difficult Feedback
- Amazon Leadership Principles, including Disagree and Commit