System Design Interviews
At the system design interviews, you are given a very vague design problem like "Design Twitter", and you need to share your approach in about 45 minutes. The purpose of these interviews is to test your experience working with the real software systems and how much you know about these systems in general.
You usually don't code much during these rounds, but simply show your design and considerations on the whiteboard, and discuss your approach with the interviewer.
System design rounds are more common for senior and more experienced candidates, and interns and new grads usually don't have them. But it is still important to keep them in mind.
To prepare for the system design interviews, you should understand the interview format and what is expected of you, study practice system design problems and solutions, and learn more about real software systems and principles.
For a good introduction to the system design interview format you can watch this video by Jackson Gabbard:
As with the coding interviews, solving practice system design problems is a great way to prepare. You can try to solve the problems yourself first, and then read the solutions to see what you missed and to learn about the concepts that may be new for you.
For a good collection of system design problems with solutions, you can check out the following resources:
System design course on educative.io has a nice collection of problems with solutions and an introduction to the common concepts you need to know. It is not free, but you can check out the free content first to see if it is worth it for you.
SystemsExpert has ten system design questions with solutions (including video), and videos on system design concepts. Again, it is not free, but you can check out the free content first.
The following free resources also have system design problems and solutions, but they are a bit of a hit-or-miss in terms of the quality of the content:
There are tons of system design videos on YouTube, where people explain typical interview problems and solutions. For example, you can check out this playlist for a collection of such videos.
Another way to prepare for system design interviews long term is to learn more about the real-world software systems and the key concepts and principles. This will prepare you for the system design interviews and make you a better software engineer in general.
One of the best ways to do this is to read a good book on software engineering. For book recommendations, check out the Books section of this website. For example, I highly recommend Designing Data-Intensive Applications as a great book about big distributed systems, and one of the best technical books I have ever read.
Besides books, expose yourself to as much information about the designs of the real systems as possible. Read blog posts, articles, and papers, watch educational videos and talks. Be curious about how the real systems work, and try to find the answers to your questions.
Below are a lot of links to different materials about system design. Some good videos:
How We've Scaled Dropbox – fascinating story of Dropbox going from one server to massive infrastructure supporting millions of users.
Building Software Systems At Google and Lessons Learned by Jeff Dean.
Everything else. It is roughly sorted down from the most recommended ones, but you can simply read the titles and see what you like:
There are some common system design concepts that you need to know. They come in handy when solving system design problems, and they often appear in the solutions.
Below are sixteen very common concepts. Read about them on Wikipedia or elsewhere, and be sure to know what they are and how they are used:
To have a structured way to approach system design problems, you can follow these steps. Try to follow them when solving practice system design problems.
Ask clarifying questions. Specify all requirements to understand what exactly your design should do.
Often, system design problems are very vague, like "Design Twitter". It is your responsibility to scope what exactly Twitter functionality is, how many users we will need to support, and so on.
Scope business requirements.
It is a good idea to think about what your design should achieve from the business perspective. What would we or potential stakeholders mostly care about? Should we be able to handle millions of users? Should your service have 99.99% uptime? Should each request be processed in 300ms? Should the data be safely replicated and never lost?
System design is about engineering, but behind most systems, there are real-world and business requirements. Show that you understand this and care about it.
Do estimations. Estimate the number of users you will need to support, disk space and network bandwidth you will need, and so on.
Before designing a performant system, it is good to have an idea of how performant it really should be. Designing Twitter for 10 and 1000000 people are two very different tasks. Use the requirements from the previous two steps for your estimations.
Start with as simple design as possible.
Before designing a big system, scale down, and come up with as simple solution as possible. Imagine you will have just 10 users, how would you build the system? Often, just one server handling all requests and storing all data is enough.
Now scale up and iterate.
Now that you have a simple solution, imagine you have more users and data, and start scaling up. Continuously identify the current bottlenecks – one server is not enough to process all requests, we need a load balancer to split the work, the database is too big for one machine or should be replicated for safety, and so on – and show how you would solve them. In the process, discuss the deeper technical details: what database schema and APIs you would create, what technologies you could use, and so on. Show how your solution aligns with the business and product requirements you specified before.
Think about the extra details of your system.
How would you test it? What about security? What are alternative designs?
To effectively prepare for the system design interviews, you will need to solve more than five problems, but solving just five is a nice way to get started.
You can use the steps discussed above, or come up with your own. Writing down just a short name of each step is enough. For example, your list can look as follows:
- Ask questions and specify design functionality.
- Scope business requirements.
- Do design estimations.
- Start with a simple design.
- Scale up and iterate.
- Think about details like testing and security.