System-design rounds are the interview format with the worst signal-to-prep ratio. Two weeks of focused prep gets most candidates to a passable level. Six months of prep gets them to staff-level. Almost no other interview format has such a sharp learning curve in the first 20 hours.

This post is for the candidate who has a system-design round coming in two weeks and no prep time to speak of. The goal isn't to get a perfect score. It's to look like someone who could do the job, which is a lower bar than candidates assume.

The interviewer is not testing whether you've seen this problem before

System-design interviews look like memorization tests. They aren't. The interviewer almost certainly knows you haven't designed Twitter from scratch, and they don't care. What they're checking is whether your thinking about scaling tradeoffs is legible.

This matters because most candidates fail by treating the round as a memorization exercise — trying to recall the exact design from a YouTube video they watched. The interviewer notices when you're regurgitating. Worse, the interviewer asks a follow-up the video didn't cover, and you have nothing.

The candidates who pass have a structure they apply to whatever they're asked. The structure is the prep. The specific patterns are bonus.

The seven moves

The seven steps are the backbone. Every senior-engineering system-design round at every reputable tech company follows roughly this arc, even when the surface details differ.

The two moves candidates most often skip are step 1 (clarify) and step 6 (failure modes). Skipping step 1 makes the rest of the design arbitrary — you can't know if you need sharding without knowing how big the data is. Skipping step 6 signals that you've designed systems but never been on call for one. Both are easy to add and disproportionately valued.

Step 5 — the deep-dive — is the highest-leverage move. The interviewer is generally not impressed by a broad sweep across every component. They're impressed by depth in one component that reveals you actually understand what's happening. Pick the most interesting one and lean in.

Four archetypes to memorize

You do not need to memorize 30 designs. You need to memorize four — one read-heavy, one write-heavy, one search, one storage — and the tradeoffs each archetype is built around. Almost every system-design prompt maps to one of these four with minor variations.

A worked mapping:

• "Design Instagram" → read-heavy archetype, fan-out + cache, plus image-storage subproblem
• "Design Uber" → write-heavy real-time matching, geospatial indexing
• "Design a URL shortener" → write-light read-heavy plus a hashing detail
• "Design a notification system" → write-heavy queueing with fanout
• "Design a typeahead / autocomplete" → search archetype with a trie or n-gram index

If you understand the four archetypes deeply enough to draw them in 10 minutes each, you can compose them to handle 80% of system-design prompts. The remaining 20% are usually niche storage or streaming problems and they're rare in non-specialist interviews.

What senior thinking actually sounds like

The difference between a junior and a senior system-design round is not the diagram. It's the running commentary on tradeoffs.

A junior candidate draws three app servers behind a load balancer and moves on. A senior candidate draws the same three app servers and says: "I'm putting these stateless because we'll need to scale horizontally. We'll keep session state in the cache rather than in the app. The tradeoff is one more network hop per request, but it makes failover trivial."

The diagram is identical. The signal is completely different.

This is the most important thing to internalize before a system-design round: the interviewer is grading the commentary, not the drawing. If you can't draw a fancy diagram but can talk about three tradeoffs and one failure mode for whatever you do draw, you'll pass most rounds.

The 14-day study plan

If you have exactly 14 days, the highest-ROI plan looks like:

• Days 1-3: Read System Design Primer — sections on caching, load balancing, databases, queues. Skim, don't memorize. Two hours per day is enough.
• Days 4-7: Watch one design video per day from Hello Interview, Exponent, or similar. Take notes on the structure they use, not the specific designs.
• Days 8-10: Practice three designs out loud — one read-heavy, one write-heavy, one search. Use a whiteboard or paper. Time yourself to 35 minutes.
• Days 11-13: Do one mock interview if you can. If you can't, do another three solo designs with a focus on the deep-dive step.
• Day 14: Rest. Re-read your notes once. Sleep.

The biggest mistake candidates make is watching 30 videos and doing zero solo designs. The skill is not in the watching — it's in the talking out loud. Five practice designs beat 30 hours of passive learning.

For broader interview prep timing, see phone-screen-what-recruiters-evaluate. For the behavioral-round structure that usually pairs with system design, see tell-me-about-yourself-90-seconds.

What to do mid-interview when you don't know something

This happens to everyone, including senior engineers. The interviewer asks "how would you handle leader election here?" and you blank.

Three responses, in order of preference:

1. Reason from first principles, out loud. "I haven't implemented this directly, but if I were going to, I'd want one source of truth — probably a coordination service like ZooKeeper or etcd. Let me think about what happens when the leader dies..." Almost as good as knowing the answer.
2. Ask what they'd consider standard. "Honestly, I'd reach for whatever the team uses — is there a coordination service in your stack?" Often the interviewer will share, and you're back on solid ground.
3. Acknowledge the gap and move on. "I don't have a strong intuition for leader election. Let me note that as a thing I'd want to read up on, and come back to the design." This is fine in moderation — once is honest, twice is concerning, three times means you're not prepared.

What you should not do: bluff. Senior engineers can hear bluffing within one sentence.

What this isn't

A few clarifications:

• It's not a coding interview. No one wants to see code. If you start writing pseudocode, you've misread the round.
• It's not a Kubernetes review. You do not need to name specific AWS services. "Object storage" is fine — you don't have to say "S3 with cross-region replication and Glacier tiering."
• It's not pass/fail on completeness. A partial design with strong reasoning beats a complete design with shallow reasoning. Interviewers grade depth over breadth.

The short version: the seven moves are the backbone, four archetypes cover most prompts, and the interviewer is grading commentary more than diagrams. Two weeks of focused practice clears the bar. Most candidates over-prep on memorization and under-prep on talking out loud.