What to do if you go blank in a System Design Interview

The problem lands - "Design a URL shortener" - and you know exactly what a system design interview wants from you. You've done the prep. You know there's a framework, you know roughly what the answer looks like. And yet, right now, your mind is a blank sheet. Nothing comes. This specific freeze - the one at minute zero, before you've drawn a single box, where you can't recall anything even though you know what you're supposed to do - is the most common way people stall, and also the most recoverable. Because here's the trick: the start of a system design interview needs almost zero recall.

This is the second post in the System Design Guide series. The first covered the first thing to do when a problem arrives (scope it). This one is for when the problem arrives and your memory simply refuses to hand you anything to work with.

Why the opening blank happens (and why it barely matters)

The start is where anxiety peaks. The problem has just been stated, the interviewer is looking at you, and there's an unspoken "impress me" hanging in the air. Under that spotlight your brain does the least helpful thing possible: it tries to retrieve the finished architecture all at once, fails, and returns nothing. That's the blank.

Here is why it doesn't matter: you are not being asked to recall a design. You are being asked to run a procedure. And the first steps of that procedure are the same for every problem ever asked - "Design Twitter," "Design a rate limiter," "Design a parking lot" - so you never have to remember anything specific to begin. Answering fast earns you nothing anyway; a quick answer with no thinking behind it is a red flag, not a bonus. So the pressure to instantly produce brilliance is imaginary. Slow down and start the procedure.

Move 1: buy the moment, out loud

The worst response to the blank is silent panic. Ten seconds of quiet feels endless and tells the interviewer nothing. Fill it with an honest, useful sentence:

"Let me take a few seconds to make sure I understand the problem before I dive in."

That's not stalling - it's the correct opening for a strong candidate, and it happens to buy you the exact breathing room you need for recall to come back online. Say it, then breathe. You've now started, and starting is most of the battle.

Move 2: say the problem back in your own words

You do not need to remember anything to restate what you were just told. Repeat the prompt back in your own phrasing:

"So we're building a service that takes a long URL and returns a short one, and redirects the short one back to the original. Let me make sure I've got the scope right."

This move is almost magic for a blank mind. It requires zero recall, it re-reads the problem into your working memory, and the act of putting it into words tends to dislodge whatever was frozen. Nine times out of ten, the next thought arrives while you're mid-sentence.

Move 3: run the one script that fits every problem

When you can't recall the architecture, don't reach for the architecture. Reach for the questions, because clarifying questions are a universal script that needs no memory of the specific system. You don't need to remember how a URL shortener is built to ask:

• What are the core features we must support?
• How many users / how much traffic?
• Read-heavy or write-heavy?
• Any latency or consistency requirements?

These same four questions open any problem. Ask them, and the interviewer starts handing you material to work with - which means you're no longer generating from an empty head, you're responding to their answers. The blank is over the moment you stop trying to produce and start asking.

Move 4: read the entities straight off the prompt

Your data model's first draft is hiding in the problem statement - you copy it, you don't recall it. The nouns in the sentence are your entities:

• "Design Twitter" -> user, tweet, follow, timeline.
• "Design a URL shortener" -> URL, short code, click.
• "Design a chat app" -> user, message, conversation.

Point at the prompt and name the obvious nouns out loud. Now you have entities on the board, and entities pull the next questions out of you ("a tweet has an author, so there's a relationship here..."). You reconstructed the starting point from the sentence in front of you, not from memory.

Move 5: write everything on the board

Every clarified feature, every number, every noun - put it on the whiteboard as it comes. This is not just for the interviewer; it's how you stop running on recall. Once the requirements and entities are written down, your next step is sitting there in front of you instead of trapped somewhere in your memory. You've offloaded the remembering to the board and freed your head to just react to what's on it. A blank mind and a blank board is panic; a blank mind and a board with the requirements on it is a design in progress.

Move 6: lean on the one thing you actually memorized

You don't need to have memorized architectures. You need exactly one fact at t=0: always start by scoping. That single rule is the seed - from "scope it first" comes restating the problem, asking the four questions, listing the entities, writing it down - and by the time all that is on the board, the specific knowledge you thought you'd lost has quietly come back, because it was never really gone. It just wasn't available under a cold-start panic. Give your recall a running start and it returns.

Once you're moving and into the actual design, the studied specifics do resurface, and having a few named building blocks as anchors helps your memory grab on - "this is read-heavy, so I'd split the read and write paths, CQRS style" or "large media shouldn't flow through my servers, I'd hand out presigned URLs." But none of that is needed to start. Start with the procedure; the knowledge catches up.

Move 7: if it's still blank, ask - as scope, not surrender

If restating and questioning still leaves you stuck on where to begin, ask - but frame it as confirming scope, never as "I'm lost":

"There's a lot we could build here. Would you rather I start from the core posting-and-reading flow, or is there a specific part you want me to focus on?"

You look like someone managing the problem, and the interviewer will point you at what they wanted anyway. Getting a nudge costs you nothing; freezing in silence costs you the signal.

What not to do in that first minute

• Don't try to recall the whole architecture at once. That's the move that caused the blank. Minute zero doesn't need it - it needs the procedure.
• Don't rush into drawing boxes to cover the panic. Designing before scoping reads as memorized and gets you designing the wrong system. The freeze is not fixed by going faster.
• Don't go silent. Restate, ask, narrate. The interviewer can't tell "thinking" from "lost" unless you talk.
• Don't treat slowness as failure. Three quiet seconds to gather yourself, spoken out loud, is exactly right. Speed is not the thing being graded.

The blank at the start is the easy one to beat

Of all the moments to freeze, the opening is the most recoverable, because the opening needs no memory - it needs a procedure. Restate the problem, ask the four questions, read the entities off the prompt, and write it all down. Do that and you're moving; and once you're moving, the specifics you were sure you'd forgotten come back on their own. You never had to summon the design from a cold start - you only had to start.

In the last post we scoped the problem; here we got past the panic of the first sixty seconds. Next in this series we take that scoped, written-down problem and turn it into the high-level design - so that even on a bad day, you have a default first draft waiting on the other side of the blank.