This is the classic peer-conflict behavioral. The interviewer wants to see you can disagree productively with someone you have no authority over.

Structure it in STAR

• Situation: "Two of us on the same team disagreed about X."
• Task: What you were each trying to achieve, and why it mattered.
• Action: Listened first → found the real concern → used data/a prototype → agreed on a path. Use "I".
• Result: What shipped, the measurable outcome, the lesson.

Example

Situation: A teammate and I disagreed on state management for a new dashboard — he wanted Redux Toolkit, I felt Zustand + React Query was lighter for our needs. Task: We had to pick one before sprint planning; the rest of the team would build on it. Action: Rather than debating in Slack, I asked him to list the requirements he was protecting — mostly devtools, middleware, and team familiarity. I built two small spikes implementing the same feature in both. We reviewed them together against his list and our actual needs (mostly server cache, little global client state). Result: The spikes made it obvious — most of our "state" was server cache, so React Query did the heavy lifting and Zustand covered the rest. He agreed. We shipped faster than a Redux setup would've allowed, and I learned to turn an opinion debate into a requirements comparison early.

What earns points

• It's a real technical disagreement, not "he was annoying."
• You moved it out of Slack into a real conversation.
• You converted opinions into requirements — a concrete, senior move.
• The decision was made by evidence, and you were genuinely open to being wrong.
• You name the lesson.

Senior framing

The mature version shows that you see peer conflict as a decision that hasn't been made with enough information yet. Your move is to gather that information (spikes, data, requirements lists) so the right answer becomes obvious to everyone — including you. That's more convincing than "I explained why I was right and they came around."