Tell me about a conflict you had at work.
The interviewer focused on a conflict that comes from different perspectives or ideas on how to execute a certain task.
Asked at:
Meta
DoorDash
Microsoft
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see how you behave when goals, opinions, or constraints clash at work. They are usually less interested in whether you "won" and more interested in how you understood the other side, how you handled yourself under tension, and whether you moved the situation toward a productive outcome. At higher levels, they also look for whether you resolved conflict in a way that improved team health, decision quality, or execution beyond just the immediate issue.
“Describe a time you and a coworker disagreed on how to proceed. What happened?”
“Tell me about a situation where you had to work through a disagreement at work.”
“Have you ever had to push through a difficult disagreement with someone on your team?”
“Walk me through a work conflict you handled and how you resolved it.”
Key Insights
- Conflict does not need to be dramatic. A strong answer often comes from a meaningful disagreement about priorities, quality, delivery, ownership, or risk tolerance rather than a personal fight.
- You should show your contribution to understanding and resolving the conflict, not just describe what the other person did. Honest ownership and curiosity signal maturity; blame-heavy storytelling is a red flag.
- Do not stop at 'we talked and aligned.' Explain what you learned about the other person's constraints, what tradeoffs were made, and how the relationship or working model changed afterward.
What interviewers probe atlevel
Top Priority
Show calm communication, openness, and respect rather than trying to prove you were right.
Good examples
🟢I suggested we step out of the review thread and talk live for ten minutes so we could clear up the misunderstanding without dragging it out.
🟢I explained my reasoning, acknowledged the risk they raised, and made it clear I was fine changing the plan if the concern held up.
Bad examples
🔴I defended my approach pretty strongly in the review because I wanted to make sure they knew I had thought it through.
🔴We went back and forth in the team chat, and I kept responding point by point until everyone could see my argument.
Weak answers center on winning the exchange; strong answers center on keeping the conversation productive.
Show that you treated the other person as reasonable and tried to understand what they were optimizing for.
Good examples
🟢I asked a follow-up question and learned the reviewer had seen a similar change break a customer workflow before, so their concern made more sense to me.
🟢Once I spoke with my teammate directly, I realized they were worried about support load after launch, not the implementation itself.
Bad examples
🔴They were blocking the change for no real reason, so I kept explaining that my approach was better until they stopped pushing back.
🔴I knew the reviewer was being too cautious, so I mostly focused on proving the code worked.
Weak answers flatten the other person into an obstacle; strong answers uncover the real concern behind the disagreement.
Valuable
Interviewers want to hear that you can disagree and still collaborate well afterward.
Good examples
🟢After we resolved it, I made a point to keep asking for their feedback, and our next review cycles were much smoother.
🟢We ended up working better together because I understood what they looked for in risky changes and started bringing that context earlier.
Bad examples
🔴We did not really talk much after that, but the work still got done.
🔴Once the decision was made, it was fine because they stopped questioning my changes.
Weak answers imply lingering friction; strong answers show trust and collaboration improved.
Pick a real disagreement with some stakes, but one that matches your level of responsibility on a small project.
Good examples
🟢I disagreed with a teammate about whether we were ready to merge because I was worried about a user-facing edge case and they were focused on a deadline.
🟢During a small feature launch, I had a conflict with a reviewer about whether we should add a basic test plan before shipping or follow up later.
Bad examples
🔴We disagreed about tabs versus spaces in a file, and I explained why my style was cleaner until they changed it.
🔴A teammate wanted to name a variable differently than I did, so we went back and forth and eventually used my version.
Weak stories are about tiny preferences; strong stories involve a real tradeoff like quality, delivery, or user impact.
Example answers atlevel
Great answers
On a small bug fix, I had a disagreement with a teammate reviewing my change. I wanted to merge quickly because the bug seemed straightforward, but they were concerned that one edge case could break a common user flow. Instead of arguing in the review thread, I asked if we could talk for a few minutes, and I learned they had seen a similar issue slip through before. We agreed to do a quick test around that scenario, and it showed my first version needed a small adjustment. I updated the change, added a basic test, and we merged later that day. After that, I started sharing my test plan earlier in reviews, and our review discussions became much smoother.
On a small product team, I clashed with our product manager about whether to postpone a minor bug fix in favor of adding a new analytics event they wanted for an upcoming demo. I thought the bug — which caused a confusing state for about 10% of users — would hurt the demo’s message, while they worried analytics would help sell the feature. Instead of getting defensive, I reproduced the bug, pulled usage logs to show how often it happened, and suggested a compromise: I’d ship a quick fix now and add a lightweight analytics event afterward so they’d still have data for the demo. They agreed, and the fix reduced support tickets that week; the analytics went in the next sprint. Since then I make a habit of bringing simple impact data to prioritization conversations so we can reach practical trade-offs faster.
Poor answers
I had a conflict with a reviewer who kept asking for changes on a small fix I wrote. I felt the requests were slowing things down, so I explained in detail why my approach already worked and pushed back on most of the comments. Eventually the thread stopped growing and we merged the change. It showed me that if you are confident in your work, you should stand by it.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late June, 2026
Rubrik
Manager
Late May, 2026
GitHub
Senior
Late May, 2026
eBay
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.