How to Prepare for a System Design Interview in Four Weeks

Four weeks is enough time, but only if you spend one week reading and three weeks practicing. Most candidates do the opposite. They read for three weeks, practice in the last few days, and then speak their first answer out loud in the real interview.

The round tests whether you can hold a technical conversation under time pressure. Reading does not build that. Speaking does, and speaking badly for two weeks is how you get good at it.

This plan assumes about one hour on weekdays and two hours on weekend days. That is roughly nine hours a week and thirty-six hours in total. Here is how to spend them.

The four weeks in summary

Week	Focus	How you spend it	What you should be able to do at the end
1	Building blocks	reading and notes	Explain ten concepts and what each one costs
2	Worked examples	reading and drawing	Draw four designs from memory
3	Practice out loud	speaking, with a timer	Finish a design in forty minutes while talking
4	Depth and weak areas	speaking and targeted reading	Answer follow-up questions without stalling

The important pattern is that reading stops after week 2. Weeks 3 and 4 are almost entirely spoken practice.

Week 1: The building blocks

You need about ten concepts. Most system design questions are built from the same small set, so this week has a real finish line.

Cover these: load balancing, caching, database types, sharding, and replication. Then add message queues, rate limiting, and content delivery networks. Finish with strong versus eventual consistency, and how to estimate traffic and storage.

For each one, write three lines in your own notes. What it does. What it costs. When you would not use it. That third line is the one interviewers ask about, and it is the one most candidates cannot answer.

Spend the last hour of the week on estimation. Practice turning a user count into a number of requests per second and a storage figure per year. You will use this in every single practice run after this week.

A structured course removes the guesswork about what belongs on this list. Grokking System Design Fundamentals covers these concepts in the order they are usually needed.

Week 2: Four worked examples

Now read four full designs and redraw each one from memory the next day. Redrawing from memory is the part that matters. Reading a design creates recognition, and recognition disappears the moment someone asks you a question.

Pick one question from each group:

A single-purpose system: a URL shortener
A read-heavy system: a social media feed
A write-heavy system: a notification system
A real-time system: a messaging service

Four is the right number because the decisions start repeating after that. By the fourth design the same choices should look familiar. Where to put a cache. Whether to do work now or in the background. How to split data across machines.

End each design by writing down the one decision you were least sure about. That list becomes your week 4 plan.

Week 3: Practice out loud, with a timer

This is the week that changes your result. Set a timer for forty minutes and talk through a design with nobody in the room. Record yourself if you can.

Follow the same four steps every time:

Ask questions for five minutes. Who uses it, how many, what must it do, and what can it skip.
State the numbers. Requests per second, storage per year, read to write ratio.
Draw a working design in ten minutes. The simplest one that meets the numbers.
Spend the rest on depth. Pick your own weakest part and explain it before the interviewer asks.

Do five sessions this week. Use questions you did not study in week 2, because practicing a design you already memorized teaches you nothing.

Listen back to at least two recordings. Three problems appear almost every time. Long silences while you think. Describing systems in adjectives instead of numbers. Naming a product before naming the requirement. Saying "I will use Kafka" is weaker than saying what you need and then naming Kafka.

If you can find one, do one session with another engineer this week. A real listener asks the follow-up question you were avoiding.

Week 4: Depth and weak areas

Open the list you wrote in week 2 and fix each item. These are your actual gaps, and they are more valuable than any general topic list.

Split the week in two. Use the first half for targeted reading on those gaps only. Use the second half for four more timed sessions, choosing questions that force you into the areas you just studied. Make one of those four a session with another engineer, so you finish the plan having practiced twice with a listener.

Also prepare for the two follow-up questions that come up in nearly every round:

What happens when this part fails? Have an answer ready for each component you draw. A database replica falls behind. A queue consumer stops. A cache is empty after a restart.

How would this change at ten times the traffic? Know which part breaks first in your design. Being able to name it is most of the answer.

In the last two days, stop learning anything new. Redraw your four designs from week 2 one more time and confirm you can still explain each decision. Going into the round with four designs you know well beats going in with twelve you half remember.

What to skip

Some preparation feels productive and is not worth the hours.

Do not memorize solutions. Interviewers change one constraint and a memorized answer stops working. Learn the decisions, not the diagrams.

Do not learn a specific technology in depth. Knowing what a system needs matters more than knowing one product's configuration. Depth on a product only helps if the role specifically requires it.

Do not read more case studies after week 2. Ten designs read passively lose to four designs you can draw and defend.

Do not spend days on estimation formulas. You need one habit, which is converting a user count into requests per second and storage. That takes an hour, not a week.

If you have less than four weeks

With two weeks, keep the structure and cut the volume. Spend three days on the building blocks, three days on two worked examples, and the remaining eight days on timed spoken practice. The reading-to-practice ratio is what matters, not the total hours.

With one week, do two worked examples and five spoken sessions. Accept that you will have gaps, and prepare the sentence you will use when you reach one. Saying "I have not designed this before, here is how I would approach it" costs you far less than guessing confidently and being wrong.

If you have more than four weeks, Grokking the System Design Interview works through the common questions in full. The study plans in the handbook spread them across a schedule.

Frequently asked questions

Is four weeks really enough to prepare for a system design interview? Yes, for most mid-level and senior roles, if three of the four weeks are spoken practice. It is not enough to learn distributed systems from nothing. It is enough to learn the interview, which is a narrower skill than the field it is drawn from.

How many hours per day do I need? About one hour on weekdays and two on weekend days. Consistency matters more than volume, because spoken practice improves through repetition rather than long sessions. Two focused hours across a week beat one six-hour weekend.

Should I practice with a person or alone? Alone for most sessions, with a person for at least two. Solo practice with a timer builds the habit of talking continuously. A real listener supplies the follow-up questions, which is the part you cannot generate yourself.

What if I have never built a large distributed system? Almost no candidate has, and interviewers know this. They are checking whether you can reason about one, not whether you have operated one. Speak in numbers and name failure cases, and the gap in experience stops being visible.

Which questions should I practice if I am short on time? A URL shortener, a social media feed, and a messaging service. Those three cover single-purpose systems, read-heavy systems, and real-time systems. Most other questions reuse decisions from at least one of them.

System Design Interview Questions, Organized by Difficulty, for choosing what to practice
System Design Interview Questions by Company, for predicting which question you will get
The System Design Interview, on how the round is structured
Thinking Like a System Designer, on the habits this plan builds
System Design Interviews: What Actually Matters, on what interviewers score