How Did You Handle Disagreement With Your Manager? STAR Templates

What Interviewers Are Actually Testing

Disagreement questions — "Tell me about a time you disagreed with your manager," "Describe a conflict with a team member," "How do you handle pushback on a technical decision" — are behavioral questions designed to probe two things simultaneously: your ability to think independently (do you have a spine and a point of view?) and your ability to operate within a professional structure (can you disagree without destroying relationships or derailing projects?). Companies want both. Engineers who never push back are dangerous. Engineers who push back in ways that create chaos are also dangerous.

The answer that scores well shows you advocated for your position with evidence, listened genuinely to the other perspective, reached a resolution through legitimate process, and maintained the working relationship throughout.

The Disagreement Question Framework

1. State the disagreement clearly: Describe what you believed and what your manager/colleague believed, without editorializing about who was wrong.
2. Show your advocacy: Explain what evidence or reasoning you brought to the discussion. This is the "independent thinker" signal.
3. Show your listening: Acknowledge what you learned from their perspective or what constraints you hadn't fully appreciated. This is the "professional" signal.
4. Describe the resolution: How was it resolved? Did you change your mind, did they, or did you find a third option?
5. Show the outcome: What happened to the project and the relationship?

STAR Example 1: Junior Engineer Disagreeing With Manager (Technical Approach)

"Early in my first job, my manager wanted to use a vendor solution for a data transformation layer, and I thought we should build it in-house using a lightweight open-source framework. I believed the vendor solution was over-engineered for our use case and would lock us into pricing that didn't scale well.

I asked for 30 minutes to present my case. I put together a comparison of the two options on four dimensions: implementation time, total cost over 3 years at our projected data volume, technical flexibility, and operational complexity. The numbers showed the open-source path was significantly cheaper, but my manager pointed out something I'd underweighted: our team had no one with deep expertise in the open-source framework, and the vendor offered a dedicated support engineer during integration. That was a legitimate risk I hadn't fully costed.

We agreed on a modified approach: we'd use the vendor solution for the initial integration but structure the contract to avoid long-term lock-in, and I would own building an internal capability so we could evaluate switching in 18 months. The project shipped on time, and 18 months later we did evaluate switching — and by then the vendor's pricing had actually improved, so we renewed. I was wrong about the lock-in risk. My manager was right to flag it."

STAR Example 2: Mid-Level Engineer Disagreeing With Manager (Prioritization)

"My manager wanted to ship a customer-facing feature before completing a stability improvement I thought was critical. We'd been seeing intermittent but hard-to-reproduce data integrity issues in production, and I believed we were accumulating risk with every day we didn't address it. My manager's view was that the feature was already delayed and customer commitments took priority.

I escalated the conversation by quantifying the risk — I estimated that the data integrity issue had a roughly 1-in-500 chance of affecting a high-value customer's data each week based on our error logs, and I outlined the likely remediation cost if it did. I also proposed a path that addressed both concerns: a targeted 2-day fix for the highest-severity part of the integrity issue, followed by the feature ship, with the full fix scoped for the next sprint. My manager agreed to the 2-day targeted fix. We shipped the feature one sprint later than originally planned, and the integrity issue didn't affect any customer before we fixed it. I was glad we found the middle path."

STAR Example 3: Senior Engineer Disagreeing With Manager (Architectural Decision)

"My engineering director wanted to adopt a microservices architecture for our next product, and I thought we were making the move too early — we had a small team and hadn't yet validated the product-market fit of the features we were building. I was concerned that the operational overhead of microservices would slow our iteration speed exactly when speed mattered most.

I requested a design review session and prepared a structured argument drawing on our specific team size, deployment frequency data, and the service count we were projecting. I also brought in a case study from a team at a previous company that had made the microservices move early and spent six months untangling the consequences. My director acknowledged the concern but pointed out that two of our customers had explicit requirements for data isolation that were harder to satisfy with a monolith approach — a constraint I hadn't fully understood. That changed my calculation meaningfully.

We landed on a modular monolith with hard domain boundaries — an architecture that would allow us to extract services later without the full operational overhead now. That decision has aged well. We've been running it for two years and extracted exactly two services; the rest are still in the monolith and that's been the right call."

Red Flags: What Never to Say

• "I just agreed because they were my manager" — signals no independent thinking
• "I was right and they were wrong, and eventually they admitted it" — signals inability to see the other side
• "I went around my manager to escalate" — without explaining why escalation was appropriate and how it was handled
• Stories where the disagreement was personal, not professional

Handle follow-up questions like "What if you were wrong?" directly: "In that case, I would have made an error in judgment, but I would have learned something specific and applied it. Being wrong after a genuine good-faith analysis is not something I'd avoid in order to play it safe."

Practice all three example types using AissenceAI's mock interview mode — real-time feedback at 116ms, invisible on screen share, supports 42 languages. $20/mo. See behavioral interview AI coaching for full STAR story preparation.

FAQ: Handling Disagreement Questions

Q: What if I've never had a serious disagreement with a manager?

A: That's worth examining. If you genuinely can't recall a disagreement, either you've had unusually aligned managers (possible), or you've been conflict-avoidant (common). Think more broadly — did you ever advocate for a different technical approach, prioritization choice, or process change? These are disagreements even if they didn't feel confrontational.

Q: Can I use a disagreement with a peer instead of a manager?

A: Yes, and sometimes peer disagreements make stronger stories because they don't involve hierarchy. Make sure the peer conflict story shows the same framework: advocacy with evidence, genuine listening, professional resolution.

Q: How do I handle the follow-up "What would you do if your manager still didn't agree after you made your case?"

A: "I would disagree and commit. Once I've made my case clearly and the decision has been made, my job is to execute it well and support the outcome even if I still have reservations. I'd flag if new evidence emerged that changed the picture, but I wouldn't relitigate a closed decision repeatedly."