How to Disagree With Your Manager in an Interview

One of the most common behavioural questions is some version of: “If your manager asked you to make a change you believe is wrong, would you do what you think is right, or what the manager said?” This page teaches you to answer it using disagree-and-commit — raise your concern with data, respect the final call, and document it — so you sound mature rather than arrogant or spineless.

This question tests your maturity, not your technical knowledge. The interviewer is checking three things: Can you disagree respectfully instead of caving in or fighting? Do you argue with data and logic rather than “I just feel like it”? And once the decision is final, do you commit fully or keep complaining behind the scenes?

The trap is thinking there are only two answers. “I’ll do what’s right” sounds arrogant. “I’ll do whatever the manager says” sounds spineless. The strong answer is the middle path: raise your concern clearly with data; if the manager still makes the same call, then — as long as it isn’t unethical, unsafe, or illegal — disagree-and-commit, and note your concern in writing.

The core framework to remember

“If I think a change is wrong, I’d first make sure I’ve understood their context — they may have a business reason I’m not aware of. Then I’d raise my concern politely, backed by a concrete example or data: ‘this approach could hit problem X, and there’s an alternative Y that handles it.’ If the manager is still firm after hearing my points, I’ll respect the decision and implement it, because they likely have more visibility than I do. I’ll just document my concern in a message so there’s a record. That’s disagree-and-commit. Of course, if it’s about safety, security, or harming someone, I’ll escalate rather than stay quiet.”

Scenario: “What would you do?”

Manager: “Suppose I asked you to build a feature a certain way, but you think that approach will cause problems later. What would you do?”

You: “First I’d make sure I’ve understood your requirement and reasoning correctly — sometimes what looks wrong to me is actually right because of a deadline or a business constraint I’m not aware of, so I’d ask one or two clarifying questions. If I still see a genuine technical risk after that, I’d come to you with a short, specific concern — like ‘when the data grows ten times, this query will slow down’ — and I’d also propose an alternative. The final call is yours; if you still want the same approach, I’ll implement it and note my concern in one line so we can track it later if needed.”

Follow-up: “But you said it’s wrong. You’ll still do it?”

Manager: “You’re certain it’s wrong and will cause problems. You’ll still do what the manager says? Isn’t that knowingly doing something wrong?”

You: “Good question. I separate two things — preference and principle. If it’s just ‘my way is better,’ that’s a preference, and deferring to a senior’s decision is perfectly fine. They’re accountable and they have the bigger picture of the roadmap. I made my case, it was heard, and now the team needs to move forward — if everyone digs in on their own preference, work grinds to a halt. But if it’s a matter of principle — a security hole, data loss, harm to users, or legal risk — then I won’t just go along with it. I’ll put my concern in writing and, if needed, escalate respectfully up to my manager’s manager. So my answer depends on the impact: commit on a small technical preference, escalate on a serious risk.”

Follow-up: “And if your warning turns out to be right?”

Manager: “Suppose you implemented it and the problem you warned about actually happened. What would you do then? Say ‘I told you so’?”

You: “No, never ‘I told you so’ — that hurts team morale and makes me look small. I’d switch into solution mode: contain and fix the problem first. The upside is that because I’d documented my concern earlier, the fix is faster — I’d already thought through an alternative. Later, once the pressure is off, I’d raise it neutrally in the retrospective — ‘how do we catch things like this earlier next time’ — focusing on the process, not on blame. That actually increases the manager’s trust in me, because I thought about the team rather than my ego.”

Follow-up: “The manager won’t even listen to your concern”

Manager: “What if the manager is very dominating, won’t listen at all, and just says ‘do it the way I told you’?”

You: “Then I’d change my approach, not my tone. The timing may be wrong — disagreeing in the middle of a meeting, in front of everyone, rarely works. I’d raise the concern one-on-one, or in a short written message — small, factual, without emotion. I’d also speak the language of solutions rather than problems: ‘This will work; we just add one small thing and we avoid the future risk.’ If they still don’t listen, then I’ve done my job by raising the concern honestly. After that, implementing it is my responsibility. If the matter is truly serious, there’s the route of a documented concern plus a skip-level conversation, but that’s a last resort, not for every small thing.”

A real example, told in STAR

If the interviewer asks for a real example, use the STAR method:

• Situation: “On one project the lead said we should do all validation on the frontend and skip the backend to save time.”
• Task: “I felt this was a security risk — someone could hit the API directly and push bad data.”
• Action: “I showed the lead a quick example — I hit the API with Postman and demonstrated the bypass. I suggested we keep frontend validation for UX, but also add a basic backend check; it’d only take two hours.”
• Result: “They agreed, we added backend validation, and at audit time that was exactly what passed instead of becoming a red flag. The lead later noted in my feedback that I’d caught the risk early.”

Notice that you “win” here — but you win with respect and data, not by fighting. That balance is exactly what the interviewer wants to see.

Disagree and commit, in one line

When you disagree: bring data, offer an alternative, prefer one-on-one, drop the emotion. When you commit: once the decision is final, support it with full energy and don’t complain behind the scenes. The one exception is safety, security, ethics, or legal risk — staying quiet there is wrong, so escalate.

For peer-level clashes rather than manager disagreements, see Conflict With a Colleague.

Tips & mistakes to avoid

• ❌ “I’ll just do what I think is right.” → arrogant, not a team player.
• ❌ “I’ll do whatever the manager says without question.” → spineless, no ownership.
• ❌ Calling the manager wrong or a dictator. → instant red flag.
• ✅ Raise the concern → bring data → respect the decision → document it → escalate only if it’s serious.
• ✅ Always propose an alternative. “This is wrong” is weak; “This is wrong, let’s do this instead” is strong.
• ✅ Say the line “they may have more context than I do” — it signals genuine humility.