Tell me about a time when your colleague disagreed with you
Asked at:
Meta
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 disagreement when reasonable people see a situation differently. They want to know whether you can stay constructive, understand the other person's perspective, and work toward a good outcome without becoming defensive or relying on authority. At higher levels, they are also checking whether you can resolve disagreement in a way that protects relationships and improves decisions for more than just yourself.
“Describe a time when you and a coworker saw a problem differently. How did you handle it?”
“Tell me about a disagreement you had with a teammate at work.”
“Can you give me an example of a situation where someone you worked with pushed back on your idea?”
“Walk me through a time you had to resolve a difference of opinion with a colleague.”
Key Insights
- Conflict does not need to be emotional to be meaningful. A strong answer often involves different constraints, incentives, or risk tolerance—not a dramatic argument.
- You should show genuine curiosity about why the other person disagreed. The best answers make it clear you investigated their reasoning instead of treating disagreement as an obstacle to overcome.
- Do not make the ending of the story simply 'I convinced them.' Stronger answers show a better decision, a thoughtful compromise, or a stronger working relationship afterward.
What interviewers probe atlevel
Top Priority
Interviewers want to see that you treated your colleague as reasonable and tried to learn what they were optimizing for.
Good examples
🟢I asked what concern they were trying to avoid, and it turned out they were worried about breaking a workflow they had supported before.
🟢Before debating implementation details, I asked why they preferred their approach and learned they were optimizing for easier handoff to the on-call engineer.
Bad examples
🔴They pushed back on my idea, but I knew my approach was cleaner so I kept explaining it until they agreed.
🔴I figured they just did not understand the task well enough, so I walked them through my solution.
Weak answers assume the other person is mistaken; strong answers uncover the logic behind the disagreement.
A strong ending includes both a practical result and evidence that the working relationship stayed healthy.
Good examples
🟢We shipped the safer version on time, and afterward that teammate came to me earlier for design feedback because we had built more trust.
🟢Our compromise avoided the bug we were worried about, and we used the same way of comparing options on later tasks.
Bad examples
🔴We shipped my version, so it worked out fine.
🔴The lead agreed with me, and after that we did not really revisit it.
Weak answers stop at getting a decision; strong answers show durable impact on outcomes and collaboration.
Valuable
Even if you still believe your position was reasonable, show that you examined how your own communication or assumptions affected the disagreement.
Good examples
🟢I realized I had jumped into solution mode before explaining the tradeoff I cared about, which made my position sound more rigid than I intended.
🟢Part of the friction was that I brought up my concern in the group chat instead of asking them directly first, so I changed my approach.
Bad examples
🔴The disagreement happened mostly because they were pretty resistant to feedback.
🔴I was clear from the start, so I do not think I contributed much to the issue.
Weak answers externalize the problem; strong answers show self-awareness without excessive self-blame.
Choose a real disagreement with some consequence, but keep the scope appropriate to someone contributing on a small project.
Good examples
🟢A teammate wanted to ship a quick fix, while I was worried it would make a customer-facing bug harder to debug later.
🟢My partner on a task wanted to skip a small test plan to save time, and I thought that created too much risk given a recent production issue.
Bad examples
🔴We disagreed about variable names in a code review, and I explained my preference until they changed it.
🔴A teammate wanted to format the API response differently, but I had already written my version so we just kept mine.
Weak stories are trivial preference disputes; strong stories involve a tradeoff where either side could plausibly be right.
Example answers atlevel
Great answers
In my first year, I was working with another engineer on a bug where users were occasionally seeing stale data. My colleague wanted to patch it quickly in the UI, but I was worried that would hide the real issue and make it harder to debug if it came back. Instead of arguing in the pull request, I asked if we could talk through what each of us was optimizing for, and I learned they were trying to avoid delaying another team that was waiting on us. We agreed to do a small server-side fix first and add a simple check in the UI as a temporary safeguard. That let us ship the same week, and the bug did not recur. After that, we worked together more smoothly because we had a better sense of when each of us was prioritizing speed versus long-term reliability.
On a small onboarding screen I was building, a colleague wanted to ship the exact design the product team provided to meet our sprint deadline, but I pushed back because the layout made the primary button hard to access for people using screen readers. Rather than arguing in the ticket, I made a quick prototype that rearranged the elements and added proper accessibility labels, and I showed it to our product manager with notes about the potential exclusion. We compromised: we adjusted the layout and added labels for this release so we wouldn't block the timeline, and put a short follow-up task to refine animations and edge cases. The feature shipped on time, a few accessibility issues were avoided in beta testing, and my teammate started including basic accessibility checks in their own reviews after seeing the prototype.
Poor answers
I had a disagreement with a teammate about how to implement a form validation change. I thought my approach was cleaner, and I had already started coding it, so I explained why it made more sense and kept going. They still preferred their version, but once they saw mine working they stopped pushing back. We shipped it and it was fine, so overall I think it was a good example of sticking to a sound technical decision.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid September, 2024
Meta
Senior
Tell me about a time when your colleague disagreed with you
Hello Interview Premium
Your account is free and you can post anonymously if you choose.