Course Content

Earning trust: disagree and commit, anti-patterns and a worked answer

The story where you lost the argument and executed the decision properly anyway is frequently the highest-scoring answer available, and almost nobody prepares one.

This lesson builds that story first, because it answers the question interviewers care about most: what you do for the six months after you lose. Then it covers the three anti-patterns candidates most often bring as their best conflict story, and ends with a full senior answer and the drilling that followed.

Losing the argument and then executing properly proves something winning it never can.

Why disagree and commit scores so well

Two reasons.

It is the rarer signal. Interviewers hear "I convinced them" constantly. They hear "I was overruled and then made the decision succeed" rarely, and it answers the question they actually care about: what do you do for the six months after you lose?

It is the behaviour that costs a team most when absent. The engineer who lost an argument and spends two quarters quietly proving the decision was wrong — slow-walking, reminding people, saying "well, as I mentioned in March" — is a specific and expensive failure mode. Interviewers are screening for it directly.

The shape of a strong answer

Four parts, and the third is the one people skip:

You disagreed clearly, on the record, before the decision. Not afterwards.
The decision went the other way, and you can state why without bitterness.
You then made it work, actively — and can name what you did.
You can say honestly how it turned out, including if it turned out you were right.

A worked mini-example

Invented. The candidate is Rui, a senior engineer.

Interviewer: Tell me about a decision that went against you.

Rui: We were choosing between building our own feature-flag service and buying one. I argued for buying, fairly hard, in a written document — my case was that we'd spend about a quarter building something that would be worse than a product we could have for roughly thirty thousand a year, and the quarter was the expensive part, not the money.

My director decided to build, for a reason I disagreed with but understood: we had specific requirements around data residency that the vendors we'd looked at couldn't meet without a contract negotiation nobody had bandwidth for.

What I did after that mattered more than the argument. I asked to own the build, which surprised people given I'd argued against it. Two reasons: I had the clearest picture of what the bought product would have given us, so I knew what the bar was; and if I'd stepped back, the team would have read that as me sulking, which would have poisoned the project.

I ran it in six weeks rather than a quarter by cutting the parts I'd been using in my own argument against building — no percentage rollouts in version one, no audit screen, only boolean flags with an interface and an approval step. Those were the things I'd said made it a quarter of work. Taking them out was the honest consequence of my own analysis.

Interviewer: How did it turn out?

Rui: Mostly fine, and partly I was right. It's been running two years and it does what we need. But we did spend about three weeks in year two adding percentage rollouts, which is roughly what I'd predicted. I don't think that makes the decision wrong — the residency requirement was real and I'd underweighted it.

Interviewer: Did you ever say "I told you so"?

Rui: Not out loud, and I'd like to claim that's discipline, but honestly by the time those three weeks came around I'd stopped caring who'd been right. What I did do, which I think was more useful, was write two paragraphs in the doc for the next build-or-buy decision about what we'd learned on cost. Making it a general lesson rather than a personal one was the only version that was going to be read.

What makes this answer work

The disagreement was real, documented, and stated with numbers.
The other side's reason is given accurately and without sarcasm.
Rui took on the work they argued against — the strongest possible commitment evidence.
The scope reduction came from their own argument, which is intellectually honest.
"Partly I was right" is stated without triumph, and immediately balanced.

The version that fails

"I said we should buy, they decided to build, so we built it. It took a quarter, exactly like I said it would."

Accurate, brief, and it scores as a warning. The write-up: "Candidate's account of a decision they lost centred on their own vindication. No evidence of commitment behaviour."

Anti-patterns

Disagree and commit is the story people forget to prepare. The anti-patterns are the stories they prepare instead: three of them, all of which candidates offer as their best conflict story.

Each anti-pattern removes exactly the thing being measured: your conduct while the disagreement was live.

Anti-pattern 1 — my colleague was incompetent

"I was working with a developer who honestly wasn't at the level the role required. Their pull requests needed three or four rounds of review every time and they kept making the same mistakes. Eventually I had to talk to my manager about it."

Every sentence is about the other person. Even if all of it is true, the write-up is:

"Two-thirds of the answer characterised a colleague's competence. When asked what they tried before escalating, gave 'I left detailed review comments'. No evidence of a direct conversation. Concern about how this candidate would describe a teammate internally."

The salvageable version of the same events exists: it is a Developing Others story (Section 13) about how you had a direct conversation and what changed. But it needs a direct conversation in it, and if there wasn't one, the story is not usable.

Anti-pattern 2 — the trivial disagreement

"We had a disagreement about whether to use a monorepo. I preferred separate repos, we talked it through, and we went with the monorepo, and honestly it's been fine."

Nothing was at stake, nothing changed, and the candidate has revealed that this is their best example. The second-order signal is worse than the first.

Anti-pattern 3 — the unresolved story

"We never really agreed, so in the end I did it my way on my services and they did it their way on theirs. It's still like that."

This is the most common ending in real engineering life and one of the worst to bring to an interview. It shows an unresolved split, ongoing divergence, and a candidate who is comfortable with both.

A worked example

Here is Rui again, this time answering the plain conflict question with a story where the first move was a mistake.

Worked example — "Tell me about a conflict with a colleague"

Rui, invented, interviewing for a senior backend role. About three and a half minutes, then the drilling.

Rui: "Context — Meridian Logistics. I was leading the build of a shipment-tracking service for our team. It needed to publish events that another team's notification platform would consume, so their staff engineer, Kwame, had to approve the design.

