"Tell me about a disagreement with a coworker (or manager) and how you handled it" is one of the most frequent behavioral questions — and the easiest to botch. The interviewer isn't asking whether you won the argument, but: can you depersonalize? Do you seek to understand first? Can you resolve via shared goals and data rather than rank or volume? And was the relationship preserved?
Three easy ways to botch it: ① "I was right, they were wrong" — egotistical, poor collaborator; ② blaming the other person (they were just unreasonable) — instant minus; ③ "I've never had a conflict" — reads as spineless or lacking self-awareness (a senior engineer can't have zero conflicts).
This post shows how to use STAR to turn a technical disagreement into a story of maturity, plus the other half of the question: disagreeing with your manager — "Disagree and Commit."
First: The "Bonus Signals" for Conflict Questions
| Signal | Anti-example | The bonus framing |
|---|---|---|
| Issue, not person | "He was stubborn" | "We disagreed on the approach, but shared the goal" |
| Understand before asserting | rebut immediately | "I first asked why he argued for it" |
| Resolve with data/prototype | who's louder | "We ran a small experiment and let data decide" |
| Preserve the relationship | burn the bridge | "We reached consensus and collaborated better after" |
| Able to commit | sulk if you lose | "Even when it wasn't my approach, I executed fully" |
💡 Core idea: the protagonist of a conflict story isn't the disagreement — it's how you steered the disagreement toward the best outcome for the team while preserving the relationship. Show "issue not person + objective criteria + willingness to commit" and you score.
Worked Script (English, ~270 words) — A Technical Dispute with a Coworker
The scenario is illustrative; swap in your own real experience.
"[S] A senior teammate and I disagreed on the technical approach for a feature. He argued to scrap the old module and rewrite it; I thought that was too risky and we should refactor incrementally. The timeline was tight, both of us held our ground, and the discussion stalled.
[T] My goal wasn't 'to convince him to do it my way' but to find the best approach for the project without damaging the working relationship.
[A] I did three things. First, understand his position: instead of rushing to rebut, I asked why he wanted a rewrite — and found his real concern was 'the old code's tech debt makes every change painful,' which I actually agreed with. Once we found the shared goal (reduce tech debt), the disagreement shifted from 'opposing sides' to 'different paths to the same problem.' Second, replace subjective argument with objective criteria: I proposed we stop debating with words and each do a small spike to measure how long 'rewrite' vs 'incremental refactor' would actually take on this module, and the risk. Third, let data decide: the spike showed a full rewrite was indeed high-risk, but his core tech-debt concern could be resolved in two phases via my incremental path. We landed on a compromise: incrementally refactor the most painful debt now, schedule the full rewrite next quarter.
[R] It shipped on time with no rewrite-induced delay; more importantly, because I understood him first and then aligned via data, he never felt attacked, and we collaborated even better afterward. My lesson: the best resolution to a technical dispute isn't winning the argument — it's turning 'people in opposition' back into 'a shared inquiry into the problem,' then converging with objective evidence."
The Other Half: Disagreeing with Your Manager — Disagree and Commit
Disagreeing with your manager is a common advanced follow-up (and an Amazon Leadership Principle: Have Backbone; Disagree and Commit). The key is to show: the backbone to voice a reasoned objection, but once a decision is made, execute fully without passive resistance.
Script (English, ~120 words): "My manager decided to prioritize a certain feature; I assessed it and thought we should pay down tech debt first. I neither stayed silent nor pushed back in the room — privately, with data, I explained: 'If we don't address these first, the risks could surface next quarter.' I made my concern and evidence clear. He listened but, based on broader business context, still chose the feature. At that point I did disagree and commit — I'd fully voiced my objection, and once the team decided, I executed it wholeheartedly instead of grumbling along the way. I also kept tracking the risks I'd worried about and raised early warnings — turning my concern into something useful for the team."
The Follow-ups Interviewers Love (prepare these)
-
🎤 "If the other person's approach was ultimately chosen, what would you do?" → Show disagree and commit directly: I'd fully voiced my view; once decided, I execute wholeheartedly — passive resistance only hurts the team. This is exactly the maturity they want.
-
🎤 "What if you're sure you're right but can't convince them?" → Emphasize objective criteria: rather than each digging in, I'd turn it into a verifiable question (a small experiment / data / a third-party expert) and let facts decide, not who's more insistent.
-
🎤 "Did the conflict damage your relationship?" → Show relationship care: because I stayed issue-focused and understood them first, they didn't feel targeted; I also checked in afterward, and we collaborated better.
-
🎤 "With your manager, who turned out right?" → Honest but mature: regardless of who was right, the point is I voiced my objection and respected the decision while executing fully; I kept tracking the risk and would warn early if my concern materialized — turning 'I told you so' into 'I helped the team prepare.'
💡 Principle for follow-ups: conflict follow-ups test "do you just want to prove you're right." Always return to "issue not person → objective criteria → willing to commit → preserve the relationship."
Polish Checklist (apply to your own story)
- Pick a real, issue-focused, constructively-resolved conflict (not personal/emotional)
- Action includes "understand their position first" (not rushing to rebut)
- Must include "resolve via a shared goal or objective data" (not rank/volume)
- Be ready for "if their approach was chosen" → disagree and commit
- Result lands on both "good outcome + relationship preserved/improved"
- Avoid the three landmines: I'm-right-they're-wrong, blame-shifting, no-conflicts
- Same structure in both languages; say it out loud, keep to 2-2.5 minutes
Wrap-Up
What the conflict question really asks is: when you disagree, can you turn 'people in opposition' back into 'a shared inquiry into the problem,' converge with objective criteria, and — once decided — execute fully while preserving the relationship? That's the core of collaborative maturity. A "technical-approach dispute resolved by understanding first + a small experiment" works well — because it shows not how good you are at arguing, but how good you are at steering disagreement toward the team's best outcome.
Write it as STAR, center it on "issue not person + resolve with data + disagree and commit," and close on "good outcome + better relationship." That turns the question from "I argued with someone" into "I handle disagreement maturely" — and the latter is who teams want. This is the seventh post in the STAR series; with overcoming a technical challenge, fast learning, ownership, failure lessons, ambiguous requirements, plus self-introduction and the motivation questions, it forms a complete behavioral interview prep kit.