The Ten Failure Modes of System Design Interviews, and the Guardrail for Each

After conducting system design interviews for a while, I noticed my debrief notes had started repeating themselves. The designs varied plenty, but the ways interviews went wrong didn't, and when I finally tried to write the list out, it came to roughly ten entries. The encouraging part is that almost none of the ten are knowledge gaps. They're process failures: things people do under time pressure that they would never endorse on reflection, which makes them fixable without reading another four hundred pages of distributed systems material. The list comes out of my own notes, though, and practices vary company to company, so hold any specific claim loosely at any given employer.

Each failure mode below comes with two things, a tell and a guard. The tell is the observable thing in your own behavior that lets you catch the failure while it's happening, because mid-interview you won't have spare attention for open-ended self-reflection, but you can notice a specific sentence leaving your mouth. The guard is a rule you commit to before the interview starts, on the theory that minute 25 of a design interview is a terrible time to be making policy decisions. Deciding in advance is most of what makes a guard hold once the adrenaline arrives.

1. Drawing before asking anything

Most design prompts are one vague sentence on purpose, and the ambiguity is part of what's being tested. The most common opening failure I watched was the marker moving inside the first minute: boxes appearing before a single question about who uses the system, how much traffic it sees, or how bad it is when it's wrong. In the loops I was part of, clarifying questions were graded as real signal in their own right, and skipping them was one of the more reliable downlevel signals in the debriefs I sat in.

The tell: something is on the board and you can't yet state the read/write ratio, the rough scale, or what the system is allowed to get wrong.

The guard: nothing gets drawn for the first five minutes. Spend them asking questions and writing the answers in a corner of the board, where they'll sit for the rest of the interview keeping you honest.

2. An estimate that decides nothing

The back-of-envelope step exists to pick which design you build: whether the data fits on one machine, whether the workload is read heavy enough that caching does most of the carrying, whether the write path is the bottleneck you design around. I've written up the small amount of math involved separately, so here I'll only describe the failure, which comes in two versions. The first is skipping the math and designing for an imagined scale, which is how a prompt whose numbers say "one solid Postgres box" ends up with a message queue between every pair of services. The second is running the math dutifully, announcing the result, and then designing as though it had come out differently, which I saw more often than you'd expect.

The tell: your design would look identical if the numbers were 100x bigger or 100x smaller.

The guard: the estimate isn't finished until you've said one conclusion sentence out loud ("read heavy, fits in memory, so the interesting work is in the caching layer"), and that sentence gets veto power over every component you add afterward.

3. Losing the structure of the interview

Structure collapse is the entry I'd put first if this list were ranked by damage: rambling, jumping between layers, being deep in index selection while half the high-level boxes are still unlabeled. In the debriefs I sat in, it ended more candidacies than missing knowledge did, partly because an interviewer can rescue a knowledge gap with a hint but can't grade a design they can't follow. The five-phase skeleton (requirements, estimates, high level, deep dive, tradeoffs) is laid out in the article on passing these interviews without scale experience, and you should memorize it.

The tell: you can't immediately name which phase of the interview you're in.

The guard: write the five phase names in a corner of the board before you start, with rough minute budgets, and announce each transition out loud ("that's the high level, let me pick the write path to go deep on"). The announcement helps the interviewer follow you, and it forces you to notice where you are.

4. Drawing a box you can't defend

This one usually starts with good intentions: the candidate read an architecture blog post recently, the component in it was impressive, and now it's on the board with the candidate hoping nobody asks about it. I watched this go badly far more often than a boring design ever did, because design interviews run on follow-up questions, and a component you half understand converts every follow-up into a coin flip.

The tell: you feel relief when the interviewer's attention moves past a box.

The guard: draw nothing you couldn't survive two follow-up questions about. A cache box means being ready for the invalidation question and the staleness question. "We'll shard it" means being ready for the shard key question. If a component fails that test, either leave it off or name the uncertainty as you draw it, which goes over far better than being caught.

5. The word "just" in front of the hard part

"And then it just gets stored." "The workers just pick jobs off the queue." In the interviews I've conducted, "just" and "simply" were dependable markers for the exact part of the design the candidate hadn't thought through, and I'd usually steer straight at whatever the word was covering for. The write path got this more than anything else: plenty of candidates spent all their attention on the read side and waved one hand at how data actually gets in, stays consistent, and survives a crash.

The tell: the word "just" in your own sentence, attached to the part of the system that's hard.

The guard: before you call the high level done, trace one write and one read end to end through every box on the board, out loud. If the trace stalls anywhere, you've found where the deep dive should visit, ideally before the interviewer finds it for you.

6. A technology name with no because attached

