The first time I prepped for a system design interview, I watched something like 40 YouTube videos in three weeks. Rate limiters, URL shorteners, news feeds, chat apps. I took screenshots of every architecture diagram. Then I sat down in the actual interview, got asked to design a notification service, and drew a load balancer with nothing behind it for about two minutes while my brain looked for anything at all.
I had seen the answer. I just couldn't find it.
The second time around I prepped very differently, and it went a lot better. This post is what changed. Most of it is about remembering what you've already covered, which turned out to be my actual problem.
The trap: system design is easy to recognise and hard to recall
When you watch someone walk through "design Twitter," every step feels obvious. Fan-out on write for most users, fan-out on read for celebrities, a cache in front of the timeline. You nod. It makes sense.
Recognising an answer and producing one are different skills, though. In the interview there's no video. There's a blank whiteboard and a person waiting. If your prep was all watching, you've trained the first skill and tested yourself on the second.
So the real goal of prep is being able to rebuild a few core ideas from nothing, on demand, weeks after you learned them.
Shrink the syllabus to building blocks
Most system design questions are remixes of the same parts. I made a list of about 15 building blocks and stopped worrying about memorising whole designs:
- load balancing and horizontal scaling
- caching (where it sits, what gets evicted, what goes stale)
- database choice: relational vs. key-value vs. wide-column
- replication and leader election
- sharding and consistent hashing
- message queues and async processing
- rate limiting
- CDNs and blob storage
- the CAP tradeoff, and what "eventually consistent" means for a real feature
- idempotency and retries
- back-of-the-envelope estimates
That's the actual syllabus. A notification service is a queue, some workers, a preferences store and a rate limiter. Once I could explain each block cold, the designs mostly assembled themselves.
For depth, the book I kept returning to was Martin Kleppmann's Designing Data-Intensive Applications. It's long and it isn't an interview book, but its chapters on replication and partitioning made the "why" click in a way short videos never did. Alex Xu's System Design Interview books are the opposite: shorter, and organised around the exact questions you'll get. I used both.
After every video, close the tab and draw it
This was the single biggest change. After watching a walkthrough, I'd close it and redraw the design on paper from memory. Boxes, arrows, the data that flows between them, and one sentence on each tradeoff.
The first attempt was always worse than I expected. I'd forget where the cache sat, or that the write path went through a queue. Then I'd reopen the video, check only the parts I got wrong, and try again the next day.
It's slower than watching three more videos. It's also the only thing that made the material stick for me.
Keep one page per building block
I kept a single note for each building block. Not a transcript of the video. Just:
- what problem it solves, in one line
- the main tradeoff
- one real system that uses it, with a source
For consistent hashing, my page said roughly: "spread keys across nodes so adding or removing a node only moves a fraction of keys. Tradeoff: uneven load unless you use virtual nodes. Used by Amazon's Dynamo, per the 2007 Dynamo paper." Enough to talk for five minutes, short enough to review in thirty seconds.
Review on a schedule, not when you panic
Here's the part I skipped the first time. I'd learn caching in week one, never look at it again, and by week three it was gone. Then I'd panic the night before and rewatch everything, which is the least efficient way to study anything.
Spaced repetition fixes this. You review an idea a day after learning it, then a few days later, then after a week, two weeks, a month. Each review is short because you nearly remember it. If you want to see how the scheduling math works, I wrote up an SM-2 spaced repetition implementation in JavaScript a while back.
For system design, a "review" is just: look at the building-block page title, try to explain it out loud, then check the page. If you got it, move on. If not, it comes back sooner.
Where Recl came in
My prep material wasn't only books. It was YouTube walkthroughs, engineering blog posts from companies like Discord and Uber, a few podcast episodes, and short clips people posted on X and Instagram. Tracking review dates for all of that by hand fell apart within a couple of weeks.
That's a big part of why I built Recl. You save a video, article, reel or podcast from the share sheet or the Chrome extension, and it writes a summary of the key ideas, with timestamps for video, and files it under a topic. Then it brings those ideas back 1, 3, 7, 14, 30 and 60 days after you saved them, so the review schedule runs itself.
Two features turned out to be handy for interview prep in particular. The timestamps meant I could jump straight to the eight minutes of a 50-minute talk that covered sharding, instead of scrubbing around. And Ask lets you ask a question against your own saves, so "what did I save about rate limiting?" pulls up the relevant videos and posts with sources.
It doesn't replace drawing the designs yourself. You still have to close the tab and sketch. Recl just handles remembering to come back.
A practice loop that worked
In the last two weeks before interviews, my routine was:
- Pick a question ("design a ride-sharing dispatch system").
- Set a 35-minute timer and talk through it out loud, drawing as I went.
- Compare with a good reference walkthrough afterwards.
- Note which building block I fumbled and add it to the next day's review.
Doing this with a friend is better, because they'll ask "what happens when that node dies?" at the exact moment you hoped nobody would.
What I'd tell myself the first time
Watch fewer designs. Learn the blocks. Redraw everything from memory. And come back to it on a schedule, because the material you studied three weeks ago is the stuff that will be missing when you face the whiteboard.
I'm Spartan Rich, and I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, sorts them into topics, and uses spaced repetition so you remember what you learned.
Top comments (0)