0

Tell me about a time you disagreed with your team

by · about 4 hours ago· ⑂ 0 remixes

Question: Tell me about a time you disagreed with your team

Companies: Anthropic, Stripe, Airbnb

Problem statement

Describe a real disagreement about a technical decision: what was at stake, what you did, and how it ended.

What the question probes

"Tell me about a time you disagreed with your team" is the most common behavioral prompt there is, and it grades more than conflict. The interviewer wants to see:

  1. That you disagree at all. Engineers who never push back either don't care or don't say. Both are problems.
  2. How you disagree. With evidence, early, in the right forum, and with respect for the other view.
  3. What you do after the decision. Whether you won or lost, do you commit and help it succeed? "Disagree and commit" is the phrase many rubrics use.
  4. Whether you can be wrong. The strongest answers often involve a disagreement you lost, or one where the other side was partly right.

What it is not: a chance to show you were right and everyone else was slow. If the other people in your story come across as foolish, the interviewer hears "this person will be hard to work with".

Pick the right story

A good disagreement story has:

  • Real stakes. A technical or product decision that mattered: an architecture choice, a launch date, a migration plan, a safety or quality bar. Not tabs versus spaces.
  • A reasonable opponent. The other side had a good argument. You can state it fairly.
  • Your action. Something you did besides arguing: built a prototype, gathered data, proposed an experiment, wrote a doc.
  • A resolution and a result. How the decision got made, what happened, and what you learned.

The best stories often end in a compromise or with you changing your mind for a good reason. A story where you lost and committed fully is very strong evidence.

Structure

Spend about two minutes:

  1. The decision and the stakes (20 seconds). What was being decided, and what it would cost to get wrong.
  2. The two positions (30 seconds). Theirs first, stated fairly, then yours, with your reason.
  3. What you did (45 seconds). How you moved the disagreement from opinion to evidence.
  4. How it ended (15 seconds). The decision, who made it, and the outcome with a number.
  5. What you learned (10 seconds). Something you do differently now.

Worked example (L4/L5)

"On my last team we were adding search to an internal tool used by about 2,000 support agents. The team wanted Elasticsearch because two people had used it before. I thought Postgres full-text search was enough, because our corpus was 4 million tickets, about 6 GB, and adding a new cluster meant a new thing for our three-person team to run on call.

Their argument was good: Elasticsearch has better relevance tuning and we might need it later. So instead of arguing in the meeting, I suggested a one-week spike. I built Postgres search on a copy of production data and our tech lead built a minimal Elasticsearch version. We agreed beforehand what we'd measure: p95 latency under 300 ms and relevance on 50 real queries the support leads gave us, scored blind.

Postgres hit 120 ms at p95 and tied on 41 of 50 queries; Elasticsearch was better on 9, mostly fuzzy matches on misspelled product names. We went with Postgres plus a trigram index for the misspellings, which fixed 6 of those 9. It's been running two years with no search incidents.

What I learned: the useful move was agreeing on the measure before anyone saw results. I do that by default now when there's a technical disagreement."

Worked example (L6)

At staff level the disagreement is usually with another team or with leadership, and the story should show how you handled the organizational side.

"I was the tech lead for our payments platform. Our VP wanted every product team to move to a new event bus within two quarters to retire the old queue. I agreed with the goal but disagreed with the timeline: we had 31 producers, and our audit showed 9 of them relied on ordering guarantees the new bus didn't give by default. A rushed migration risked double-processing payments.

The VP's argument was fair: the old queue cost us about $400,000 a year and caused two major incidents that year. Delay had a real cost.

I didn't fight the date head-on. I wrote a two-page doc that split the producers into three groups: 22 that could move as planned, 9 that needed partition keys and idempotency work first, and a list of what each would need. I proposed moving the 22 on the original timeline, which got us about 70% of the cost savings, and the 9 a quarter later with a migration kit my team would build. I reviewed it with two product tech leads before the VP saw it, so it arrived with support.

The VP agreed. The 22 moved on schedule; the kit took six weeks, and the remaining 9 moved with zero payment incidents. One thing I got wrong: I estimated the kit at three weeks. Since then I put a range on any estimate I use to argue a date.

The lesson for me was that a disagreement with leadership goes better as a better plan than as a 'no'."

Variations of the prompt

The same story answers many prompts. Angle it differently:

  • "Tell me about a time you disagreed with your manager." Lead with the hierarchy: how you raised it, and how you committed if you lost.
  • "Tell me about a time you pushed back on a decision." Lead with why the stakes justified pushing.
  • "Tell me about a time you changed your mind." Lead with the evidence that convinced you.
  • "How do you handle conflict on a team?" Answer with this story, then one sentence of general principle.

Red flags

  • The other side is stupid. If you can't state their argument fairly, the interviewer doubts your judgment and your collaboration.
  • You won by escalating. Going over someone's head as the first move is a negative signal.
  • No commitment after losing. "We did it their way and it failed, as I said" is the worst ending.
  • Trivial stakes. A disagreement about naming doesn't show anything.
  • No outcome. Stories that end at "so we discussed it" leave the interviewer guessing.
  • A disagreement with no feelings in it at all, or one that's all feelings. Acknowledge it was uncomfortable if it was, but keep the focus on the decision.

Follow-ups

  • "What would you have done if they had said no?"
  • "Was there anything in their position you came to agree with?"
  • "How did your relationship with that person change afterwards?"
  • "What if the data had come out the other way?"
  • "Tell me about a disagreement you lost."
  • "How do you decide which disagreements are worth having?" (Good answer: reversibility and cost. Cheap, reversible decisions aren't worth a fight; one-way doors are.)

Interviewer expectations

Mid-level (L4)

  • A real technical disagreement with stakes, told in the first person.
  • States the other position fairly and moves the discussion toward evidence.
  • Commits to the decision, and the story ends with a result.

Senior (L5)

  • Proposes a way to settle the disagreement (spike, experiment, agreed success criteria) rather than arguing longer.
  • Shows judgment about which disagreements matter, and the outcome has a number.
  • Has a version where they were wrong or lost and committed fully.

Staff (L6+)

  • Disagreement crosses teams or leadership; handled by reframing the decision (a better plan, a phased option) and building support before the decision meeting.
  • Weighs the cost of delay against the risk explicitly and gives the other side's concern real weight.
  • Draws a lasting lesson about how decisions get made, and changed something because of it.

Sign in to comment, vote or remix.