Tell me about a time when you had a conflict with a peer and you were wrong
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can handle disagreement without ego and whether you can accurately recognize when your own judgment was off. Interviewers are looking for humility, self-awareness, and a credible learning loop: how you understood the other person's perspective, corrected course, and changed your behavior afterward. They also want to see that being wrong did not damage the working relationship.
Key Insights
- You do not get extra credit for choosing a dramatic argument; you get credit for showing mature ownership when the stakes were real enough to matter.
- Honest ownership is the core of this question. If your story spends most of its time proving that you were 'technically still kind of right,' experienced interviewers will notice the defensiveness immediately.
- Make the peer's reasoning legible. Strong answers show why a reasonable person disagreed with you and what you learned from understanding their constraints, assumptions, or risk tolerance.
What interviewers probe atlevel
Top Priority
Even at junior level, interviewers want to see curiosity: you do not need to agree immediately, but you should try to understand what your peer was worried about.
Good examples
🟢I asked them to walk me through the failure case they were worried about, and that helped me see a part of the system I hadn't worked on before.
🟢After the meeting I followed up one-on-one because I realized I didn't actually understand why they were pushing back. Once they explained the dependency, their concern made sense.
Bad examples
🔴We went back and forth in the pull request until our lead clarified what we should do.
🔴I explained my reasoning a few times, and once they showed me an example I understood why they preferred the other option.
Weak answers focus on defending a position until someone else settles it; strong answers show active effort to understand the peer's reasoning.
Valuable
Example answers atlevel
Great answers
On a small feature project, I disagreed with another engineer about skipping some validation because I thought the input was already clean from an earlier step. I pushed pretty hard in the code review and treated their concern like unnecessary caution. They asked me to walk through a few real examples with them, and one of them showed a path I hadn't considered where bad data could still get through. At that point it was clear I was wrong, and if we had shipped my version we probably would have created a bug that was annoying to trace. I updated the code, thanked them for pushing on it, and asked them to re-review the change to make sure I had fixed it properly. Since then, when someone raises a risk in an area I don't own deeply, I ask them to show me the failure case before I argue for simplicity.
At my previous job supporting an enterprise product, a key customer reported a bug that was causing a service outage. I insisted we follow our normal triage and approval process before making any production changes because I was worried about breaking other customers. A support engineer begged for a quick hotfix and said the impact was severe; I still pushed back and told them to file the ticket and wait for sign-off. Within an hour the customer escalated to our account team and it became clear I had put process ahead of uptime. I admitted I was wrong, stayed late to help prepare and deploy the fix, apologized to the team, and then worked with them to create a documented “emergency change” path so we could respond faster next time without abandoning controls.
Poor answers
I had a disagreement with a peer about how to implement a feature, because I wanted to keep it simple and they wanted more checks. We talked through it for a while and eventually I went with their approach so we could keep moving. It ended up being fine, and I think the main takeaway was that different engineers have different styles. Overall it worked out because I was flexible.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late May, 2026
Follow up included: how was the conflict handled, what did you learn and how you went about discovering your colleague was right
Late January, 2026
Early November, 2025
Tell me about a time when you had a conflict with peer and you were wrong
Hello Interview Premium
Your account is free and you can post anonymously if you choose.