Tell me about a time you disagreed with your manager.

Why this question is asked at all

Two things, and they pull in opposite directions. The first is whether you have a spine: can you hold a technical position when the person holding it is more senior than you, and can you make the case in a way that is about the substance rather than about who is right. An engineer who never disagrees upward is a liability, because they will watch a bad decision ship and say nothing.

The second is whether you are safe to give a decision to. Once the call is made and it goes against you, does the organisation get your full effort, or does it get quiet non-compliance, an I-told-you-so six weeks later, and a lingering morale problem? This is what Amazon's leadership principles label "disagree and commit", and the phrase has spread far beyond Amazon because the underlying worry is universal. Most candidates prepare only for the first half of the question and answer only the first half, which is why the second half is where the score is decided.

There is also a quieter read on how you describe your manager. The interviewer is listening for whether you can represent someone else's reasoning fairly under pressure. If your manager appears in the story only as an obstacle, they learn something about how you will describe them to the next interviewer.

Choosing the disagreement

The choice of story does most of the work, and there are two ways to get it wrong.

Choosing something trivial is the more common error. A disagreement about a variable naming convention, or which of two equally good libraries to use, is safe precisely because nothing was at stake, and safety is the problem. The interviewer concludes either that you avoid real conflict or that you are not being candid. Pick something where a wrong decision would have cost real money, real time, or real reliability.

Choosing a story where you were plainly right and your manager was plainly foolish is the subtler error, and it is worse. It reads as a complaint dressed as an anecdote, it tells the interviewer nothing about your judgement — anyone can be right when the other side is absurd — and it raises the question of what you will say about the manager you are interviewing to work for. The best stories are ones where both positions were reasonable, and the tension was a genuine trade-off: speed against maintainability, a deadline commitment against technical risk, breadth of scope against depth of testing.

Structuring it without sounding rehearsed

STAR still applies, but the weighting is unusual for this question. Situation and task should be two or three sentences, and must include your manager's position stated in a way they would recognise as accurate. Action covers how you made the case: what evidence you gathered, whether you did it in a one-to-one rather than in front of the team, and whether you offered a way to test the disagreement cheaply rather than only asserting a conclusion.

Then the part that most answers omit. Result has two halves: what was decided, and what you did next. If the decision went your way, say what you did to make sure your manager was not left looking overruled. If it went against you, say plainly that you executed it, and say what you actually did — not "I supported the decision" but the concrete thing, such as writing the migration you had argued against and adding the monitoring that would catch the failure mode you were worried about.

The way to avoid sounding rehearsed is to keep one specific, slightly awkward detail in — the number you were wrong about, the thing you said badly in the meeting, the fact that you were annoyed for a day. Polished answers with no friction in them read as constructed. It also helps to speak in the register of a work conversation rather than a presentation: say "I thought the estimate was optimistic" rather than "I proactively surfaced a concern regarding timeline feasibility."

A worked example

This is an example to show the shape and the level of specificity. Do not recite it — the details will not survive a single follow-up question. Replace it with something that actually happened to you.

"Last year my manager wanted us to ship a new pricing API by the end of the quarter, and to do that he proposed we skip building the reconciliation job that would compare our computed prices against the legacy system's. His reasoning was fair: we were three weeks from the date, the reconciliation job was maybe eight days of work, and the legacy system was being decommissioned anyway, so it felt like building a bridge to a building we were about to demolish.

I disagreed because the cutover plan had us running both systems in parallel for six weeks, and without reconciliation we would have no way to detect a pricing discrepancy except a customer complaint. I asked for twenty minutes in our one-to-one rather than raising it in sprint planning, because I wanted to argue the point and not put him on the spot in front of the team. I brought two things: the four pricing rules where the legacy logic had undocumented special cases, and a rough estimate that a one per cent error rate across the parallel window was somewhere around a few thousand transactions. I also offered a smaller version — a read-only sampling job on one per cent of requests, about two days of work rather than eight.

He took the sampling job but held the date, which was less than I wanted. I said I thought we would regret not having the full comparison and then I built the sampling job and stopped relitigating it. It caught a rounding discrepancy on volume discounts in the second week of the parallel run, which we fixed in a day.

Two things I would do differently. My cost estimate was hand-waved — I said 'a few thousand transactions' when I could have pulled the actual volumes in an hour, and a real number would have been much harder to argue with. And I was irritated for about a day after that conversation, which I do not think I hid especially well. What I got right was proposing a cheaper version of my own idea instead of defending the expensive one."

Notice what that does. Both positions are defensible and the manager's reasoning is stated generously. The escalation is private and evidence-led. The outcome is a partial loss, which is more credible than a win. And the story continues past the decision, which is the part that answers the actual question.

The trap

The trap is ending the story at the moment of the decision. Candidates put their effort into the disagreement itself — the evidence, the meeting, the argument — and then close with "and we went with my approach" or "and the decision was made." Both endings fail, because the interviewer's real question is not whether you can disagree. It is what kind of colleague you are in the weeks after a decision you lost, and an answer that stops at the decision leaves that unanswered. The interviewer will usually not prompt for it; they will simply mark it as missing.

The corollary is that a story where you won is a weaker vehicle than one where you lost, because a win never tests the commit half. If your only prepared story ends in vindication, prepare a second one that does not.

Half of this question lives after the decision. If your story ends when the call is made, you have answered whether you can disagree and left the more important question — whether you can commit — unanswered.