I used to think system design interviews were about memorizing architectures. So I spent three weeks reading blog posts about Kafka, Cassandra, and load balancers, filling a notebook with diagrams I could barely reproduce from memory. My first real interview at a large e-commerce company started with "design a URL shortener," and I immediately started drawing boxes. Three minutes in, the interviewer stopped me and asked how many users we were designing for. I didn't know. I hadn't asked. That was the moment I realized I had been preparing for the wrong test.
The actual skill being evaluated isn't recall. It's structured problem solving under ambiguity. Interviewers want to see how you clarify requirements before committing to a design. After that failure, I changed my approach entirely. I stopped reading articles and started doing mock interviews with a friend who worked at a payments startup. We would pick a random system like a ride sharing service or a news feed and I would force myself to spend the first ten minutes just asking questions. How many daily active users? What's the read to write ratio? Do we need strong consistency or can we tolerate some lag? Those questions sound basic, but asking them out loud changed how interviewers reacted. They stopped looking bored and started nodding along.
The second thing that helped was learning to estimate capacity without a calculator. You don't need exact numbers, just order of magnitude reasoning. If a service has a hundred million users and each one writes once a day, that's roughly a thousand writes per second on average, maybe ten times that at peak. Once I could do that kind of math in my head, the diagrams became meaningful. I could decide whether we needed a cache or a queue not because the book said so, but because the numbers justified it.
One mistake I kept making even after I got better at asking questions was jumping to a perfect solution too early. I would try to include sharding, replication, and a message queue in the first pass, and the design would collapse under its own weight. A senior engineer I worked with told me to start with the simplest thing that could work, then iterate. Design a single server and a database. Then ask where it breaks. That advice felt almost too obvious, but it worked. In my next interview, I walked through a basic version first and then added complexity only when the interviewer pushed me to scale. The conversation felt like a collaboration instead of a presentation.
You can't fake experience, but you can simulate it. I set up a small homelab with two old laptops and a Raspberry Pi. I built a tiny URL shortener, a chat service, and a file storage system. None of them handled real traffic, but the act of wiring together an API, a database, and a cache taught me more than any article. When interviewers asked about tradeoffs between SQL and NoSQL, I could talk about a time I hit a write bottleneck on a Postgres table, not just recite a list of pros and cons.
The most underrated part of system design prep is learning to communicate your thought process while you think. Record yourself doing a mock interview. You'll hear long awkward pauses and sentences that trail off. Fixing those, not memorizing more architectures, was what finally got me an offer. The interviewer isn't looking for a perfect system. They're looking for someone they'd want to design with.