Learn

Your disagreement story should not end with you being proved right

30 October 2026 · Behavioral: your part of the story

"Tell me about a time you disagreed with a colleague." You pick the story where you turned out to be right, because that feels safest. You tell it, the interviewer nods, and then asks: "What would you have done if they had overruled you?" You do not have an answer, because in your story nobody had to.

The situation

The disagreement question is a staple of behavioral rounds, and it is rarely about who was right. It checks how you behave when two reasonable people want different things: whether you argue with evidence or with seniority, whether you can propose a cheap way to settle it, and whether you can work with a decision you did not choose. A story whose only ending is "and I was right" answers none of those. It also tends to make the colleague sound foolish, which the interviewer notices.

A post on DEV this week made a related point about ordinary work: engineers describe it like a ticket title, and the investigation and the trade-off disappear. Disagreement stories suffer from the same compression. "We had a debate and went with my approach" is a ticket title.

What goes wrong

Here is an invented story of the common kind:

Our login page was slow, and the tech lead wanted to move sessions into a cache. I thought that was overkill. We discussed it, and in the end we added an index instead, which fixed it. Everyone agreed it was the right call.

Put two follow-ups to it. "How did you convince them?" The story has no answer: "we discussed it" hides the move that mattered. "What did you think of the lead's idea?" The story has only "overkill", which sounds dismissive. And "everyone agreed" closes the door on the most useful part, the moment where the outcome was not yet known.

Now the same incident, told by the person who disagreed:

The lead proposed moving sessions into a cache, which would have taken about two weeks. I did not want to argue opinions, so I asked for one afternoon to look at the query plan first. It showed a full table scan on the session lookup. I added the index, and login got much faster. But the slowest requests were still slow, and when I traced them, they were waiting on the session writes, which the index did not help. So I went back and said the lead had been half right: the cache was still needed for writes, just not urgently. We did it the next quarter, and I wrote the first version.

What to say out loud

The shape is: what each side wanted and why it was reasonable, the cheapest test you proposed, what the test showed, and what you did with a result that did not fully favour you.

The sentence that carries the most weight is the one where you report back against your own position: "I went back and said the lead had been half right." It shows you treated the disagreement as a question about the system, not a contest. It also answers the overrule question before it is asked.

Say the other person's view in its strongest form, in one sentence, before your own: "The lead wanted a cache because session load was going to grow, which was true." If you cannot state their reason fairly, the interviewer will assume you did not hear it at the time either.

If your real story ended with you overruled, tell it. Say what you did next: "I said I disagreed, wrote down the risk in the design doc, and then built it their way." Then say whether the risk happened. A story where you lost the argument and still delivered is often stronger than one where you won.

Avoid numbers you did not measure. "Much faster" is honest if you remember it that way. A precise latency you cannot defend becomes the next question.

The exercise

1. Write the disagreement story you would tell today, unedited. Mark the sentence where the disagreement is settled. If it says "we discussed it" or "in the end", that is the gap.
2. Write the other person's position in one sentence, in a form they would sign. If it contains "overkill", "wrong" or "didn't understand", rewrite it.
3. Write the test or evidence you proposed to settle it, and how long it took. If there was none, say honestly how it was decided.
4. Write what happened after the decision, including anything that went against your view. If it all went your way, find the cost of your approach and name it.
5. Retell the story aloud from memory in under two minutes. In three days, retell it again without notes and check that the other person's reason and your report-back sentence both survived.

Where this fits in Gadfly

Gadfly has four rooms: algorithms, system design, behavioral and code review. The behavioral room keeps a bank of your stories, separates the competencies a story claims from the ones it actually earns, and asks you to retell a story later, as in the last step above. Its report is a set of observations made by rules over what you said, not a hiring prediction.