Q1 of 32 · Behavioural

Tell me about a time you disagreed with a developer about a bug.

BehaviouralJuniorbehaviouralcollaborationconflictstar

Short answer

Short answer: Use STAR. Pick a real example where you held a position with evidence, listened to the developer's reasoning, and reached a decision based on user impact rather than ego. The lesson is the point, not the disagreement.

Detail

This question probes your collaboration style and your ability to disagree without being a problem. The framework to lean on is STAR: Situation, Task, Action, Result.

A good answer has three load-bearing pieces:

  1. You came with evidence, not opinion. "I think this is a bug" is weaker than "I checked the spec, the design Figma, and reproduced it on three browsers — here's what I found." Evidence depersonalises the disagreement.
  2. You listened to the developer's framing. Often "this is a bug" and "this is intentional" are both partially true — the spec is ambiguous, the edge case wasn't considered, or there's a constraint you didn't know about. Showing curiosity is a strong signal.
  3. You escalated to user impact, not authority. The right resolution mechanism is "what's best for the user / business," not "who's senior" or "who shouts loudest." If the two of you couldn't agree, you involved a PM or designer to break the tie.

End with the lesson. Interviewers care less about whether you "won" and more about what you learned. "Next time I'd open the conversation by asking what they expected before saying I think it's broken" is a much better close than "and they agreed I was right."

A red flag to avoid: war stories that paint the developer as incompetent. That signals you'll be hard to work with.

// MODEL ANSWER

I will give you a concrete example using STAR. We were testing a new checkout flow and I found that submitting an order without a billing address returned a 200 OK with no error — the form just reset silently. I raised it as a bug, but the developer said billing address was optional. Rather than going back and forth on opinions, I returned with the spec, which stated billing address is required for orders over fifty pounds, and a recording of the silent failure on a seventy-five-pound order. That shifted the conversation from my view versus theirs to what does the spec say and what is the user impact. We brought the PM in to clarify, confirmed the spec meant required, and the fix went in before release. What I took away is to open with a shared reference point — the spec, a design, a user research finding — before saying something is broken. Leading with evidence removes the ego from the conversation. I would also now ask the developer what they expected to happen before asserting something is wrong, because sometimes there is context I am missing that changes the picture entirely.

// WHAT INTERVIEWERS LOOK FOR

Evidence-based reasoning, willingness to listen, and a resolution mechanism rooted in user impact. They also want a stated lesson — what would you do differently.

// COMMON PITFALL

Telling the story as a hero narrative where you were right and the developer was wrong. Or having no clear lesson at the end — interviewers read that as 'didn't learn from it.'

// Related questions

Tell me about a time you worked with someone whose communication style was very different from yours.

Behavioural

Describe a time you had to give a developer difficult feedback.

Behavioural