INTERVIEW QUESTION
Tell me about a time you had a conflict (or disagreed with a coworker): how to answer
Show the other person's view fairly, how you worked it out with them, and what you did once the decision was made, even if it went their way.
Most people have a disagreement they could use for this question. The trouble is that the one they reach for first is the one they won, and telling it turns into a case for why the other person was wrong.
That's usually the weaker story. The best conflict stories are often ones where you didn't win, because they show you really weighed the other view, as an engineer on r/ExperiencedDevs puts it. What gets judged is how you worked it out with the person, and what you did once the decision was made, whichever way it went.
This page is about disagreements you were part of, with a peer, your manager or someone on another team. If you were in the middle, handling a client or two groups who wanted different things, that's a stakeholder management question, and it needs a different answer.
What interviewers listen for
Candidates tend to spend their time on the problem and the outcome, and skip the middle. The middle is what's being judged: what each of you thought, what you tried, and how the decision got made. The process is the informative part, according to another engineer in the same thread.
For individual contributors, the test underneath is usually “disagree and commit”. Could you argue your case, then get fully behind the decision once it was made? That's mostly what one hiring engineer looks for. For managers, the same interviewer looks for running the trade-off discussion and accepting that someone has to decide.
The same expectation appears in Amazon's leadership principles: challenge respectfully when you disagree, then commit wholly once a decision is made.
Committing isn't the same as giving in. A hiring manager on Reddit listens for two things: that you can look honestly at your own part, and that you're not a pushover when what the other person wants really is unreasonable. Getting that balance across starts with which disagreement you choose.
Choosing a disagreement to tell
Pick a disagreement about the work, such as a design, a date, a method or what the data showed. Clashes of personality are harder to tell well and harder to judge. A good story shows you kept it about the work, even when it got tense.
Then check that it mattered. A disagreement with real consequences, where you had a reason to care, sounds genuine. One candidate on Reddit found their safe, diplomatic answer came across as fake. A real disagreement, told from both sides with what they'd change, went much better.
Match the stakes to the level you're applying for. For senior roles, an easy disagreement can read as a sign you weren't working at that level, as one senior engineer points out.
Some stories don't belong here: harassment, a grievance that's still open, or someone you still resent. If telling it means criticizing a person at length, pick another.
Within those limits, be more honest than feels comfortable. Say what you actually thought at the time, including if you were annoyed, and where you were wrong. A story where you were reasonable at every step is the one that sounds rehearsed.
A popular low-risk choice is two people giving you clashing assignments. It works here only if you show how you handled the two people; if the story is really about what you dropped, it belongs on the prioritization question.
Once you have the right disagreement, the telling follows a fairly fixed order.
How to tell it
What the disagreement was about. One or two sentences: who, which decision, and what each of you wanted. If the interviewer can't say what you disagreed about, nothing after it lands.
Their view, fairly. Explain why their position made sense from where they stood. Hiring managers want to know whether you can describe a charged situation objectively, as a hiring manager on r/interviews puts it.
What you did with them. The evidence you gathered, a prototype or test, a one-to-one conversation before the group meeting.
Who decided, and what you did next. If it didn't go your way, say how you committed: what you built, said or stopped arguing about. If it did, say what you conceded and whether you'd have committed as fully the other way; that answers the follow-up before it comes.
The relationship afterwards. One line on how working together went after. If some of the friction was your doing, say so here.
That's the STAR order, with most of the time on the action.
Follow-ups usually land on the last two steps: “What did you do once the decision was made?” and “How was the working relationship afterwards?” If you practice out loud with Kora, you pick your role, answer behavioral questions out loud, get a follow-up when your answer leaves out an important detail, and get feedback after each answer.
Example answers
In each made-up stronger answer, the other person's reasons come before the candidate's own action, and several of the candidates didn't get their way. Check whether yours explains why the other side thought they were right.
Software engineer
Question: “Tell me about a time you disagreed with another engineer, a PM or your manager about a technical decision.”
Weaker
“A senior engineer on my team wanted to add a caching layer that I thought was overkill. I knew it would add complexity we didn't need, so I pushed back hard in the design review.
Eventually the team saw my point and we went with my simpler approach, which worked fine. I think it shows I'm not afraid to speak up.”
The other engineer's reasons never appear, “the team saw my point” skips how the decision was made, and the story is mainly about being right.
Stronger
“Our tech lead wanted to move our job queue to a new message broker. I thought we should tune the database-backed queue we already had, because the team knew it well and the broker meant new on-call work.
Her worry was fair. Our traffic was doubling every few months, and she'd been paged twice for queue backlogs.
Instead of arguing in the review, I asked for two days to load-test my option. It held at about three times our traffic, but not at the five times she was planning for. I shared the numbers with her first, then with the team.
She decided on the broker. I said I still thought it was early, and then I took on writing the runbook, because on-call was my main concern. We still work together closely, and she now asks me to load-test her designs.”
The tech lead's case is told fairly, the disagreement was settled with a test rather than a debate, and the candidate lost and still took on the part they'd worried about.
Follow-ups to expect: What was the other person's view, and why did they hold it? What did you do once the decision was made?
Product manager
Question: “Tell me about a time you disagreed with an engineer, a designer or your manager about a product decision.”
Weaker
“My engineering lead wanted to delay our launch to fix tech debt, but the business needed the feature. I explained the business priorities and escalated to our director, who agreed with me, so we launched on time.”
Going to the director is the first move, the engineering lead's concern is waved away as tech debt, and nothing is said about the relationship afterwards.
Stronger
“Our engineering lead wanted to delay a new bulk-import feature by three weeks to rewrite the file parser. I wanted to launch on the date, because we'd announced it for our customer conference.
His concern was real. In testing, the parser had failed without any error message on very large files, and customers would think their data had imported when it hadn't.
We sat down with the usage data and found that only about 3% of accounts ever uploaded files that large. We agreed to launch on the date with a size limit and a clear error message above it, and to rewrite the parser in the next sprint.
I'd underestimated how much that silent failure had worried him. Since then, I bring him in before I commit to a date in public.”
The disagreement is about something specific, the two of them worked it out without escalating, and the candidate names what they got wrong about the other person.
Follow-ups to expect: What data or example did you use to back up your view? How was the working relationship afterwards?
Product designer
Question: “Tell me about a time you disagreed with a PM, an engineer or your manager about a design decision.”
Weaker
“An engineer told me my design couldn't be built. I knew it could, because I'd seen other apps do it, so I showed him examples and in the end he built it. It shows I fight for the user.”
The engineer's reason for saying no is missing, “fight for the user” frames it as a contest, and the interviewer can't tell what the constraint was.
Stronger
“I designed a drag-and-drop way to reorder items in a list. Our front-end engineer said it wasn't worth building, because our component library didn't support it on mobile, and building it ourselves would take most of a sprint.
I thought reordering mattered, because it was the second most common request in our support tickets.
So I asked what would be cheap to build. He said up and down arrows on each item would take a day. I tested both versions with five users. Drag and drop was quicker on desktop, but on mobile people found the arrows easier.
We shipped arrows everywhere, with drag and drop on desktop the following month. I'd assumed my version was better for everyone, and I was wrong about mobile.”
The engineer's constraint is concrete, a quick test settled it rather than opinion, and the candidate admits part of their own position didn't hold up.
Follow-ups to expect: What was the other person's view, and why did they hold it? How was the working relationship afterwards?
Data analyst
Question: “Tell me about a time you disagreed with your manager or a stakeholder about an analysis.”
Weaker
“My manager wanted to report a metric in a way I thought was misleading. I told him the data didn't support it, but he went ahead anyway. I learned that sometimes you have to pick your battles.”
There's no detail on the metric or the manager's reasoning, and “pick your battles” sounds like giving up rather than committing.
Stronger
“My manager wanted to report that our new onboarding emails had raised activation by 12%. I thought most of that was seasonal, because the emails launched in January, when activation always rises.
His view was reasonable. Leadership needed a number that week, and we had no control group.
I compared the same weeks in the last two years and found the usual January rise was about 8%. I showed him privately before the review, rather than raising it in front of his boss.
He still decided to report the 12%, and he added a note that some of it was likely seasonal. I wrote that note with him. I'd have done it differently, but it was his call, and the note was honest. Next time, we set up a holdout group before the launch.”
The candidate argued with data, raised it privately, lost, and helped make the final version honest. The change that followed is concrete.
Follow-ups to expect: What data or example did you use to back up your view? What did you do once the decision was made?
Program manager
Question: “Tell me about a time you disagreed with an engineering lead or a stakeholder about a program decision.”
Weaker
“The engineering lead and I disagreed about whether we were ready to launch. I felt strongly that we weren't, so I raised it with leadership and they delayed the launch. It was the right call.”
The disagreement isn't described, the engineering lead's reasons are missing, and the candidate went over their head without trying to settle it first.
Stronger
“We were three weeks from moving our warehouses onto a new inventory system. I wanted to move one warehouse first. The engineering lead wanted to move all four at once.
His reasoning was solid. Running two systems side by side meant syncing data between them, and he thought that sync was riskier than the move itself.
We spent an afternoon listing what could go wrong with each plan. On my plan, the sync was the biggest risk. On his, if something broke, every warehouse would stop shipping at once.
We agreed on all four warehouses at once, but on a Sunday, with the old system kept ready to switch back to for 48 hours. I didn't get my plan, and I set up the switch-back checklist and ran the weekend call. We didn't need to switch back.”
Both plans and their risks are named, the two of them worked it out without escalating, and the candidate committed to a plan that wasn't theirs.
Follow-ups to expect: What was decided in the end? How was the working relationship afterwards?
Consultant
Question: “Tell me about a time you disagreed with a senior colleague about a recommendation.”
Weaker
“My engagement manager wanted to recommend a price increase I didn't agree with. I respected the hierarchy and didn't say anything, and the client went ahead with it. In hindsight I should have spoken up.”
There was no disagreement in practice, and the interviewer learns nothing about how the candidate would raise a concern.
Stronger
“We were recommending a 6% price rise to a building-supplies client. My engagement manager wanted to apply it across all products. I thought we should exclude the twenty items trade customers buy most, because our survey showed they compare prices on those.
He had a good reason for keeping it simple. The client's sales team had struggled with a complicated price change the year before.
I asked for half an hour with him before the client meeting and showed him how trade customers had reacted to the last rise on those items. He agreed the risk was real, but not that it needed twenty exceptions.
We settled on excluding five items, which covered most of the risk. I'd have gone further, but five was something the sales team could explain, and I helped draft their guidance.”
The candidate raised it privately with evidence, the manager's reason is respected, and the final answer is a real concession on both sides rather than a win.
Follow-ups to expect: What was the other person's view, and why did they hold it? What did you do once the decision was made? How was the working relationship afterwards?
If you've never had a conflict
Plenty of people haven't had a real argument at work, and “I get along with everyone” feels like the honest answer. Yet one interviewer on r/interviews calls it a red flag. It can suggest you've never worked on anything important enough to disagree about.
The fix is to widen what counts. A conflict here is any time you thought one approach was right and someone else thought another. Feedback you gave or received, a review that went back and forth, or a recommendation your manager changed all count.
If you're early in your career, a group project, a part-time job or a volunteer role works. The same hiring manager widens the question to school or sport when candidates struggle, because they want your reasoning, not the drama. Say “It wasn't a big conflict, but we disagreed about…” and tell it properly.
What makes the answer go wrong
Most weak conflict answers are really about who was right. These are the common versions:
- A case for your side. Spending the answer defending yourself is one of the mistakes that hide good work, and it leaves no room for the other view.
- Going straight to your manager. An interviewer who asks this often calls it the wrong answer. Escalating can be right, but as a step you agreed on together.
- “We met in the middle.” Amazon's principles warn against compromising just to keep the peace, so a split-the-difference ending isn't automatically a good one.
- An attack on the person. The question is partly a check for this. One interviewer recalls a candidate explaining how they got the other person fired.
Other ways it gets asked
The question comes in a few wordings, and each shifts what to emphasize.
“Tell me about a time you disagreed with your manager.” It feels risky, but it's fine if you had evidence and raised it privately first. A practitioner on r/interviews calls this the meeting before the meeting. A good ending can be what an analyst on Reddit describes: arguing with data, losing, and getting on with it.
“Tell me about a difficult working relationship.” This is a pattern rather than one decision. Say what made it hard in neutral terms, and what you changed in how you worked with the person. Advice in a Deloitte thread puts it simply: describe the situation without pointing fingers.
“Tell me about a time you disagreed with a decision.” Here the decision may have been made before you could argue. Say how you raised your concern, who you raised it with, and what you did when it stood.
“How do you handle conflict?” It's worded as a hypothetical, but answer with a real example. A sentence on your approach, then the story, gives the interviewer something to judge.
A story where you were between two other people or teams fits the stakeholder management question better.
For a disagreement you were part of, the story you lost is often your best one: their view told fairly, what you did together, and how you committed.