Tell me about a time when you had a conflict with your manager and you were wrong
Asked at:
Meta
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can disagree upward without becoming defensive, and whether you can accurately recognize when your own judgment was off. Interviewers want to see maturity under power imbalance: can you advocate for your view, seek to understand your manager's context, and then update when the evidence says you're wrong? It is also a strong test of self-awareness, coachability, and whether conflict leads to learning rather than resentment.
“Describe a time you disagreed with your manager and later realized their perspective was right.”
“Have you ever pushed back on your boss and then changed your mind? What happened?”
“Tell me about a time you had a different view from your manager and discovered you were missing something important.”
“What's an example of a conflict with your manager where your initial judgment was wrong?”
“Can you share a situation where you challenged your manager's decision and later saw that your approach wasn't the best one?”
Key Insights
- Conflict with a manager does not need to mean a heated argument. A strong answer often centers on differing assumptions, priorities, or risk tolerance, and shows how you worked to understand the context you were missing.
- You need to be clearly wrong in a real way. If you choose a story where your manager was technically wrong but you generously accepted it, interviewers will hear avoidance rather than humility.
- Don't stop at 'my manager explained it and I agreed.' Show the learning loop: what information you lacked, how you updated your thinking, and what you changed afterward so the mistake did not repeat.
What interviewers probe atlevel
Top Priority
A strong junior answer ends with a simple but believable change in behavior that you carried into later work.
Good examples
🟢After that, I started asking earlier what risks mattered most before I got attached to an implementation, and it helped me avoid similar misses on later tasks.
🟢I created a habit of checking assumptions with my manager before release decisions, especially around testing and rollout risk.
Bad examples
🔴The main thing I learned was to trust my manager more next time.
🔴Since then I've tried to be less opinionated when my manager gives feedback.
Weak answers learn obedience; strong answers learn a reusable working habit.
You do not need to know everything, but you should show that you asked questions and tried to understand why your manager saw it differently.
Good examples
🟢After we disagreed, I asked my manager to walk me through the risks they were seeing, and that exposed some deployment concerns I hadn't considered.
🟢I set up a short follow-up because I wanted to understand why they were pushing for a slower rollout, and I learned there had been similar incidents before.
Bad examples
🔴My manager said there were bigger concerns, so I stopped arguing and moved on.
🔴I didn't really see the issue, but I trusted that my manager had more context and followed their direction.
Weak answers defer to authority; strong answers actively seek missing context and demonstrate learning from it.
At junior level, the bar is simple but important: pick a real mistake, own it plainly, and avoid turning the story into subtle blame of your manager.
Good examples
🟢I pushed back on adding monitoring because I thought it would slow me down, and I was wrong because I underestimated how hard the issue would be to debug once it reached users.
🟢I believed my change was ready to ship because it passed my local checks, but my manager was right that I hadn't validated the edge cases that mattered in production.
Bad examples
🔴I disagreed with my manager about the timeline, but later it turned out there were dependencies I hadn't been told about, so I just followed their plan.
🔴My manager wanted more testing and I thought it was overkill, but I did it anyway since they had more experience.
Weak answers keep the candidate morally or intellectually 'mostly right'; strong answers state a concrete judgment error the candidate made and own it without hedging.
Valuable
Your story does not need giant scope, but it should involve a real tradeoff that affected work quality, delivery, or risk.
Good examples
🟢We disagreed on whether a feature was ready to release because I thought the remaining issues were minor and my manager thought the user risk was too high.
🟢I pushed back on spending time on observability before launch because I thought it wasn't necessary for a small feature.
Bad examples
🔴We disagreed on whether I should post updates in chat or email.
🔴I wanted to work from home that day and my manager preferred I come in because we had a launch.
Weak answers are mostly about style or logistics; strong answers involve meaningful engineering judgment within junior scope.
Example answers atlevel
Great answers
Early in my first year, I was finishing a small feature and my manager asked me to add basic monitoring and one more round of edge-case testing before release. I pushed back because the feature looked straightforward and I thought the extra work would just delay us. In our follow-up, I asked what risk they were seeing, and they explained that similar changes had been hard to diagnose once they hit production because failures only showed up for a small set of users. They were right; when I tested more carefully, I found a case I had missed. I updated the code, added the monitoring, and sent a revised release plan so we could ship safely a day later. After that, I got into the habit of asking earlier what failure modes mattered most instead of assuming a change was low risk because it seemed small to me.
At my previous job I was asked to implement a CSV export for a customer-facing reports page. I argued with my manager that we should build a generic export service so future formats would be easy, because I hate duplicating code. My manager pushed back: customers needed CSV today and the deadline was tight, so he wanted a simple focused endpoint we could ship. He was right — my insistence would have delayed the release and added unnecessary complexity for a near-term need. I admitted I was wrong, implemented the simple export, and then proposed a small follow-up task with clear cost estimates to factor out shared code later. I learned to balance good design with practical delivery and to present trade-offs with estimated effort instead of assuming my preferred approach is best.
Poor answers
I had a disagreement with my manager about whether a feature was ready to ship. I felt it was fine because I had tested the main path, but my manager wanted extra checks and monitoring. We went back and forth a bit, and then I just did what they asked so we could keep moving. It ended up shipping without major issues, and I think the main takeaway was that it's usually faster to trust your manager's instincts on release decisions.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early March, 2026
Meta
Staff
Early January, 2026
Mid-level
Early November, 2025
Meta
Staff
Tell me about a time when you had a conflict with your manager and you were wrong
Hello Interview Premium
Your account is free and you can post anonymously if you choose.