The first time I seriously prepped for a system design interview, I treated it like a multiple choice exam with a right answer. I memorized how Twitter scaled, how Netflix does CDNs, how DynamoDB handles quorum. I could draw Uber's dispatch flow from memory. Then I walked into an actual interview and got asked to design a simple URL shortener. I froze.

I started diagramming a distributed key value store with consistent hashing and replication before the interviewer even finished the question. He stopped me and said, walk me through what happens when a user clicks a link. Just to one server. I didn't have an answer. I'd skipped the parts that actually matter because I was so eager to show off scale.

That failure taught me the first rule: clarify requirements before you draw anything. Ask how many users, what the read write ratio is, what consistency is acceptable. The interviewer isn't testing whether you know every design pattern. They're testing whether you can find out what the problem actually is before solving it.

After that, I changed my approach entirely. Now I start with the smallest possible system that works. For a URL shortener, that's a single web server, a database with a table that maps short codes to long URLs, and a redirect endpoint. No caches, no queues, no replicas. Then I talk about what breaks as traffic grows and add pieces one at a time with a reason for each.

I saw this work from the other side too when I started interviewing candidates. The best one I ever interviewed began a rate limiter problem by saying, I'd probably just store a counter per user in memory for now. He was calm, he admitted he didn't know the exact math for token buckets off the top of his head, and he walked us through a sliding window approach by drawing a few boxes. He got an offer because he could reason from simple to complex without panicking.

The other mistake I made early on was ignoring tradeoffs. I once proposed a NoSQL database for a system that clearly needed transactions, and the interviewer asked how I'd handle a double spend. I mumbled something about eventual consistency and we both knew it was over. You don't need to memorize every database's consistency model, but you do need to be honest about what you don't know and talk through the consequences.

For practice, I stopped reading blog posts and started talking out loud while drawing on a whiteboard. I'd give myself twenty minutes for a problem like design a notification service, then I'd watch the recording and cringe at how many times I said 'then we scale this' without explaining how. You can't hide from that. I also read Designing Data Intensive Applications cover to cover, not because it gives you interview answers, but because it teaches you to ask better questions about storage and replication.

The candidates who stand out aren't the ones who know every distributed systems trick. They're the ones who can start with a single Postgres table and a humble redirect endpoint, then reason up from there. If I could redo that first interview, I'd spend ninety percent of the time on the simple version. That's probably all you need.