How to answer

Tell me about a time you had a conflict with a coworker

The STAR framework

1

Situation

Briefly set the scene — who, when, what was at stake.

2

Task

Your specific responsibility — what you owned, not what the team did.

3

Action

Concrete steps you took. First person. Quantify wherever possible.

4

Result

Measurable outcome + what you learned.

Almost every behavioral loop contains a version of this prompt, and it is one of the few questions where the wrong answer is “I do not really have conflicts with coworkers.” Interviewers are not auditing your niceness. They are checking whether you can sit across from a colleague who disagrees with you, name the disagreement, and walk out with the relationship intact. CPP Global’s workplace conflict report found the average employee spends 2.8 hours per week on conflict at work — roughly a third of a workday — so claiming you have never had one reads less like virtue and more like denial. This guide covers how to answer tell me about a time you had a conflict with a coworker using STAR, with 15 examples across engineers, PMs, designers, and managers.

Why interviewers ask this

The surface read is conflict resolution: can you de-escalate a disagreement without it spilling into the rest of the team. The deeper read is emotional regulation. When somebody pushes back on your work, or you push back on theirs, what is your first move? Do you withdraw and stew? Escalate to your manager before talking to the person? Drop a passive-aggressive line in the next standup? The interviewer is mapping your default and predicting how their team’s Slack will read in six months.

Hiring managers are not looking for a story where you never have conflict, and they are not looking for one where you were obviously right and your coworker was obviously wrong. As The Muse and HBR’s guidance on difficult conversations both note, the signal is in how you treated the other person — whether you assumed competence, looked for the shared goal, and named what you contributed. “My coworker was being unreasonable and I fixed it” is the most common bad answer because it telegraphs low self-awareness in one sentence. The candidates who get hired pick a real disagreement, take partial ownership, and end on a resolution that did not require anybody to lose.

The STAR framework

STAR — situation, task, action, result — keeps this answer from drifting into either gossip or vagueness. Target a 90-second spoken answer with the action paragraph carrying about half. The pitfall is different from other STAR questions: candidates over-explain the situation because they want the interviewer to side with them, and under-explain the action because the action is uncomfortable to narrate.

Situation (two sentences). A specific disagreement at work — not bullying, not harassment, not anything that should have gone to HR. A scope dispute, a technical disagreement, a missed handoff, a turf overlap. Name the project and the person’s role (not their name), and what the two of you actually disagreed about.

Task (one sentence). What outcome you were on the hook for, and why the disagreement was blocking it. If the conflict had no business stakes, pick a different story.

Action (three to five sentences). The load-bearing part. Did you go talk to them directly? What did you open with? Where did you concede? Where did they? The interviewer is listening for whether you led with curiosity (“help me understand why you think X”) or judgment (“you are wrong because Y”). Name the specific moment the conversation turned.

Result (two sentences). What got unblocked, what changed in the working relationship, and what you now do earlier. A conflict story without a working-relationship outcome reads as a one-time fix.

15 sample answers

Each example is one disagreement, one move, one resolution. Aim for 60–90 seconds spoken, roughly 70 words on the page.

Backend engineer vs. PM, scope. “The PM wanted three features in a two-week sprint and I knew the data layer could not absorb all three. Instead of pushing back in standup, I booked 20 minutes with him, walked through the migration risk, and offered two features with tests or all three behind a flag. He picked the two-feature plan and started looping me into scoping the next quarter.”

Designer vs. PM, scope creep. “A PM kept adding screens to a flow mid-sprint. I had vented about it for a week before realizing I had never said no out loud. I sent her a Loom showing the dependency chain, asked which three screens were launch-critical, and she cut six. We shipped two days early. Now I ask the scoping question on day one.”

Two peer engineers, territory. “Another engineer and I both believed the auth module was ‘ours’ and kept overwriting each other’s PRs. I asked for coffee, said it directly — ‘we are stepping on each other and I am part of the problem’ — and we wrote a one-page ownership doc that afternoon. We co-led the next refactor.”

IC vs. manager, priority. “My manager wanted me on a migration I thought was lower-value than a reliability project the team kept punting. I wrote a one-page memo with the incident data, asked for 15 minutes, and said I disagreed but would do what he decided. He read it, switched my quarter to reliability, and the migration moved to the next hire.”

Product manager vs. engineering lead, estimate. “The eng lead’s estimate was triple what I had committed to leadership. My first reaction was frustration. Instead of pushing back, I asked him to walk me through where the time went, and three line items were things I had not scoped. I went back to leadership, re-cut the launch into two phases, and we shipped phase one on the original date.”

Designer vs. engineer, feasibility. “An engineer kept marking my designs as ‘not buildable’ without details. I stopped reacting in tickets and pulled him into a 30-minute working session with the design open. Half my interactions were expensive and half trivial — but he could not tell me which until we sat together. We built a shared ‘cheap vs. expensive’ rubric the rest of the team adopted.”