The review stalled. Three weeks, four rounds of comments, and the comments were getting shorter and less specific each round. We had a launch commitment to a customer for the end of the following month, so three weeks was about a third of the runway gone.

I'll be honest about what I did first, because it was the wrong move. I went to my manager and asked them to unblock it. My framing was that Kwame was being obstructive. My manager asked me one question — 'what did they say when you asked them what the actual objection was?' — and I didn't have an answer, because I hadn't asked. I'd been responding to the comments rather than to the person.

So I set up thirty minutes with Kwame and opened with a version of that question: what would have to be true for you to be comfortable approving this?

Their answer had almost nothing to do with the comments they'd been leaving. The design had my team publishing events and their platform doing the fan-out, retries, and dead-letter handling. Which is a normal split. But their team was four people, already carrying nine pages a week, and they'd lost two engineers in the previous year partly over on-call load. Taking on delivery guarantees for another team's event stream, with no headcount, was a real cost they had no way to absorb. And they'd been burned before — another team had done exactly this two years earlier and the operational load had stayed with them permanently.

The comments in the review had been proxies for that, because 'my team can't absorb this' is a hard thing to write in a design document.

What I changed: I moved the retry and dead-letter handling to our side. We publish only after we've confirmed delivery semantics we own, and their platform consumes a stream that is already guaranteed. It cost us about two weeks of extra work and it made our service more complicated. It was still the right call — we were the team with the headcount and the motivation.

Result: approved in two days. We launched two weeks late rather than the eight weeks the stall was heading for. And about four months later Kwame and I co-wrote the internal guidance on event-ownership boundaries, which was more useful than the original project.

Reflection: two things. The design change I'd probably find again eventually. The behaviour change is the one that stuck — I now treat a stalled review as a signal that there is an objection nobody has written down, and I go and ask rather than answering the comments. And I escalated before I'd had a single direct conversation, which I'm not proud of."

The follow-ups

Interviewer: You said their argument was about on-call load. Make the case for their side as strongly as you can — as if you were them.

Rui: Their case is stronger than mine was, honestly. A four-person rota at nine pages a week is already past the point where people start leaving; they'd lost two in a year and could name the reason. Every event stream they take delivery guarantees for adds a class of 3am page that they can't fix, because the bug is in someone else's producer. They'd watched exactly that happen two years earlier and the load never went back. So from where they sat, approving my design meant accepting a permanent, unbounded, un-fixable-by-them increase in on-call burden in exchange for helping another team hit a date. The rational move is to stall, because there's no mechanism that makes saying no directly safe.

And that last part is the bit I'd add now: the reason it came out as vague review comments rather than as a clear objection is that our organisation didn't have a way for a team to say "we don't have capacity to own this" that carried any weight. So they used the only lever they had.

Interviewer: Let's go back to the escalation. What exactly did you say to your manager, and what did they say?

Rui: I said something close to "Kwame is blocking the tracking design and I don't think the comments are in good faith — can you talk to their manager?" Which is a bad sentence in at least two ways. My manager didn't take the bait. They asked what the objection was, I said the comments were about schema versioning, and they asked what happened when I asked directly. I said I'd replied in the document. They said, roughly, "that's not the same thing, go and ask."

I was annoyed at the time, because I wanted the problem solved rather than a lesson. In retrospect it was the right call and it took them about ninety seconds.

Interviewer: What if Kwame hadn't come around? Suppose you'd made the change and they still didn't approve.

Rui: Then I'd have escalated, and I think that would have been legitimate — but the escalation would have looked completely different. Instead of "they're blocking me", it would have been "we have two teams with a real resourcing conflict, here are the two options, here's what each costs, we need someone to pick". That's a decision for our managers to make. The thing I'd got wrong the first time wasn't escalating, it was escalating a personality problem I'd invented instead of a resourcing problem that was real.

I'd also have had a much better case, because I could have said what I'd already tried.

Interviewer: You said you took on two weeks of extra work. How did your own team feel about that?

Rui: Not great initially, and one of them said what I'd been thinking a week earlier — that we were absorbing cost for someone else's staffing problem. I didn't have a clean answer to that. What I said was that we were the team with the deadline and the headcount, so we were the team that could afford it, and that I'd rather spend two weeks than eight.

The thing that actually settled it was that I brought the on-call numbers into our team meeting rather than paraphrasing them. Nine pages a week on four people, two departures. That landed differently than "the other team is worried about load".

Interviewer: And where is that relationship now?

Rui: Good, and usefully so. Kwame is the person I go to first when I'm designing anything that crosses into their platform, which saves me the three-week version of this conversation every time. The guidance document came out of that. I'd say the project was worth two weeks and the relationship was worth considerably more.

What the write-up said

"Earns Trust — strong hire. Volunteered their own misstep (escalated before engaging) unprompted and did not soften it. Stated the counterparty's position at full strength when asked, including the organisational reason it was expressed indirectly — this was the strongest moment in the interview. Changed their own design at real cost rather than arguing. Handled the counterfactual question about a failed resolution with a specific, better-shaped escalation rather than a hypothetical. Evidence of a durable relationship outcome (co-authored guidance, ongoing consultation). No characterisation of the colleague at any point in 20 minutes. Also usable evidence for Delivery."

Notice what is absent from that write-up: any assessment of whether Rui's original design was correct. Nobody scored it, and nobody asked.