You don't need to have run Kafka in production to pass a system design round. You need to know why someone would reach for it, and what breaks if they don't.
That's the part most prep advice skips. It hands you a list of components and a few famous designs to memorise. Then the interviewer asks "why not just use Postgres?" and the memorised diagram has no answer.
Here's an approach that works when you have 0 to 3 years of experience and no big systems on your resume yet.
1. Learn the building blocks as trade-offs, not definitions
About ten pieces show up in almost every round: load balancers, caches, queues, SQL vs NoSQL databases, replication, sharding, CDNs, rate limiters, object storage and search indexes.
For each one, write down three things:
- what problem it solves
- what it costs (latency, money, complexity, consistency)
- what fails first when traffic goes 10x
"A cache makes reads fast" is a definition. "A cache makes reads fast until the data changes, and then you have to decide who is allowed to see stale data" is a trade-off. Interviews are graded on the second kind.
2. Borrow other people's experience
You don't have production war stories yet. Engineering blogs are full of them. Discord, Uber, Netflix, Stripe and Cloudflare all write up real design decisions, usually because the first version broke.
Read one a week and ask yourself: what would I have done, and where would it have broken? That question is the whole interview, practised slowly.
3. Do 8 to 10 classic problems end to end
Not 50. Ten, done properly: URL shortener, rate limiter, chat app, news feed, notification system, file storage, ride matching, typeahead search, payment system and video streaming.
"Properly" means you could talk through each one for 45 minutes:
- Clarify: who the users are, what scale, reads vs writes, what can be eventually consistent
- Estimate: requests per second and storage per year. Rough numbers are fine.
- High level: the boxes and the arrows
- Deep dive: one component in detail, usually the one the interviewer pokes at
- Failure: a node dies, a region goes down, traffic spikes
I keep a free list of 132 system design interview questions, each with the opening prompt, what the round is really testing and the clarifying questions worth asking. No signup needed to read it. Start with the easy ones. They're easy on purpose.
4. Spend the first five minutes asking questions
The most common way to lose a system design round early is drawing boxes in minute one.
Take "design a URL shortener". Before anything else:
- How many new links a day, and how many redirects?
- Do links expire?
- Can users pick custom aliases?
- Do we need click analytics?
Each answer changes the design. Asking shows the interviewer you know that, and it buys you thinking time.
5. Practise out loud, with someone who interrupts
Reading a design and explaining it while someone asks "why?" every two minutes are different skills, and only the second one gets graded. Short version: set a 45-minute timer, give a friend a list of follow-ups, and swap roles next time.
I wrote a longer post on this, including what to do when you have nobody to practise with: How to practice system design interviews when you have nobody to practice with. If you need a partner, Practick (which I built) pairs you with one for free.
What interviewers are actually checking
At 1 to 3 years of experience, nobody expects you to have designed Twitter. They're checking whether you:
- ask what you're building before you build it
- make a choice and explain the trade-off, instead of listing every technology you know
- can go deep on one part when pushed
- think about failure without being prompted
A simple design you can defend beats a clever one you can't.
What's the follow-up question that caught you off guard in a system design round? Drop it in the comments.
