Conflict Questions

Conflict questions check whether you can understand the other side, disagree with evidence, and reach a decision without burning the relationship.

How It Works

"Tell me about a conflict with a coworker" isn't checking whether you've had one. Everyone has. The interviewer wants to know how you act when you disagree: whether you try to understand the other person, argue from evidence instead of frustration, and get to a decision the team can live with. Underneath, they're asking whether you'd be easy to work with on a hard day.

Pick a disagreement about the work: a design choice, a deadline, a priority, how much to test before shipping. Skip personality clashes, and skip stories where the other person is the villain. If they had no good reason for their position, the story says more about how you see colleagues than about how you handle conflict. The best stories have a reasonable person on the other side, with a point you came to respect.

Also skip stories where you were simply right. "I showed them the data and they agreed" leaves out the part being scored. Interviewers want the middle: how you found out why they disagreed, what changed your mind, and how the two of you got to a decision.

  1. Understand their side. What did they want, and why? Say how you found out: a one-on-one, a question, reading their design doc.
  2. Disagree with evidence. What did you bring besides an opinion: data, a prototype, a past incident, a cost estimate?
  3. Escalate sensibly, if you need to. Taking a stuck decision to a manager together is fine. Going around someone isn't.
  4. Reach a resolution. What was decided, and who decided it?
  5. Keep the relationship. How did you work together afterward?

Expectations scale with level. Early in your career, a disagreement with a peer over an approach or a code review is a good story. Senior candidates should have conflicts with more at stake: with their manager, another team's lead, or a product partner over scope, where they had to find a path that worked for both sides. Either way, expect follow-up questions like "What if they'd still said no?" and "How do you two get along now?"

What Interviewers Listen For

  • Whether you tried to understand the other person's reasons before arguing.
  • Evidence over heat: what you brought besides a strong opinion.
  • Whether you escalated at the right time, to the right person, and openly.
  • A real resolution, even if it wasn't the one you wanted.
  • How you talk about the other person, and whether you still work well together.

How It's Asked

The same question comes in many wordings. Any of these wants the same kind of story.

  • Tell me about a time you had a conflict with a coworker.
  • Tell me about a time you disagreed with your manager.
  • Describe a time you pushed back on a decision.
  • Tell me about a time you worked with a difficult person.
  • Tell me about a time someone disagreed with your approach. How did you handle it?
  • Give me an example of a time you and a teammate couldn't agree on how to build something.
  • Tell me about a time you worked with a team whose priorities clashed with yours.

Sample Answers

The Question

Tell me about a time you disagreed with a coworker.

Try drafting your own answer first, then compare. Both answers are invented.

Show Sample Answers

A Common Answer

Yeah, so there was a senior engineer on my team who was really hard to work with. He'd block my pull requests over small things and always wanted everything done his way. I tried to explain my approach but he just wouldn't listen. Eventually I went to my manager, she agreed with me, and after that things were fine. I think the lesson is that sometimes you have to stand up for yourself.

A Strong Answer

At a fintech startup I owned the backend for our accounts API. The mobile lead wanted a new endpoint that returned the whole account screen in one response, so the app would make one call instead of six. I didn't want it. It would tie our release schedule to the app's screen layout and be hard to cache. In a design review it got tense, and he said backend always slows mobile down.

I realized I'd been defending my design without understanding his problem, so I asked him for a half-hour call. He showed me their data: on slow connections the account screen took 4.2 seconds to load at the 90th percentile, and app reviews were complaining about it. That changed how I saw it. His problem was real, even if I still doubted his fix.

So I went looking for evidence instead of arguing. Our latency logs showed two of the six calls were slow because of a missing database index, not because of round trips. I proposed a two-week experiment: I'd add the index, his team would make the remaining calls in parallel, and if the screen wasn't under two seconds at the 90th percentile, I'd build his endpoint. We agreed that if the numbers didn't settle it, we'd take it to our managers together.

The account screen dropped from 4.2 seconds to 1.6, so we didn't need the combined endpoint there. But when we ran the same check on the checkout screen, his approach won. Its calls depended on each other and couldn't run in parallel, so I built a combined endpoint for checkout. We now share a latency dashboard and meet once a month. What I'd do differently is ask for his data before the design review. Defending my design in front of ten people made it harder for both of us to change our minds.

Why It Works

  • The weak answer makes the coworker a villain and ends with a manager picking a side. It describes a conflict but shows nothing about how the candidate handles one.
  • The strong answer starts by understanding the other side, and finds that his problem was real. That's what changes the conversation.
  • The disagreement is settled by evidence and a test both people agreed to in advance, and the candidate concedes the checkout screen. Being partly wrong makes the story more believable.
  • It ends on the working relationship and a reflection about the candidate's own behavior, not the other person's.

Common Pitfalls

  • Telling a villain story. If the other person sounds unreasonable, the interviewer wonders how you'd describe your next team.
  • Picking a story where you were simply right and they gave in. There's no middle to score.
  • Choosing a conflict that's too small to matter, like a naming convention, or too personal, like a clash of personalities.
  • Escalating as your first move, or going around someone. Interviewers listen for whether you talked to the person first.
  • Claiming you never have conflicts. It sounds either unaware or evasive.