"I'll use Postgres" is a decision. "Postgres over a document store, because the data is relational and the write volume doesn't justify giving up joins" is a graded answer, and in my experience the second version is what survives into the written feedback. Naming technologies without reasons was among the most common failures at every level, I think because it feels like progress: the box gets a label, the diagram advances, and none of the judgment the interview measures ever shows up.

The tell: a technology name leaves your mouth and the sentence contains no "because".

The guard: every named component comes with one tradeoff sentence naming the alternative you rejected and why. If you can't produce the sentence, that's failure mode four again, and the same rule applies.

7. Fighting the steer

Somewhere past the midpoint the interviewer will redirect you ("let's talk about how the feed gets generated"), and a steer is the interviewer telling you which rubric box they still can't fill in. Following it is almost always correct. What I watched instead, regularly, was the steer treated as an interruption: a minute of token attention, then a pull back toward rehearsed material, which went over badly in the room and worse in the debrief. I've played out a complete interview, both steers included, in the rate limiter walkthrough if you want to see the mechanic up close.

The tell: irritation that they've pulled you off your plan, or hearing yourself say "I'll come back to that" for the second time.

The guard: pre-commit that the steer outranks the plan, always. Whatever you were saving for later either comes up naturally or mattered less than you thought.

8. Vanishing into the board

Design interviews contain more legitimate thinking pauses than coding interviews, which makes the silence problem harder rather than easier. The failure isn't the pause itself (a stated "give me 30 seconds to think" is completely fine, and needing a beat to process is not a flaw); the failure is vanishing: turning to the board, drawing in silence, and leaving the interviewer with nothing to grade for two minutes. Interviewers can't grade what they can't hear, and that mechanic applies to whiteboards at least as much as to code.

The tell: you surface from thought and can't remember the last sentence you said out loud.

The guard: announce every pause with a purpose and a duration ("give me 30 seconds to sketch the write path before I explain it"). It turns dead air into evidence that you manage your own thinking.

9. The borrowed war story

Under pressure, "have you dealt with this at scale?" can pull an invented anecdote out of otherwise honest people, and I understand the temptation completely: the question feels like a trap, and a story feels like the way out. In the interviews I've conducted, the second follow-up question found the edge of a bluffed story just about every time, and design interviews are where that unravels fastest, because probing depth is the entire point of the interview. Meanwhile "I haven't run this at scale, but here's how I'd reason about it" scored fine, over and over.

The tell: you're mid-sentence describing production experience you don't have, and part of you is already dreading the follow-up.

The guard: write the honest sentence down before the interview and use it verbatim when the moment comes. First-principles reasoning, clearly labeled as such, is a strong answer at every level I've graded. A collapsed bluff loses the interview and takes some trust in your other answers down with it.

10. The happy path eats the clock

The last five minutes of a design interview (tradeoffs, what breaks first, what you'd change at 10x) carried real weight in the senior-versus-mid decisions I watched, and it's also the section candidates most reliably never reached. Rarely because they couldn't discuss failure; usually because minute 38 found them still adding features to the happy path, often features nobody had asked about.

The tell: you're adding a capability the interviewer never mentioned, and there are ten minutes left.

The guard: treat the final five minutes as already spent before the interview begins. When the clock reaches them, stop building and start breaking your own design: what fails first as load grows, which data you'd be sad about losing, which box you'd redesign given another week. Ending an interview by critiquing your own work, unprompted, was one of the more reliable strong signals I saw.

What to do with a list of ten

Reading a list like this, the natural move is to feel guilty of all ten. Nearly everybody commits several of these under pressure, even people who build distributed systems for a living, including myself in some mocks I've done when I've become rusty. In most of the interviews I've conducted the difference between a rough interview and a strong one was two or three failures caught early rather than zero committed. Pick the two or three you recognize, write their guards somewhere you'll see them, and leave the rest for another week.

Guards on paper don't hold under adrenaline until they've been rehearsed under something like real conditions, which means timed interviews, out loud, with the guards in front of you. A friend and a whiteboard cover most of that for free, and the solo practice routine covers the gap when no friend is available (a recorded prompt and a self-grading rubric will catch failures five, six, and eight on tape with humbling clarity). Peer mocks on Pramp and paid human mocks on interviewing.io both work well too. And if you want interviews on demand against something that steers you mid-design and grades the result afterward, that's part of what we build at Preppable.

One last note on this list. Several of the guards above compress an entire topic into a sentence (the two-follow-ups rule alone is carrying cache invalidation, shard keys, and queue backpressure), so over the coming months I'll be unpacking the major building blocks one at a time, with this list as the map they hang off; the rate limiter walkthrough already covers one of them end to end. In the meantime, these ten cover most of what I watched separate interviews that went well from interviews that didn't, and every one of them is trainable. The failures that sink people are mostly process habits, and process habits respond to a few weeks of practice far faster than any amount of additional reading would.