Tell me about a time when you had disagreements with your colleagues
Asked at:
Upstart
Uber
Meta
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to understand how you behave when smart people want different things, interpret data differently, or have different risk tolerance. They are usually less interested in whether you "won" and more interested in whether you can navigate disagreement with judgment, empathy, and follow-through. For senior candidates especially, they also want to see whether you can preserve trust while still moving work forward.
“Describe a time you and a coworker saw a problem very differently. What happened?”
“Tell me about a situation where you had to push through a professional disagreement with someone on your team.”
“Have you ever strongly disagreed with a colleague about how to proceed on a piece of work?”
“Walk me through a time when there was conflict around a decision you were involved in.”
“What's an example of a disagreement at work that you handled well?”
Key Insights
- Conflict does not need to be emotional to be meaningful. You will give a stronger answer if you explain the underlying mismatch in goals, incentives, constraints, or risk tolerance rather than framing it as two people simply disagreeing.
- You should show your own contribution to the disagreement, even if it was small. Honest ownership is a strong maturity signal; a story where you were entirely right and everyone else was the problem usually reads as low self-awareness.
- Do not stop at 'we talked and aligned.' Explain what you did to understand the other side, what changed in the plan or your thinking, and what the outcome was for both the work and the relationship.
What interviewers probe atlevel
Top Priority
You do not need to agree immediately, but you should show curiosity about why the other person felt differently.
Good examples
🟢After the disagreement came up, I asked my teammate to walk me through what risk they were worried about and realized they had context from an earlier bug I did not know about.
🟢I set up a quick follow-up conversation because the meeting was getting tense, and I used that time to understand what constraint they were optimizing for.
Bad examples
🔴I knew my approach was simpler, so I just kept explaining it until they stopped pushing back.
🔴My teammate didn't want to do it my way, and I assumed they were being overly cautious because they didn't understand the code.
Weak answers treat the other person as an obstacle; strong answers treat them as a source of information.
Interviewers want to hear that the work progressed and that you could still work well with the person afterward.
Good examples
🟢We agreed on a smaller safe change first, and afterward the teammate and I reviewed the results together, which made later collaboration easier.
🟢Even though we did not choose my original approach, I supported the final decision and we continued working well together on the project.
Bad examples
🔴We never fully agreed, but I just did my part and avoided working with them on similar tasks afterward.
🔴The issue was resolved because my lead picked a side, and after that I did not really interact with the teammate much.
Weak answers may end the disagreement but damage collaboration; strong answers preserve the working relationship and execution.
Valuable
Show that the disagreement changed how you work, even in a small way.
Good examples
🟢I learned to ask for context before defending an approach because I often do not yet have the full picture.
🟢The experience taught me to separate my idea from my identity, which makes it easier to hear pushback and adjust.
Bad examples
🔴The main lesson was that I need to argue my case more confidently next time because I was right.
🔴I concluded that some teammates just overcomplicate things, so now I try to avoid those discussions.
Weak answers harden ego; strong answers show increased humility and better habits.
Pick a real disagreement with some consequence, but keep the scope honest; interviewers want to see maturity, not manufactured drama.
Good examples
🟢I disagreed with a teammate about whether we should rush a fix into production or spend a few more hours validating it because the change touched customer-facing behavior.
🟢I had a disagreement during a project about whether to add a shortcut solution or build something slightly more robust since we knew another team would depend on it the next month.
Bad examples
🔴We disagreed about variable names in a small script, and I kept pushing until the reviewer accepted my version because I felt it was cleaner.
🔴A teammate wanted to format the code one way and I preferred another, so I argued my case in chat until the thread went quiet.
Weak stories make the candidate seem attached to low-stakes preferences; strong stories involve a real tradeoff where judgment matters.
Example answers atlevel
Great answers
In an internship, I disagreed with another engineer about a bug fix for a checkout issue. I wanted to patch the specific error quickly, but they were concerned that my change would hide a deeper problem and create more support issues later. Instead of pushing harder in the meeting, I asked if we could walk through the recent incidents together, and I learned they had seen a similar shortcut cause repeated failures before. We ended up doing a small safe fix for the immediate problem and adding one extra check so we could confirm the root cause the next day. That delayed us by a few hours, but it prevented a repeat issue and taught me to ask for context before getting attached to my first solution. I worked with that engineer again later, and our communication was much smoother after that.
At a small startup I built a short onboarding flow and the product designer wanted a heavy animated background to make it look flashier. I was worried it would slow down the experience for users on older phones — our analytics showed about 25–30% of users were on low-end devices and support had notes about slow startup times. Rather than just push back, I made two quick prototypes (with and without the animation), measured load times, and proposed an A/B test so we could let real users decide. The designer agreed, and I also suggested lazy-loading the animation so it wouldn't block the initial view. The experiment showed no meaningful increase in conversions but did hurt load time, so we shipped the lighter version; the situation taught me to resolve design disagreements with data and concrete, low-risk experiments.
Poor answers
I had a disagreement with a teammate about how to implement part of a feature during my internship. I felt my approach was simpler, and I spent a while explaining why it made more sense. Eventually my lead agreed with me, so we moved forward with my version. It worked, and after that I usually trusted my instincts more in those discussions.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid May, 2026
Uber
Mid-level
Mid May, 2026
Amazon
Senior
Mid April, 2026
Meta
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.