Your System Design Answer Is Right But Unconvincing

"Your System Design Answer Is Right But Unconvincing"

Hey, welcome back. I'm Gaz, this is Gazar Breakpoint, and today I want to talk about something I've watched derail dozens of strong engineers: you give a system design answer that is completely correct, and you still get the no.

Let me start with what that actually looks like.

Picture two engineers in two separate interviews. Same prompt. They draw the identical architecture. Same boxes, same arrows, same database. One walks out rated staff. The other gets "technically fine, but not at this level."

Same picture. Different score. So what was different?

It wasn't the design. It was everything around the boxes. The numbers one of them put on it. The trade-off they named out loud. The failure case they owned. The way they said what they would do differently at ten times the scale.

Here is the uncomfortable truth. The interviewer was never grading your diagram. They already know the textbook answer. What they are actually probing is one question: can I trust this person to make an ambiguous call when I am not in the room?

Correctness is table stakes. It gets you into the conversation. It does not move your level. Conviction does. And conviction is not a personality trait, it is a structure you can learn.

So here is the core idea. You are not graded on the design. You are graded on the reasoning that survives questions.

A correct answer with invisible reasoning reads as lucky. The same answer with the reasoning exposed reads as senior. Your whole job in that room is to make the thinking visible.

And there is a sentence structure for it. Once you hear it, you will not be able to un-hear it. It has three parts. Name the trade-off. Name the alternative you rejected. Say why this one fits your constraints.

Put together, it sounds like this. "I would use X over Y, because for this workload I care more about A than B, and I am willing to pay the cost of C."

That is the entire move. Let me show you why each part carries weight.

Naming the trade-off proves you know nothing is free. The fastest way to sound junior is to present a choice like it has no downside. Naming the alternative proves you saw the option space. And saying why it fits your constraints is where the seniority lives, because juniors recite the properties of a technology, while seniors connect a property to the specific problem in front of them.

Let me make this concrete with a real prompt. Design a rate limiter.

Here is the answer most people give, and it is correct. "I would use Redis, increment a counter per user with a time to live, and reject anyone over the limit." That works in production. In an interview it scores about a four out of ten. Watch what happens when I take the exact same idea and run it through the structure.

First, I put a number on it before I draw anything. Say fifty thousand requests a second at peak, two million users. Two million counters at thirty bytes each is around sixty megabytes, which fits in one Redis node trivially, and fifty thousand operations a second is well under a single primary. The numbers just told me a centralized node works here, and roughly where it stops working. I have not changed the technology. I have made the reasoning visible.

Then I name the trade-off. "Token bucket over a fixed window, because a fixed window lets someone burst to double the limit right at the boundary, and I would rather pay a little complexity for smooth, tunable limiting."

And then the part that actually separates staff from senior. What happens when the limiter's Redis goes down? Most people never say. I will. "If the limiter cannot reach Redis, I fail open. I let requests through rather than take down the whole API over a rate limiter, and I make that fail open versus fail closed a per route decision, because a payments endpoint might choose differently than search."

Saying fail open versus fail closed, on purpose, is the highest signal sentence you can say in a design review. Same Redis, same basic idea the junior gave, but now there is a number, a named trade-off, and an owned failure mode. That is the move from a four to an eight, and the architecture barely changed.

Quick gut check before we wrap. Five tells that quietly cap you at senior, no matter how good the design is. Reaching for the technology before the numbers. Saying "it scales" with nothing behind it. Listing three options and never committing. Describing only the happy path. And not being able to say what you would defer at ten times the scale.

The fix for every single one is the same. Slow down and make the reasoning visible. Even mid answer, "let me back up and put some numbers on this" is never too late, and it reads as more senior, not less.

So, three things to take into your next interview. One, you are graded on the reasoning that survives questions, not the diagram. Two, make it visible with one sentence: trade-off, alternative, why it fits. Three, the layers that level up any answer are a number, a named trade-off, and an owned failure mode.

Get those right and the same architecture you already know how to draw starts scoring a level higher, because now they can see you think.

If you want to drill this under real pushback, that is exactly what my System Design cohort on Maven is built for, and there is a free lesson on this exact topic linked below. I also do one to one mentorship for engineers targeting staff and principal. Subscribe if you want one of these every week, and I will see you next time.