If you are a middle or senior-level candidate, you may expect system design questions as part of your technical interview. The objective of system design interviews is to evaluate a candidate's skill at designing real-world software systems involving multiple components.
Understanding and mastering system design questions are crucial in practicing for software engineering interviews. If you’re not properly prepared for these questions and concepts in your interview, you'll miss out on the opportunities of expanding your career with a better-paying position, or even with a great company.
So in this lesson, we will cover how to prepare for a system design interview. You will learn the most common questions and answers.
How to answer theory questions
Most likely, at the beginning of the interview, you will be asked the most basic questions. This way, the recruiter wants to understand if you are familiar with the general principles of system design.
Fundamentals of system design
To help you answer questions about fundamentals, let's examine what problems are crucial for most software systems:
- Scalability: determines if this system can grow with the growth of your product
- Reliability: determines if this system produces correct results every time
- Availability: determines if this system remains operational to perform its required function in a specific period. It is a simple measure of the percentage of time that a system, service, or machine remains operational under normal conditions
- Efficiency: two standard measures of its efficiency are:
- The response time, which denotes the delay to obtain the first item
- The bandwidth, which denotes the number of items delivered in a given time unit
- Maintainability: determines if this system can evolve with your team and is easy to understand, write, and extend
Three key skills
Besides basic knowledge about system design, you need to show skills related to this area. These competencies are very revealing to a recruiter. Possessing these three qualities shows that you don't just know the theory, but know how to apply it in the field:
Skill 1. Gathering requirements. The most important part is staying inquisitive and working to understand the demands. To see it more clearly, you can ask to divide the requirements into two sections:
- What is completely necessary
- What is nice-to-have, but not crucial
Skill 2. Keeping design documents clear and explicit. The goal is to keep documentation in a way that a person not involved in the conversation can understand. All key points should be written down: your approach, trade-offs, solutions, core flow, and ways to design the system. The key points should be understandable to everyone, and only then can the documentation be considered of high quality.
Skill 3. Converting requirements to implementation. Interviewers want to see how you talk about requirements and internal structures of your systems. They also want to know if you are trying to get to know the user. Ask questions like "who is this feature for?" and "how will they be using it?". This way, you gather more information that will help you translate requirements into implementations.
Scaling design
There may also be questions in the interview about how to scale the system. Scaling the system may be necessary for many reasons, such as increased data volume, increased workload, and a growing audience of users. We have to decide how to scale the system.
There are two types of scaling:
- Vertical. You scale by adding more power (CPU, RAM) to your existing machine.
- Horizontal. You scale by adding more machines into your pool of resources.
There are things to consider when scaling:
- Caching. Load balancing helps you scale horizontally across an ever-increasing number of servers, but caching will enable you to make better use of the resources you already have.
- Load balancing. Public servers of a scalable web service are hidden behind a load balancer. This load balancer evenly distributes load (requests from your users) onto your group/cluster of application servers.
- Database replication. Database replication is the frequent electronic copying of data from a database in one computer or server to a database in another so that all users share the same level of information. The result is a distributed database in which users can access data relevant to their tasks without interfering with the work of others. The implementation of database replication to eliminate data ambiguity or inconsistency among users is known as normalization.
- Database partitioning. Partitioning of relational data usually refers to decomposing your tables either row-wise (horizontally) or column-wise (vertically).
- Platform Layer. Separating the platform and web application allows you to scale the pieces independently. If you add a new API, you can add platform servers without adding unnecessary capacity for your web application tier.
How to deal with case studies
System design interview questions are tough to crack if you aren't well-prepared. The questions are broad, have multiple possible answers, and require some foundational knowledge.
Structure of system design cases
When working on each system design case, you should go through the following steps:
Step 1. Requirements clarifications. Spend a few minutes questioning the interviewer and agreeing on the scope of the system. Make sure you know all the requirements the interviewer didn't tell you about in the beginning.
Step 2. Estimation. It is always a good idea to estimate the scale of the system we’re going to design:
- What scale is expected from the system?
- How much storage will we need?
- What network bandwidth usage are we expecting?
Step 3. API / Interface definition. Define what APIs are expected from the system. This will establish the exact contract expected from the system and ensure that we haven’t gotten any requirements wrong.
Step 4. Data model definition. Defining the data model in the early part of the interview will clarify how data will flow between different system components. Later, it will guide data partitioning and management.
Step 5. High-level design (chart). Sketch the important components and the connections between them, but don't go into some details. Usually, a scalable system includes:
- Web server (load balancer)
- Service (service partition)
- Database (primary/secondary database cluster plug cache).
Step 6. Details. For each component, you need to write the specific APIs. You may need to finish the detailed OOD design for a particular function. You may also need to design the database schema for the database.
Step 7. Bottlenecks. Try to discuss as many bottlenecks as possible and different approaches to mitigate them. For example, do we have enough replicas of the data so that we can still serve our users if we lose a few servers? How are we monitoring the performance of our service?
Example of a system design case study
Let's take a look at one common example — let's design a parking lot. This question requires your skills in object-oriented design to check whether you can apply technical thinking to physical objects.
Clarifications:
- This is a one level parking lot, or does it have multiple floors?
- What types of vehicles are we allowed to park there?
- How many entries/exits do we need? What is the price for the parking, etc.
High-level design:
- Use cases: customers parking and paying for their spot; admin managing the system, etc.
- Classes of the system: ParkingLot, ParkingFloor, Account, ParkingTicket, Vehicle, etc.
Details:
- UI interface to the customers: display panels showing available spots, prices, etc
- What are the required enums, data models, and constants for the parking lot system?
Bottlenecks and expectations:
- Will this system meet the requirements you’ve laid out with the interviewer in the beginning of the session?
Conclusion
As you can see from the complex questions above, there is a lot of ground to cover when it comes to system design interview preparation. So it’s best to take a systematic approach to make the most of your practice time.