Customer success vs. sales, handoff. “Sales kept closing deals on promises CS could not deliver, and I had been escalating to my director instead of to the AE. I owned that, went directly to the AE, said the handoff was breaking the customer, and proposed a 10-minute pre-close call. Renewal rate on his accounts went from 62% to 84% the next quarter.”

Marketing manager vs. brand lead, voice. “Brand wanted to rewrite every ad I shipped. I had been working around her by shipping to channels she did not watch — which was the real problem. I owned it, set up a weekly 30-minute review where she signed off before launch, and stopped going around her. Ads shipped faster because rework dropped from 40% to under 10%.”

Data scientist vs. analyst, methodology. “An analyst on a sister team was using a metric definition that contradicted mine, and we kept presenting conflicting numbers in leadership reviews. I reached out, suggested we co-author one definition doc, and let her name the metric. The doc became the company-wide definition.”

Engineering manager vs. peer manager, headcount. “Another EM and I both wanted the same senior hire and were lobbying our director separately. I went to him directly, said this would look bad if we kept doing it, and we agreed to a one-page rubric. He got the hire, I got priority on the next one, and we co-ran the next loop.”

Junior engineer vs. tech lead, code review. “A tech lead was leaving harsh code review comments that demoralized the team. I was the most junior but also the most affected. I asked for 15 minutes, said the comments were landing badly even when the technical points were right, and offered a few rewrites. He took the feedback and team PR throughput came back.”

PM vs. designer, A/B test. “A designer pushed back hard on a test result because she did not believe the variant. Instead of dismissing her, I sat with her and re-ran the segment cuts. She was right that one segment had been mis-attributed. We re-ran the test cleanly, the winner flipped, and we caught a tagging bug that had affected three other tests.”

Operations lead vs. finance, process. “Finance wanted weekly forecasts; I thought monthly was enough. We kept missing each other’s deadlines. I asked her what decision the weekly number unblocked, learned it was a cash-flow call I had not known about, and switched to weekly. She dropped a separate report I had been duplicating. We saved each other about three hours a week.”

Sales rep vs. solutions engineer, demo. “An SE and I disagreed on whether to demo a feature that was still buggy. I had been pushing, he had been refusing. I dropped my position when he showed me the latest support ticket. We co-wrote a ‘do not demo’ list, and my close rate went up because we stopped breaking trust on calls.”

Senior engineer vs. junior peer, mentoring. “A junior kept pushing back on my code reviews in ways that felt personal. I asked for a coffee and said I wanted to understand how my feedback was landing. My comments were short to the point of feeling dismissive. I rewrote my review style — more ‘why’, less ‘change this’ — and his PR pickup rate doubled.”

What NOT to say

The bad answers are predictable. The interviewer has heard each many times, and they signal the same thing: you have not done the reflective work.

Avoid these patterns:
  • "I never really have conflict at work." Reads as evasive or oblivious. Every functioning team disagrees. Saying you do not signals you either avoid hard conversations or do not notice them.
  • Badmouthing the coworker. "She was difficult, he was incompetent, they were political." How you describe an absent colleague to a stranger is exactly how you will describe future colleagues to your next manager.
  • HR-level conflict. Harassment, bullying, discrimination, physical confrontation — these should have gone to HR, and the interview is not the venue. Pick a professional disagreement.
  • No resolution. A story that ends with "we just stopped working together" or "I transferred teams" is a complaint, not a behavior signal.
  • "I was right and they were wrong." Even when you were, framing it this way removes you from the story. Hiring managers want to hear what you contributed to the friction, not just the fix.
  • Going over their head first. A story that starts with "so I went to my manager about it" before you tried talking to the person tells the interviewer how you will handle disagreements with them.

Closing move and practice routine

The best closing move on this question is a one-sentence rule you took from the experience — something concrete you now do earlier. “Since then I book the direct conversation before I escalate.” “Since then I ask which deadline the other person is working toward before I argue about mine.” That sentence is the line the interviewer writes down, because it proves the conflict produced a behavior change rather than just a story.

To practice, pick two real workplace disagreements from your last two roles. For each, draft the four STAR beats on an index card and time the action paragraph out loud. If it runs under 30 seconds, you are skipping the uncomfortable part — the actual conversation — and the interviewer will feel the gap. If it runs over 90, you are litigating who was right; cut it.

Then rotate each story against three framings: conflict with a coworker, disagreement with a manager, time you gave difficult feedback. The same situation usually fits more than one — two well-rehearsed stories across three framings will carry you through most behavioral loops. The candidates who sound calm on this question are not the ones with more drama in their history. They are the ones who have rehearsed naming the other person’s perspective out loud, in their own voice, without flinching. That is the entire signal the question is built to test.