The short answer: pick a real, work-focused disagreement that had stakes — a design choice, a code review, a priority call with a PM or your manager — and describe the other person’s position fairly before you explain yours. Spend most of the answer on the specific steps you took to resolve it (a conversation, a written comparison, a quick experiment), then close with the outcome, the state of the working relationship, and what you would do differently. Interviewers are not checking whether you won; they are checking whether you can disagree without damage and commit once a decision is made.
Below: what the question probes, which conflicts make good stories for engineers, a five-part structure, three worked examples, blame-free phrasing, and the follow-ups that separate a rehearsed story from a real one.
What interviewers are actually testing
Conflict is one of the most common behavioral topics in software engineering loops — the Tech Interview Handbook calls conflict resolution the most common soft-skill question. It comes in many wordings, but they all probe the same signal:
| Wording you might hear | What it is really asking |
|---|---|
| “Tell me about a conflict with a coworker.” | Can you work through friction with a peer directly? |
| “Tell me about a disagreement with your manager.” | Will you push back respectfully, and commit if you lose? |
| “A time you had a difference of opinion with a team member.” | Can you separate the idea from the person? |
| “A time you had to influence someone during a conflict.” | Do you persuade with evidence rather than rank or volume? |
| “How do you deal with difficult coworkers?” | Do you describe people fairly, or as villains? |
Across those variants, a strong answer shows four things:
- You can state the other side fairly. If you cannot explain why a reasonable person held the opposite view, the interviewer assumes you did not listen at the time either.
- You resolved it collaboratively — with data, a prototype, a written trade-off or a direct conversation, not by pulling rank or quietly giving up.
- You committed to the outcome. Amazon’s Have Backbone; Disagree and Commit principle asks people to challenge decisions respectfully, then commit fully once a decision is made. Other companies look for the same behavior without naming it.
- You learned something. A short reflection shows self-awareness, which matters more at senior levels, where you are expected to resolve conflicts and influence without authority.
Emphasis varies by company. For Meta, prep guides and candidate reports commonly list conflict resolution among the behavioral-round signals; at Amazon the question fits most naturally under Have Backbone; Disagree and Commit and Earn Trust (“listen attentively, speak candidly, and treat others respectfully”), both covered in our Amazon behavioral interview guide.
Pick the right conflict
The story you choose decides most of the outcome. For engineers, the best material is usually a disagreement about the work itself:
| Conflict type | Example | Watch out for |
|---|---|---|
| Technical design | Relational vs. document store, build vs. buy, where retries or caching should live | Too much architecture detail in the setup |
| Code review | A reviewer blocks your PR, or you block someone else’s | Making it about style nits rather than real risk |
| Priorities with a PM | Feature deadline vs. a reliability or tech-debt fix | Casting the PM as someone who “doesn’t get engineering” |
| Your manager | An estimate, a staffing call, a process change | Sounding like you still resent the decision |
| Cross-team | An API contract, ownership of a shared component, on-call boundaries | Blaming “the other team” as a group |
Avoid personality clashes with no work substance, anything that belongs with HR, trivial stakes (tabs vs. spaces), conflicts that never resolved, and ones your manager settled while you watched.
Prepare more than one. Have two or three conflict stories with different endings: one where you persuaded the other person, one where you were persuaded or lost and committed anyway, and one where you met in the middle. Three “I was right” stories in a row reads as stubbornness.
A five-part structure that works
This is STAR with two additions that matter for conflict questions: the other person’s view, and a reflection. For a full walkthrough of the base format, see our behavioral STAR examples.
- Context (one or two sentences). Your role, the project, and why the decision mattered.
- Both positions, stated fairly. Theirs first is a good habit: “Her concern was X, which was reasonable because Y. Mine was Z.”
- What you did (the bulk of the answer). Asking questions to understand their reasoning, moving the debate off a comment thread, writing a short options doc, agreeing on decision criteria, running a benchmark, proposing a middle path. Use “I” for your actions.
- Outcome. What was decided, what happened, and how the working relationship looked afterward. Use real numbers only.
- Reflection. One or two sentences on what you learned or would do differently.
Prep advice on length varies, but most of it lands between about 90 seconds and three minutes out loud. The first telling needs to be complete, not exhaustive; follow-ups will pull out the rest.
Three sample answers
These are illustrative answers, not scripts. Swap in your own project, details and results — the value is in the shape of each one.
1. A code review standoff with a senior peer (compromise)
Context: “I owned a service that sent order-status emails. A senior engineer on a neighboring team blocked my pull request adding retries to the sender; he wanted retries handled by the shared job queue.”
Positions: “His concern was that services retrying on their own could overwhelm the email provider during an outage — a fair point. Mine was that the queue migration would push a launch tied to a customer commitment back about two weeks.”
Action: “After two rounds of PR comments, I asked for a short call. I restated his concern to check I had it right and learned he had seen a retry storm take the provider down before. I proposed shipping with capped backoff and a circuit breaker behind a flag, and I took ownership of the queue migration for the next sprint. I summarized the decision on the PR so both teams could see it.”
Outcome and reflection: “He approved it, we launched on time, and I finished the migration the next sprint. He became one of my regular reviewers. The lesson: move a disagreement off text early — the comment thread made us both sound more dug in than we were.”
2. A priority clash with a product manager (persuaded, with an alternative)
Context and positions: “Two weeks before a release, our PM wanted to add a bulk export a large customer had requested. I knew the export path had a pagination bug that occasionally dropped rows. Her priority was the customer commitment; mine was not building on a data-correctness bug. Both were legitimate.”
Action: “Instead of debating it in standup, I reproduced the bug on a test account and brought her a one-page summary with two options and rough estimates: build now and accept the risk, or fix pagination first and ship a sprint later. I also asked what the customer needed by the date — a one-time file would cover them.”
Outcome and reflection: “We sent that customer a one-time export, fixed the bug, and shipped the feature the next sprint. We also started a short risk review before each release. I learned to ask what a deadline is protecting before arguing about it.”
3. Disagreeing with a tech lead and being wrong (committed)
This shape works well for interns and new grads, and is often the strongest story at any level.
Context and positions: “During my internship, my tech lead asked me to test a new endpoint against a real database. I argued mocks were faster and enough. Her view was that the team had been burned by mocks passing while the real schema had drifted.”
Action: “I asked to try both on one endpoint. The test against a containerized database caught a column-type mismatch the mocks passed right over. I showed her both and told her she was right.”
Outcome and reflection: “I wrote the remaining tests her way and added the mismatch to the team’s testing doc. What I learned: when someone experienced has a strong opinion, ask where it comes from — and if a disagreement is cheap to test, test it.”
Phrasing that keeps blame out of the story
Engineers already have a model for this: the blameless postmortem. Google’s SRE book describes postmortems that focus on contributing causes without indicting any individual or team. Tell a conflict story the same way — describe positions, incentives and constraints, not personalities.
| Instead of | Try |
|---|---|
| “He was being difficult.” | “We were optimizing for different things: he cared about provider stability, I cared about the launch date.” |
| “My manager just didn’t get it.” | “I hadn’t yet made the case in terms of what she was accountable for.” |
| “They were wrong.” | “I thought the risk was higher than they did, so I suggested we measure it.” |
| “The PM kept changing requirements.” | “Requirements were moving, so I proposed a weekly scope check-in.” |
| “So I escalated it.” | “We agreed to bring both options to our tech lead with a written comparison.” |
| “In the end I won.” | “We went with the queue-based design, and here is how it played out.” |
Three more habits help:
- Use “we” for the goal and “I” for your actions. “We both wanted the launch to go well; I suggested we prototype both options.”
- Leave names out. “A senior engineer on a partner team” is enough detail; names make it sound like a complaint.
- Keep your tone neutral. If you still sound annoyed telling it, pick a different story.
Follow-up questions to expect
Interviewers probe to check the story is real and to see how you think. Prepare short answers to these:
- “What was their point of view?” Give their strongest argument, not a strawman.
- “How did you feel? How did they feel?” Be honest (“frustrated, mostly about the timeline”) and show you noticed the other person.
- “Did you agree with the final decision?” If not, say so and explain how you committed anyway.
- “How is your relationship with them now?” A concrete sign helps: they review your code, you paired on the next project.
- “What would you do differently?” “Nothing” is a weak answer.
- “When do you escalate?” When you have both tried to resolve it, the decision is blocking work, and you can present the options fairly together.
- “Has someone disagreed with you and been right?” Your “I was wrong” story covers this.
Mistakes that sink the answer
- “I’ve never really had a conflict.” Interviewers tend to read this as avoidance or a story being held back.
- A villain story. If the other person sounds unreasonable, you sound hard to work with.
- Winning by rank or by going around someone. Even if it worked, it is the wrong signal.
- No resolution. “We just stopped working together” is not an ending.
- Claiming a group outcome as your own. If the team reached the decision together, say so; overclaiming invites follow-up questions you cannot answer well.
- Losing and not committing. Any hint that you slow-walked a decision is a red flag.
- An architecture lecture. Give enough technical context to make the stakes clear, then move on.
- A memorized script. It sounds fine until the first follow-up. Prepare bullets, not paragraphs.
How to prepare this answer in an hour
- Brainstorm (15 minutes). List every disagreement from the last two years: design reviews, code reviews, planning meetings, incidents, internship or team projects.
- Pick two or three (5 minutes). Choose different endings (persuaded, committed, compromise) and, ideally, different counterparts (peer, PM, manager).
- Outline each in five bullets (15 minutes). Context, both positions, actions, outcome, reflection. Note only numbers you can stand behind.
- Say them out loud and time them (15 minutes). Record yourself and cut setup that drags.
- Rehearse the follow-ups (10 minutes). Have a friend fire the questions from the follow-up list above at each story. Practicing alone, a free AI mock interview in CoPilot Interview reads behavioral questions built from your résumé and a job description aloud, then scores each spoken answer with what worked and what to improve.
One story can often serve several prompts — a conflict where you made a hard call might also answer a challenging project question.
Rehearse your conflict story out loud
Paste the job description and your résumé, pick a behavioral-heavy mix, and answer an AI interviewer out loud. Each answer gets a score with what worked and what to improve — free for 15 minutes a day, no credit card.
Try a free AI mock interviewFAQ
How long should my answer to a conflict question be?
Advice varies, but roughly 90 seconds to three minutes is a common target for the first telling. Keep the setup short, spend most of the time on what you did, and let the interviewer's follow-up questions pull out the extra detail.
What if I have never had a conflict at work?
Use a disagreement rather than a dramatic clash: a design choice, a code review, a priority call, or a conflict from an internship, team project or open-source work. Saying you have never disagreed with anyone tends to read as avoidance.
Can I talk about a conflict with my manager?
Yes, as long as you pushed back respectfully, backed your view with evidence, and committed to the final decision. Avoid any version where you still sound resentful or where you went around your manager.
Is it OK to tell a story where I turned out to be wrong?
Yes, and it is often one of the strongest answers. Admitting you were wrong, explaining what changed your mind and showing that you committed afterward demonstrates exactly the self-awareness the question is looking for.
Is escalating to my manager a bad answer?
Not by itself. Bringing a stuck decision to a tech lead or manager with both options written up fairly is a healthy move, but it should come after you tried to resolve it directly, not instead of trying.