Tell me about a conflict you had at work.

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.