Disagreement With a Teammate or Manager

The classic senior STAR question. Interviewers want to see: you can hold a position, listen, change your mind when wrong, escalate appropriately, and not damage relationships.

What they’re really asking

Can you advocate for an idea without being abrasive?
Do you know the difference between “right” and “popular”?
Will you escalate when needed, or will you sulk?
Do you actually update your beliefs when presented with new info?
Are you safe to disagree with as a colleague?

STAR structure for this prompt

Situation: specific, concrete. Not “a project I worked on” — “the migration of our payments service from sync to async in Q2 2023.”

Task: what was your role, what was the decision being made?

Action: what you did — concretely. The disagreement, your approach, the resolution path.

Result: what happened, what you learned. Honest about whether you were right.

Strong example template

Situation: Working on a payment-flow refactor; my team lead proposed Saga orchestration via Celery; I’d been working with Temporal in a previous project and felt it was better suited for our retry / compensation logic.

Task: Decide what to ship. ~2 week window before the next compliance deadline.

Action:

Wrote a one-page comparison doc — pros/cons for both, code examples for the same flow (refund-on-failure) implemented in each.

Booked a 30-min sync with the team lead specifically to discuss. Came prepared.

Asked them to walk me through their reasoning first; they had context I didn’t (we had Celery monitoring in place, no operational experience with Temporal).

I pushed back on two specific points where my comparison was stronger — explicit retry policies and the time-skipping test environment.

We agreed to a middle ground: ship Celery now for the deadline, with a structured “review in 6 weeks” trigger to evaluate Temporal for the next phase.

Result: Shipped on time. Six weeks later, we hit two production retry edge cases that took longer to debug than Temporal’s flow would have. I pulled together a follow-up doc; the team agreed Temporal was right for the next service. I learned: my technical preference was right, but the team lead’s operational concerns were also valid, and the “review trigger” mechanism let us not relitigate. Also realized I’d presented my view assuming “best technology wins” — the lead was right that operational maturity matters at least as much.

What this answer signals

Specific scenario — not a generic “we disagreed about architecture.”
Receptive first. “Asked them to walk me through their reasoning first.” Shows you listen.
Concrete actions. Wrote a doc, booked a meeting, prepared examples.
Compromise mechanism. “Review in 6 weeks” — not “I gave up” and not “I forced it through.”
Honest result. You were partially right and partially wrong. Owning the wrong part is the signal.
Lesson learned. “Best technology wins” was your blind spot.

Anti-patterns to avoid

“And then I was right and they admitted it.” Sounds petty; doesn’t show growth.
“I escalated to my manager.” Going over someone’s head should be a last resort and you should say why escalation was needed, not the default.
“Eventually they came around to my view.” No collaboration; sounds like you wore them down rather than reasoned together.
“It was never really resolved.” Concerning — interviewers wonder if you carry that to other relationships.
“I didn’t say anything because they’re senior.” The opposite extreme; doesn’t signal senior-level confidence.
Vague platitudes. “I tried to listen and find common ground.” Too abstract to evaluate.

Variations you might be asked

“Tell me about a time you disagreed with your manager specifically.” Same structure; higher stakes. Show you escalated through the right channels (1:1, written proposal, time-bounded experiment) rather than going around them or going silent.
“How do you handle pushback on your design decisions?” Forward-looking version. Talk about how you invite it: writing design docs, RFC-style proposals, explicit “what could go wrong with this?” sections.
“Tell me about a time you were the one being pushed back on.” Tests humility. Pick a case where you actually updated your view.

Key phrases that signal seniority

“I wanted to make sure I understood their concern first…”
“We agreed on a trigger to revisit…”
“In hindsight, I underweighted [operational, organizational, etc.] factors…”
“I made a one-page doc rather than a 20-minute synchronous debate…”
“I treated this as a decision-quality question, not a who-wins question…”

A bad answer in this category

“My team lead wanted to use one library; I thought another was better. I explained my reasoning in a meeting. After some discussion, we agreed to use my approach. It worked out well.”

Why it fails: no specifics, no nuance, no evidence of receptive listening, no honest reckoning with whether you were right.

A great answer is concrete

The interviewer should be able to picture the meeting. The doc you wrote. The slack message. The 1:1. The follow-up review. The specific bug that came up later.

If you can’t picture it, you’re not telling a story — you’re reciting a template. Pick a real scenario from your career, even an awkward one, and tell that.

Reflective practice

Before the interview, list 3-5 real disagreements from your career:

With a peer over a technical decision.
With a manager over priorities or process.
With a stakeholder (product, design, customer-facing) over scope.
With your past self — a decision you made that you later disagreed with.

For each, pre-write a 3-paragraph STAR. Pick the strongest for the interview; have the others ready as follow-ups.

Interview angle

The interviewer is probing: are you safe? Are you collaborative? Do you have judgment about which battles to fight? The “right” answer isn’t proving you were right; it’s showing you exercise judgment about when, how, and how hard to push.

Senior engineers regularly find themselves wrong, mid-disagreement, and the best ones notice and adjust. Show that you do.