Conflict with a Teammate
Practice this question in a realistic, spoken behavioral interview.
Tell me about a time you had a conflict or a significant disagreement with a teammate.
The best conflict stories show two engineers who both had defensible reasons for their position, then worked through to a decision the team could live with. Pick a disagreement where you can explain what your teammate was optimizing for as fairly as your own argument, what evidence shifted the conversation, what you conceded, and what compromise or decision shipped in the end.
What the Story Needs to Make Clear
The useful details are in the disagreement itself and the way it moved toward a decision:
- Keep the conflict professional: Use a disagreement about the work: architecture, scope, process, quality bar, or priorities. Personality-clash stories are hard to recover from.
- Show the other view as reasonable: Explain what your teammate was optimizing for, even if you disagreed. The best conflict stories have two defensible positions, not a hero and a villain.
- Handle it directly and privately: Walk through the conversation you initiated, rather than describing side conversations, quiet resentment, or a manager pulled in as referee.
- Use evidence to move the discussion: Bring in data, user impact, benchmarks, design principles, or a small experiment that changed the discussion.
- End on the team outcome: Close on getting to a better decision because both perspectives were worked through, not on who won the argument.
Where This Answer Usually Goes Wrong
The failure modes here are subtle. A conflict story can sound fine in the room and still downgrade the writeup on Earn Trust or Collaboration:
- Claiming you have never had conflict: This signals either limited experience or low self-awareness, and at any level above L3 it gives nothing to grade on Has Backbone / Disagree and Commit. If you genuinely cannot recall a workplace conflict, use a code-review disagreement or a design-doc debate. Those count.
- Using the story to prove you were right: If the other person exists only to be wrong, the answer comes across as arrogant. Framing the conflict as a winner-loser dynamic tends to drop the Earn Trust score by a full grade.
- The personal-grudge story: "This guy was always so annoying, and one time..." Personality-clash framing raises the question of how you will describe your future coworkers. Keep it on observable work behavior.
- Escalating to a manager as the first move: "We disagreed, so I immediately went to our manager" skips the peer-level work the question is probing. Escalation is appropriate sometimes, but the stronger story shows what you tried first. Skipping to it weakens the Influence signal.
- A conflict that ended with you giving up: "I just let them have their way to keep the peace" signals lack of conviction. A good answer either ends in a real compromise, a defensible concession (you were convinced by their argument), or an honest admission that the team picked the other path and you supported it.
- The clean-compromise resolution every time: Stories where you and your teammate "talked it out and aligned" feel pre-packaged. Real conflicts have residue. A small acknowledgment that the working relationship was tense for a week, or that you still slightly disagree with the eventual decision, makes the story credible.
- No evidence beyond opinion: "I argued that approach X was better" without bringing data, a benchmark, a prior incident, or a customer signal is conviction without judgment. On senior loops this reads as argument by assertion.
How This Answer Changes by Level
Conflict stories scale up the stakes, not the volume:
At staff+, "conflict with a teammate" usually means a strategic disagreement with another senior engineer or a partner team's leader. A peer-to-peer Go-vs-Python debate at L7 sounds underleveled.
How to Describe the Conversation
Spend time on the moment where the disagreement became productive. Re-establish the shared goal, state your case with evidence, listen for what they were protecting, then explain how you got to a decision: a compromise, an experiment, or conceding because their argument was stronger. Aim for a solution both of you can stand behind.
How to Build the Story
Situation
Set up the professional disagreement and what each side believed would produce the better engineering outcome.
- Example: "I was working with another senior engineer, John, on designing a new microservice. I was advocating for us to write it in Go, because of its performance and concurrency benefits for this specific use case. John was strongly in favor of using Python, because that's what the rest of our company's stack was written in, and it would be more familiar to the team."
Task
Frame the decision you were trying to protect as the best technical choice for the team and the company, rather than your personal preference.
- Example: "We were both passionate about making the right long-term decision, but we were at a stalemate. My goal was to resolve this disagreement so we could move forward with the project."
Action
Show the conversation in order: the shared goal, your view, their view, and the joint solution.
- Re-establish the shared goal: "I asked John to grab a coffee so we could discuss it away from the keyboard. I started by saying, 'Look, I know we both want this service to be a success. We're on the same team here.' This immediately de-escalated the tension."
- State your case calmly: "I then calmly laid out my case for Go, focusing on the data. I showed him some benchmarks I had run that demonstrated a 3x performance improvement for our specific workload."
- Listen to theirs: "Then, I stopped arguing my side and asked him to walk me through what worried him. His strongest point was the maintenance burden of a one-off service in a language most of the team did not know. He was optimizing for team consistency."
- Converge: "After hearing his points, I realized he was right about the team impact. I proposed a compromise. I said, 'What if we write this service in Python, but isolate the expensive part and test whether async processing gets us close enough?' He still preferred the simpler path, but the benchmark gave us a concrete way to decide. We moved forward with Python and documented the performance assumption we were accepting."
Result
Close with both outcomes: what decision shipped, and how the disagreement changed the working relationship.
- Example: "The result was that we built the service in Python with a narrower async section around the slow operation. It met the immediate performance target and was easier for the rest of the team to maintain than a new-language service would have been. More importantly, the disagreement became less personal because we had named what each of us was optimizing for. On later design discussions, we were quicker to ask, 'What trade-off are we actually debating?'"
This answer works because the goal was the right technical decision, not who got their preferred option. Listening to John's concerns, running a real benchmark, and accepting the trade-off showed engineering judgment over ego.
Three-Tier Scoring on the Conflict Question
The conflict question is graded against Earn Trust, Has Backbone, and Influence. The tiers:
The Mediocre tier on conflict is almost always either "I've never had one" (no signal) or a personality complaint about the other person (red flag). What lifts an answer to the top tier is showing that you changed your mind during the disagreement, rather than holding your ground until the other party gave in.
Harder Variant: When the Conflict Did Not Resolve Cleanly
The clean Go-vs-Python compromise above is the easy version of this question. The follow-ups often push toward harder variants: a conflict you handled badly, a conflict that ended in escalation, or a conflict where the other person was acting in bad faith. Here is a sample answer that handles one of these.
"About a year ago, I was the senior engineer on a small team rebuilding our reporting service. Another senior engineer, who had been at the company longer than me, kept rewriting parts of my code during reviews without discussing the changes. He would push his version directly to my branch, sometimes overnight, and then mark my PR as approved.
I tried to handle it directly first. I asked him to grab coffee and said something like, 'I noticed you've been pushing changes to my branches. I'd rather we discuss them in the PR thread first.' He pushed back. He said his approach was faster, he had more context on the codebase, and review comments were slowing the team down. I asked if there were specific patterns he was correcting, in case I was missing something. His answer was vague.
The conversation did not change his behavior. Over the next two weeks the same pattern continued. At that point I made the judgment that this was not a peer-level disagreement anymore; it was about how we operated as a team. I went to our manager, and I tried to frame it carefully: I described the behavior, I shared two specific PRs as examples, and I said I wanted his help thinking about whether this was a process I should adapt to or a pattern worth addressing.
Our manager talked to him separately. The behavior mostly stopped. The working relationship between the two of us stayed cordial but cool for a few months. We worked through it eventually by partnering on a smaller project where the scope was clear and the ownership was split.
What I would do differently now is escalate earlier. I waited two weeks because I wanted to be sure I had tried peer-level resolution, but in retrospect after the first conversation it was clear my peer was not going to change unilaterally. The cost of waiting was a worse PR experience for two more weeks and more accumulated frustration on both sides. That earlier escalation calibration is something I'm faster about now."
What this version does that the cleaner one cannot:
- Honest escalation: The candidate tried peer-level first, made the judgment call to escalate, and explained the reasoning. On senior loops, that calibration is what the follow-ups dig for.
- A relationship that did not heal completely: "Cordial but cool for a few months" is a believable outcome. Stories where the difficult relationship becomes a warm friendship sound made up.
- A self-critical note that costs the candidate something: "I waited two weeks. The right answer was probably one week." That admission scores higher than the polished resolution.
- No naming of the other engineer's character: The candidate describes the behavior, not the person.
The easier conflict version usually draws one or two follow-ups. The harder version draws three or four, all circling the same calibration question: when did you escalate, why then, and what did you change about your judgment afterward.