Tell me about a time when you strongly disagreed with your manager or peer on something you considered very important to the business.
Asked at:
Capital One
Meta
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you handle high-stakes disagreement when the other person has influence over your work or outcomes. They want to see whether you can challenge important decisions without becoming rigid, political, or careless with relationships. Strong answers show judgment about what was truly important, curiosity about the other person's reasoning, and a constructive path to resolution.
“Describe a situation where you pushed back on your manager or a teammate about a decision that really mattered.”
“Tell me about a time you thought your lead or peer was taking the wrong approach on an important business issue. What did you do?”
“Have you ever had to challenge a decision from your boss or another engineer when the stakes were high?”
“What's an example of a meaningful disagreement you had with your manager or a colleague, and how did you handle it?”
“Walk me through a time when you and someone influential on your team saw an important decision very differently.”
Key Insights
- Conflict does not need to be emotional. You will usually sound stronger if you frame the disagreement in terms of tradeoffs, risk, incentives, or business priorities rather than personalities.
- You should show why the issue mattered enough to challenge, not just that you had a different opinion. Interviewers are listening for judgment about when disagreement is worth spending organizational energy on.
- Do not make the story about winning. The strongest answers show that you worked to understand the other person's constraints, improved the decision quality, and preserved or even strengthened the relationship.
What interviewers probe atlevel
Top Priority
Even as a junior engineer, you are expected to show curiosity about why someone disagreed instead of assuming they were wrong.
Good examples
🟢Before arguing further, I asked my manager what deadline or constraint I might be missing and learned there was a customer commitment driving the urgency.
🟢I set up a follow-up with my teammate to understand why they wanted the simpler approach, and it turned out they were worried about the support burden after launch.
Bad examples
🔴My manager kept saying we should move forward, but I knew the approach was unsafe, so I kept repeating my concerns until they gave in.
🔴My peer disagreed in the meeting and I felt they just did not understand the code, so I defended my plan there.
Weak answers assume bad judgment on the other side; strong answers show the candidate investigated the motivations, constraints, or risks behind the disagreement.
You do not need perfect data at junior level, but you should show that you grounded your pushback in something more than certainty or stubbornness.
Good examples
🟢I did a short investigation and showed that the current approach failed on a few realistic inputs, which made the risk concrete.
🟢I compared the extra day of work against the likely cleanup if the release went wrong and used that to explain why I wanted to delay.
Bad examples
🔴I just felt strongly that the bug risk was obvious, so I kept saying we should not ship it.
🔴I told my teammate I had seen this kind of thing fail before, which should have been enough reason to change course.
Weak answers rely on conviction; strong answers convert concern into observable reasoning, examples, or tradeoff analysis.
At junior level, the bar is not 'biggest impact in the org' but whether you can recognize when a decision has real customer, reliability, or delivery consequences rather than personal preference.
Good examples
🟢I pushed back when we were about to skip validation on an internal upload flow because I thought it could corrupt customer data and create support work later.
🟢I disagreed with a peer about removing tests to hit a deadline because I believed it would create production risk for a feature already promised to customers.
Bad examples
🔴I disagreed with my manager about whether we should use dark mode in the admin tool because I thought users would like it more, so I pushed pretty hard for that.
🔴A teammate wanted to name the service one way and I wanted another because I thought mine was cleaner, and we went back and forth for a while.
Weak answers spend conflict capital on taste or minor process issues; strong answers show judgment that the issue had meaningful business, customer, or operational impact.
Valuable
Even at junior level, do not stop your story at 'I raised the issue'—show what happened next and what you learned about handling disagreement.
Good examples
🟢After we decided, I helped implement the safer version and checked afterward that the issue we were worried about did not occur.
🟢I also learned to ask about business constraints earlier, which helped me handle later disagreements more effectively.
Bad examples
🔴Once I made my argument, it was really my manager's call, so I moved on and did not follow up much after that.
🔴We agreed to my idea, and that was the main outcome I was looking for.
Weak answers end at advocacy; strong answers show follow-through, outcome awareness, and personal growth.
Example answers atlevel
Great answers
In my first year, I disagreed with my manager about releasing a data import feature on the original date. During testing I found that a few malformed files could partially import and leave records in an inconsistent state, and I felt that would create real customer support issues. Instead of just saying we should delay, I asked what was driving the date and learned a customer demo was already scheduled that week. I put together a short investigation with example failures and suggested a compromise: keep the demo date, but limit the import format and add validation before general release. My manager agreed, we shipped the narrower version, and the follow-up release went out a week later without the data issue. What I learned was to ask about the business constraint early so I can frame my pushback around a workable option, not just a concern.
In a previous role at a health‑tech startup I pushed back when my manager suggested turning off authentication in a demo environment so executives could quickly try a new feature. I was uncomfortable exposing any patient data, so I calmly explained the legal and reputational risks and proposed a concrete alternative: add a short-lived feature flag scoped to a few accounts, enable audit logging, and prepare a redacted demo dataset. My manager was initially skeptical about the extra work, so I implemented the flag and scrubbed data overnight and asked legal for a quick check. The demo went ahead on schedule with zero data exposure, and our team adopted the scoped-flag + audit approach for future demos. I learned that standing firm on ethical and privacy concerns works best when you pair it with a practical, low-cost solution.
Poor answers
I had a strong disagreement with my manager about how quickly we should launch a small internal tool. I felt we were overthinking some edge cases, and I kept pushing in the team meeting until we decided to move forward. The launch was fine, so I think it showed that I can stand by my opinion even when my manager disagrees. In general, I try to be direct and not let people slow things down too much.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid March, 2026
Meta
Senior
Mid March, 2026
Amazon
Senior
Mid February, 2026
Capital One
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.