When studying data structures/algorithms (DSA) interview questions, there’s a clear playbook: master the concepts and practice consistently to apply that knowledge. That practice comes easy because there are thousands of DSA questions on sites like LeetCode, HackerRank, and AlgoExpert that reflect the types of questions you’ll get during your interview.
Systems design questions are a different story. Most practice systems design questions do not reflect those you’ll get during an interview. There is, of course, a lot of high-quality information regarding how to solve systems design interview questions in general. But it’s hard to get that information to stick without a solid set of practice questions.
Lack of quality practice problems
The lack of quality practice questions makes sense. Systems design questions can be highly complex. To build a system, you not only need input from multiple components but almost always require some external state. You not only need to accept input and return values but will likely have to deal with complex user interactions such as indicating data is processing or handling multiple sets of dependent steps. Compare this to your standard DSA question, which usually provides some list of numbers or strings as input and has a solution that can fit within a single function. What’s more, a system's “edge cases” are numerous; you have to be prepared to explain what would happen if any combination of components in your system fails. Spending time creating a quality practice question means having to capture all of this complexity, an arduous and time-consuming endeavor.
The real interview
Because they take so much effort to create, most practice questions are well-studied problems with precise inputs, outputs, and best practices. Questions like “implement a key-value store” or “implement a URL shortening service.” Systems design questions in real-world interviews are much more ambiguous. They will likely be something that you haven’t directly come across. There may be many “right ways” to design it. There may be solutions that would be incorrect given an initial set of constraints but ideal with different ones. While existing practice systems design questions provide valuable reference material when studying the general structure of solving systems design questions, it’s hard to work backward from a known solution and visualize all of its alternatives. It’s also tempting to fall into the trap of memorizing specific well-known systems vs. the more creative process of designing something you’ve never seen before.
I encountered this issue of sourcing high-quality practice systems design questions while interviewing last fall. I had simultaneous interviews with Meta (back then Facebook), Google, and Amazon, and I was extremely nervous because I couldn’t build up confidence in my systems design interviewing skills. I was scouring the internet for quality systems design interview questions and kept feeling like I was coming up short or just memorizing solutions to specific systems.
Creating my own problems
Then one day, I started to take note of certain products’ features that I found interesting. For example, when signing into Netflix from a TV, I noticed that you could navigate to a login page on your computer, enter the code found on your TV, and complete the flow from there. I observed upon adding something to my cart on an e-commerce site and then getting distracted during checkout how I’d get an email 30 minutes later telling me not to forget about the items I had.
I started to ask myself: if I were an engineer for this product and had to build this feature from the ground up, how would I do it?
For example: if I were an engineer at Netflix, and a product manager came to me and said, “we want to make it easy for people to sign in on their TV by showing them a code and letting them do it on their computer,” how would I build that?
If I were an engineer at Amazon, and a product manager came to me and said, “we need to send email reminders to people when they exit out of a checkout flow and don’t come back,” how would I build that?
Then I would sit down with a pen and paper and architect the feature from the ground up. Most of the time, this resulted in a drawing or diagram of how the system powering this feature would behave. Often, I would wade into a blind spot in my knowledge and have to look something up. I’d even go to the engineering blogs of the company to see if they had written anything on the feature I was designing if I got stuck and gave up.
After doing this for a few weeks, I realized I felt twice as confident in systems design interviews as I had before, and I found them to be much easier. I performed well in all three of my big tech company interviews, leading to offers from all of them.
Why it works
I think this method of trying to design systems for real-world features is an effective way to source practice system design questions. Because there’s a real-world system behind the feature, you can be sure it is relatively complex. Of course, this won't be the case if you choose to design a tiny feature. But often, user-facing features – especially for popular products – are jam-packed with a ton of complexity, giving you a sufficient problem space. Just make sure that before you try and design the feature, it doesn’t feel “super easy” to you.
Also, because the feature exists in the real world and not for a job interview, you can be confident it is sufficiently ambiguous. Most real-world problems are ambiguous, and most features solve real-world problems. The systems that power these features might be even more ambiguous than the systems you’ll have to design during your interview. This is a good thing. You want to train harder than the actual interview will be. That way, when it comes time to do the interview, it’s easy. In the immortal words of Rip Torn: “if you can dodge a wrench, you can dodge a ball.”
Where to find resources
There are a ton of great resources for finding real-world features. Reading the engineering blogs of the companies you’re interviewing for will help you see what types of systems these companies design and give you a sense of how they talk about designing systems. Going to meetups/tech talks where people talk about what they build at work is a great chance to speak with that person and learn more about the concept from the source. Many product launches on HackerNews and ProductHunt have links to open-source software, so you’ll be able to dive into the code and see the design first-hand. Make sure the product is sufficiently complex enough to warrant a real-world feature.
Conclusion
When finding systems design interview questions, the best place to look is the real world, at the products and features you use. Find features in real life and design those systems yourself so that you're more than ready when it’s time to do that at an interview.
Join the community
Looking for a study partner? Hackpack is the most active community of engineers studying for programming interviews. We hold each other accountable, provide support, and fight burnout to study more efficiently and get the job faster.
Apply Here
Events | Youtube | Twitter | LinkedIn | Newsletter
Top comments (0)