Tell me about a time when you had a conflict with a peer and you were wrong
Asked at:
Oracle
Meta
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.
“Describe a time you disagreed with a coworker and later realized their perspective was the better one.”
“Tell me about a situation where you pushed for something with a peer, then had to admit you were wrong.”
“Have you ever been in a disagreement with another engineer and changed your mind? What happened?”
“What's an example of a conflict with a colleague where your initial judgment didn't hold up?”
“Walk me through a peer disagreement where you learned that your approach or assumption was off.”
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
Once you realize you're wrong, the key is not just agreeing; it's helping repair the work and the relationship.
Good examples
🟢After I realized they were right, I thanked them, updated the implementation, and asked them to review the revised version to make sure I had addressed the issue correctly.
🟢I owned the mistake in our next sync, helped clean up the affected work, and documented the lesson so I would not repeat it on a similar task.
Bad examples
🔴Once I understood their point, I just updated my code and moved on.
🔴I accepted their suggestion and we finished the task, so it was resolved.
Weak answers stop at passive acceptance; strong answers show active repair and follow-through.
At junior level, interviewers mainly want to see that you can plainly admit a mistake, name your part in the conflict, and avoid blaming the other person.
Good examples
🟢I was convinced my approach was simpler, and I pushed for it too hard. After we tested both options, it was clear I had missed an edge case they had been warning me about.
🟢I initially treated their concern as overthinking, but I was wrong. They understood the dependency better than I did, and my proposal would have created extra rework.
Bad examples
🔴I disagreed with my teammate about how to implement something, but it turned out we were both a little wrong because the requirements were unclear.
🔴My peer pushed back on my approach and later we changed it, but I still think my original idea would have worked if we'd had more time.
Weak answers blur or dilute responsibility; strong answers state plainly what the candidate got wrong and why.
Valuable
For junior candidates, learning can be simple, but it should be concrete enough that an interviewer believes your behavior changed.
Good examples
🟢Since then, when I disagree on implementation details, I first ask what risks the other person sees before defending my approach.
🟢That experience taught me not to assume I understand adjacent code just because my part seems straightforward, so now I do a quick walkthrough with the owner before proposing changes.
Bad examples
🔴It taught me to listen more to teammates.
🔴I learned to be more careful before pushing back.
Weak answers give generic morals; strong answers show a repeatable behavior change.
Your story does not need huge business impact, but it should be about a real disagreement with meaningful consequences for the work.
Good examples
🟢We disagreed about whether a shortcut in the implementation was safe, and choosing poorly would have caused rework in a feature we were actively building.
🟢The conflict was about whether to make a change in one part of the code without checking a dependent path, which mattered because it affected correctness, not just style.
Bad examples
🔴We disagreed about variable naming and eventually picked their suggestion.
🔴A teammate wanted tabs and I preferred spaces, and I realized later they were right because it matched the project style.
Weak answers pick trivial disagreements; strong answers choose conflicts that reveal judgment under modest but real stakes.
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 January, 2026
Oracle
Senior
Early November, 2025
Meta
Staff
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.