How to prepare for a system design interview in four weeks

Ten hours a week. Three problems, done three times each. The rest got deliberately skipped, and the skipping is the actual plan.

Caption: The constraint is the product. A four-week prep plan is a time budget first and a syllabus second, which is why most reading lists fail.

Four weeks does not buy you distributed systems

Four weeks is not enough time to learn distributed systems. It is exactly enough time to learn how to talk about them coherently for forty-five minutes without unravelling.

Confuse those two goals and you will spend week three on a consensus paper that will never come up, then walk into the room and forget to ask how many users the thing has.

I have sat on both sides of this table. The candidates who fail are almost never the ones who knew less. They are the ones who tried to know everything and arrived with a head full of unstructured trivia and no way to open a problem.

The standard advice is a link dump, and link dumps have no Tuesday

Search this topic and you will drown. Twelve videos, four books, a repository with eight hundred stars. Or you will find someone telling you, gently, to learn the fundamentals.

Neither tells you what to do on Tuesday evening at half past eight, tired, with ninety minutes before you stop being useful. That is the only question that matters, because that is where the hours actually get spent.

I fell for the link dump version myself, years ago. I collected the resources, felt organised, and by week two I had watched a lot and produced nothing. Watching is not practice. You cannot get better at speaking by listening.

The maths nobody does before they start

Do the arithmetic before you do anything else. Ten hours a week, four weeks, is forty hours. That is one working week to prepare for something people treat as a career gate.

One problem, worked properly, written down, with a data model and a stated bottleneck, takes three to four hours the first time. Three problems, three passes each, at three and a half hours average, is thirty-one and a half hours. That leaves eight and a half hours for week-one fundamentals and week-four mocks. The budget closes fast, and it does not stretch because you feel motivated on a Sunday.

I cut consensus algorithm internals. The CAP theorem as philosophy. Every database I would not name in an interview anyway. Container orchestration. Any book read cover to cover. I cut them on purpose and felt nothing.

If a topic cannot change what you say out loud in a forty-five minute conversation, it is not preparation. It is procrastination with a technical accent.

Week one: building blocks only, one hour a night

Week one is four topics and nothing else. Load balancing, caching, databases, queues. That is the entire surface area.

Each weekday, one hour, one topic in rotation. The drill is fixed: pick one narrow question, answer it in writing in your own words, then find the trade-off that makes it interesting. "Why would I put a cache in front of this" is a bad question. "What happens to my database when the cache node dies at peak" is a good one, because it has a failure mode in it.

At the weekend, one written summary. One page, four sections, no diagrams. If you cannot explain when you would pick a queue over a synchronous call in three sentences, you do not have it yet.

Caption: The only diagram you need in week one. Almost every interview problem is this picture with one component stressed until it becomes the topic.]

Week two: three problems, slowly, no shortcuts

Three problems. A rate limiter, a news feed, and an event ingestion pipeline. Between them they cover state, fan-out, and throughput, which is most of what gets asked.

Slowly means three to four hours each, spread across the week, written down. Requirements first, then scale numbers, then the API, then the data model, then the boxes. Most people draw the boxes first, which is why their designs collapse the moment someone asks what a row looks like.

Here is my own bad call, and it cost me an offer. In a real interview I was asked for a rate limiter and I reached for a fixed window counter because it was the first thing in my head and it was simple to describe. Simple, and wrong at the boundary.

Here is the broken version. The counter resets at the top of each minute, so it is blind to anything that happens across the boundary.

fixed window: resets on the clock, not on the user

key = f"rl:{user_id}:{int(time.time() // 60)}"

count = redis.incr(key)

if count > 100:

reject()

a user sends 100 at 10:00:59 and 100 at 10:01:00

that is 200 requests in two seconds, and the counter is happy

The interviewer did not tell me it was wrong. He asked what happens right at the minute boundary, and I said "nothing special", and I watched him write something down. That is the moment it ended.

The fix weighs the previous minute's count by how much of it has passed, so a burst sitting on the boundary no longer gets a free pass.

sliding window counter: borrow from the previous window, weighted

prev, curr = redis.mget(prev_key, curr_key)

elapsed = (time.time() % 60) / 60

est = int(prev or 0) * (1 - elapsed) + int(curr or 0)

if est > 100:              # the boundary burst is now visible

reject()

Without that single line of weighting, a user slips two hundred requests through in two seconds and the system calls it legal. With it, the boundary is visible and the burst gets rejected.

One line, and the failure mode disappears. I did not learn that from a video. I learnt it because someone made me feel stupid about it in a room.

Week three: same three problems, timer running

Week three is not new material. It is the same three problems, again, with a clock on.

Forty minutes each, out loud, standing up if that helps, following the same opening sequence every single time. Six moves, in this order. Then you can think about the problem.

Clarify what is in scope. Ask for scale, and if nobody gives you numbers, invent reasonable ones and say them out loud. Sketch the API surface. Define one table. Draw the path. Name the bottleneck yourself, before anyone asks you for it.

That sequence is the whole point of the month. Content varies by problem. Structure should not vary at all, because structure is what stops you freezing when the question is one you have not seen.

The second pass will feel boring and slightly humiliating. That means it is working. Boring means it has become procedure, and procedure is what survives adrenaline.

Caption: The six-step opening sequence, drilled until it survives adrenaline. Content varies by problem, structure does not vary at all.

Week four: mocks only, and patch what they expose

No reading in week four. Mocks, ideally with another person, ideally someone senior enough to interrupt you rudely.

Mocks expose two things. What you do not know, which is cheap to fix, maybe an hour of reading. And what you do when someone is watching, which is the real one.

I once watched a candidate draw for four minutes in silence while three people waited to ask him about users. He was building the wrong thing and nobody could stop him, because he never looked up.

That second kind only shows up when a human is in the room. This is the entire reason week four is not more practice on your own.

You are not being tested on whether you know what a message queue is. You are being tested on whether you are pleasant to solve a hard problem with.

The final 48 hours, in one page

Do not learn anything new. Nothing you absorb in the last two days will survive the interview, and the attempt will cost you sleep you cannot spare.

Reread your four one-page summaries from week one, once, slowly. Redraw the standard picture from memory on paper: client, load balancer, app tier, cache, primary and replica, queue and worker. If any part of it comes out shakily, redraw it until it does not, because that picture is your fallback when the question is unfamiliar.

Rehearse your opening sixty seconds out loud, the clarifying questions you always ask, so that the first thing out of your mouth is procedure rather than panic. Write your three go-to numbers on a card and know them cold, whatever you have chosen as your reference points for requests per second, storage per record, and cache hit ratio. Then check the logistics, the link, the time zone, the working microphone. Then stop, and go to bed early, and accept that you have spent forty hours and forty hours is what you had.

Where this plan breaks

This is for someone with real backend experience who has never had to narrate it. Match your ambition to what you have actually built and operated. If you have never been responsible for a live service, if you have never been the person who gets woken up when it breaks, four weeks will not fill that gap, and no plan will.

It also assumes a genuine ten hours. Six hours a week is a different plan, not this one compressed, and you should cut to two problems rather than rushing three. Do this only if you have a real date, a real ten hours, and a person available for week four. Otherwise take eight weeks and be honest that you are taking eight weeks.

What it actually cost

Forty hours of evenings, and the honest social cost that comes with them. Three problems learnt properly instead of fifteen skimmed. A stack of topics I still cannot speak about with any authority, which I chose.

And the offer I lost to a fixed window counter, which I count as tuition.

If this plan makes sense to you, you will find the same philosophy at PracHub: structured practice and mocks, not another resource list.

What are you still planning to learn that would change nothing you would say?