How I Prepped For My System Design Interviews (From Zero)
I think it’s fair to say that a lot of the software engineer interview preparation material on the internet relates to LeetCode-style interview problems. This makes sense because a lot of the material on the internet in general is tailored toward beginners. In this case, beginners are more entry-level and (also to a certain degree) mid-level software engineers.
I found that this leaves a gap in the amount and quality of interview preparation material for topics like behavior interviews and system design. As a person without any system design interview experience, this was worrisome.
In this article, I’ll share how I navigated studying the system design interview through free and paid resources, my first experiences with real system design interviews, and some tips I can offer in hindsight (after minimal on-the-job system design experience).
I’m creating this blog post to allow other people to learn from my own personal experience, as I think it could be immensely helpful. After leaving Google, my system design interview preparation over a handful of months helped me land a mid-level software engineering role at my current company.
How Long Did It Take Me To Prepare For System Design Interviews?
It took me about 3 to 4 months of studying an hour a day to pass system design interviews when I started with minimal initial knowledge. This length could be shortened by a couple of months if someone has prior experience working in environments where end-to-end scalable systems (like at startups).
The reason it takes so long to study system design compared to LeetCode-style interview questions is that many more decisions based on tradeoffs are necessary to be made.
Why is System Design Hard to Learn?
Coding interview questions generally have up to 3 or 4 solutions (including brute-force and optimal solutions). System design problems, on the other hand, don’t have a single optimal answer. They have an unlimited number of acceptable solutions based on the initial requirements and constraints.
In order to be able to arrive at optimal solutions during system design interviews, the interview requires that you understand how to build complete distributed end-to-end distributed systems which are scalable, available, and low-latency at both a high and low level.
It’s difficult to gain a working understanding of all of this knowledge before even applying the concepts to an interview environment, especially if you haven’t been exposed to much system design in your day-to-day job.
How I Learned System Design From Scratch
I remember how difficult it was for me to start studying system design. I think I watched a couple of system design interview videos just thinking to myself:
“What does she mean that NoSQL databases are built to scale out horizontally easier?”
“What in the world is consistent hashing?”
“Why is a WebSocket being used here?.. also wtf is a WebSocket?”
These are only a handful of my thoughts at the time. The truth is that I had a lot to learn and my initial approach of just watching videos for a general understanding wasn’t going to work for me. For people with more practical system design experience, it may work.
I learned system design from scratch by studying great system design interview resources and supplementing that knowledge through additional YouTube videos and blog posts. The biggest focus was on learning what’s important vs. what’s not.
The most important things to learn when starting out are the fundamental building blocks of system design. This was the weakest link in my knowledge that prevented me from optimally understanding examples of system designs.
An example of this can be described with a cache. A basic understanding of a cache will tell you that it’s a “system design element” which stores information in memory for faster retrieval in memory instead of disk. However, the bigger questions you’ll need to understand are things such as:
- What are the limitations of a cache?
- Why not only use caches?
- What about the staleness of the data in the cache?
- Does it matter?
- What are the key features of a cache?
- Order of magnitudes faster than reading from a database
- TTL policy?
- Eviction policy?
- What are some applications of a cache?
- caching a [key -> value] data within a database
- for applications like TikTok, pre-generating timeline metadata for every user
All of these key questions should be discussed during a system design interview but wouldn’t be discussed if you were only familiar with caches on a basic level.
This is the reason I found it beneficial to go through the breadth of system design components and understand their features and useful applications. The beneficial system design topics I looked into include:
- Databases
- Caches
- Message Queues
- Servers
- Load Balancers (aka Reverse Proxies)
- Blob Storage
- Content Distribution Networks (CDNs)
After learning about these system components in detail, I was able to focus on studying examples of system designs. My focus at this point was understanding the flow of data through the system instead of the individual system components themselves being the focus. The important things to identify at this point included bottlenecks and dealing with the system design problem’s requirements and constraints. This is the stage where looking through examples of system design is immensely helpful.
For drawing system design diagrams and practicing for the interview, I recommend using Excalidraw or Google Draw. These are the two platforms that I’ve been told (and have used) during real interviews, and I think it’s best to practice with the real tools you’ll be using during interviews if possible.
The last thing I focused on was the interview flow itself. No matter what level of seniority you are, I imagine this being really important. Just because you’re really good at designing systems doesn’t mean you’ll pass system design interviews (an unfortunate truth). The system design interview (much like the coding/LeetCode-style interviews) is all about giving signals to your interviewer that you’re good at system design.
Your interview flow is all about organizing a way to methodologically communicate a complete end-to-end solution (along with major design decisions and tradeoffs) during the duration of the interview. If you cannot do this, then you’re more likely to fail the system design interview.
Luckily, there are resources that are available online that teach you everything you need to know.
What Resource is Best for The System Design Interview
I’ve gone through a lot of resources, both free and paid, when I was preparing for my system design interviews. Ultimately, there was one resource that stood out to me in the end that I deem “the bible of system design interviews”.
The best resource for preparing for the system design book in my opinion is System Design Interview – An Insider’s Guide. The book methodologically explains the topic of system design as it applies to performing well during interviews, along with great examples.
So, why do I recommend System Design Interview – An Insider’s Guide? Well, it covers all of the major aspects of system design as they apply to the system design interview. The only thing the book lacks in my opinion (that’s glaring) is more detail within the system design examples.
The book literally primed me with everything I needed to know on a fundamental level to design basic end-to-end, scalable, low-latency, and highly available distributed systems in addition to how to drive a system design interview.
