"Tell me about a time you had a conflict with a coworker" is one of the few behavioral questions you can count on. It shows up because the interviewer wants to know one thing: are you someone they can put on a team without creating a mess.
That's the whole point of the question. They're not curious about your drama. They're checking whether you can disagree with another adult, work through it, and keep shipping. So your answer has to do two jobs at once. Tell a real story, and prove you're easy to work with under tension.
Here's a structure that does both.
The structure
Use four beats. Situation, the disagreement, what you did, the outcome. It's STAR with the conflict made explicit.
- Set the scene fast. One or two sentences. What were you building, who was the other person, why did your paths cross.
- State the disagreement plainly. What did you want, what did they want, and why did it matter. No villain.
- Say what you actually did. This is the part that counts. Concrete actions, in order.
- Land the outcome. What happened, and ideally what you took away from it.
Most people spend too long on beats 1 and 2 and rush beat 3. Flip that. The actions are the answer.
A worked example
"On a payments project, a backend engineer and I disagreed about where validation should live. I wanted it in the API layer so the frontend could trust the responses. He wanted it in the database constraints so nothing bad could ever get written, full stop.
We were both partly right, and we'd been going back and forth in pull request comments for two days, which was going nowhere.
So I asked him to grab fifteen minutes on a call. I came in assuming his constraint was non-negotiable and asked him to walk me through why. Turned out he'd been burned by a data corruption bug at his last job, so the database guarantee mattered to him a lot. Once I understood that, I proposed we do both: keep his constraints, and add the API validation on top so we'd get clean error messages instead of raw database errors. He was fine with it because it didn't remove his safety net.
We shipped it that week. After that we started hashing out design questions on a quick call before they turned into long comment threads."
That's under a minute and a half spoken. Notice what it does. It names a real technical disagreement, it makes the other person reasonable, and the resolution comes from understanding his position, not from winning.
The traps
Making the other person the bad guy. The fastest way to fail this question is to tell a story where you were right and they were a problem. The interviewer hears that and thinks, this is what they'll say about me someday. Give the other person a legitimate reason for their position, even if you disagreed with it.
Picking a conflict that isn't one. "Someone wasn't pulling their weight so I told my manager" isn't a conflict you resolved, it's an escalation. Pick a story where you were directly involved in working it out.
Going personality, not substance. "We just had different working styles" is vague and a little worrying. A disagreement about a technical decision, a deadline, or a priority is concrete and safe. It shows you can fight about the work without making it about the person.
No resolution. If the story ends with "and then I left the team" or "we never really fixed it," find a different story. You don't need a fairy tale, but you need to have done something that moved it forward.
How to prep this without sounding scripted
Write down two or three real conflicts from your last couple of roles. For each, fill in the four beats in plain bullet points, not a script. The goal is to know the shape of the story, not to memorize sentences.
Then say it out loud. The first time you tell one of these stories it always runs long and wanders. By the third time it's tight. A mock interview is the easiest way to get those reps, because saying it to another person is different from rehearsing in your head.
One more thing. If you genuinely can't think of a conflict, that's usually a memory problem, not a calm-life problem. Think about a code review that got tense, a deadline two people saw differently, a design call where you pushed back. Small disagreements handled well make perfectly good answers.
The question isn't a trap. It's a chance to show you can disagree without being difficult, which is a real and rare skill. Pick a true story, be fair to the other person, and spend your words on what you did.