How to Disagree With Your Interviewer

Forty minutes in, you have put a message queue between the API and the worker tier, and the interviewer leans back.

"Why not just call the service directly?"

There is a small, specific silence here, and what happens inside it is worth more to your interviewer than the previous forty minutes. Because the question is almost never a correction. It is a probe, and what it is probing is whether there was a reason underneath the box or whether the box arrived by habit.

Two candidates fail this moment in opposite directions, and both failures are about communication rather than knowledge.

The two failures

The first candidate hears an objection and folds. "Oh — yeah, we could do that, let's do it synchronously." The design changes in four seconds. What that reveals is not flexibility; it is that there was never a position to begin with. If your architecture can be moved by a raised eyebrow, the interviewer now suspects every other box on the board arrived the same way — and they will start testing the ones they had previously accepted.

The second candidate hears an objection and hardens. The voice goes flat, the sentences get shorter, the phrase "as I said" appears. They repeat the original justification more loudly rather than engaging with the new one. This is worse, because the interviewer is no longer learning about the design at all; they are learning what you are like at 4pm on a bad incident.

The gap between them is narrow and it is not about confidence. It is about what you are arguing for.

Defending a decision, versus being defensive

Defending a decision means the decision is the subject of the sentence. You talk about the queue, the failure it prevents, the cost it adds, and the conditions under which you would remove it. The decision is an object on the table that both of you can pick up and turn over.

Being defensive means you are the subject. The unspoken content is "I am not wrong", and everything after that is in service of that claim rather than the design.

You can hear the difference in the first three words. "The reason I'd keep it is…" points at the design. "Well, I did say…" points at you.

The practical trick is to stop using the word I for a sentence or two after pushback. Not forever — just long enough that you are describing a trade-off rather than a person.

Hold the position, but name what it costs

A held position that admits no downside reads as stubbornness. A held position with its price tag attached reads as engineering. The shape has three parts, and it fits comfortably in twenty seconds.

State the reason. Concede the cost honestly. Name the condition that would flip you.

"I'd keep the queue, because the write path has to survive the worker tier being slower than the arrival rate — direct calls make the API's latency a function of the worker's worst day. The cost is real: an extra hop, ordering to think about, and a whole new thing that can be backed up when we're debugging at 3am. If the work is genuinely fast and the volume is modest, that complexity isn't worth it and I'd drop it."

Nobody hearing that thinks you are being difficult. You have agreed with the interviewer's implied criticism — the queue is extra machinery — while keeping your design. And the last clause matters most: by naming what would change your mind, you have shown that the position has edges, which is the entire thing they were probing for.

Changing your mind without collapsing

Sometimes the pushback is right. Sometimes the interviewer knows something about the workload that you did not, and the moment they say it, your design is worse than the alternative. Change it — but change it visibly, and change it for a reason you can point at.

The collapse sounds like: "Yeah, good point, let's do that instead."

The update sounds like: "That changes it — I was assuming the consumer could fall behind for minutes at a time. If the work is bounded and always completes in single-digit milliseconds, the queue is buying me almost nothing and costing me an operational component. Let me take it out and handle the spike with a bounded thread pool instead."

Identical outcome. Completely different signal. One of them threw away the reasoning along with the box; the other kept the reasoning and swapped the box, which means the reasoning is still available to defend the next decision.

Say what new information arrived. That single habit is the whole difference.

When you genuinely do not know

There is a third case that candidates handle worst of all: the interviewer pushes, and you have no idea whether they are right.

Guessing confidently is the worst available option, because it is the one that gets checked. Capitulating is the second worst. The good answer names the shape of your uncertainty.

"I don't know which way that goes, honestly. It depends on whether the read amplification from the fan-out is worse than the write cost of maintaining the index, and I haven't got a feel for the relative sizes here. If I were doing this for real I'd measure it before choosing. If I have to pick now, I'd go with the index because the read path is user-facing and the write path isn't — but that's a preference, not a proof."

That is not a weak answer. It says you know exactly what would settle the question, which is the same skill the whole interview is trying to detect, arriving in an unexpected form.

The thing they are actually measuring

Interviewers are not scoring who won the exchange. They are estimating what it costs to move you — whether new evidence updates your design cheaply, or whether it takes an argument.

Too cheap and you cannot be relied on to hold a decision under pressure from a louder colleague. Too expensive and nobody wants to review your pull requests.

The target is in the middle, and it is reachable with a sentence: here is my reason, here is the price, here is what would change it. Say that, and disagreement stops being a confrontation and becomes the two of you looking at the same problem — which is the version of the interview where people get hired.