Introduction
System design interviews are an essential part of any software engineering interview loop. They are increasingly more important as you advance your career.
How do you know you are ready? You probably have heard the working backward method. Interview preparation is no different. Let’s get into the head of an interviewer and examine the goals of a system design interview. I hope this could help you get into the right mindset before you start preparing for an interview.
I am not an authority on system design interviews. I’ve conducted well over 100 interviews in the past few years, but the perspectives and opinions are still just mine.
My goal as an interviewer is to assess your level and potential as a future team member, and I achieve that goal by examing your skills, thought process, collaboration, and experience.
Real-world System Design
System design is an umbrella term for many things. Design object-oriented classes, APIs, subsystems that access external resources are all system design; however, in the past few years, system design has almost become synonymous with distributed system design. So this article will focus on distributed system design.
One can write a book on this topic. In my opinion, system design is both art and science. There are rights and wrongs, but at the same time, it’s not easily measurable like science. These are the aspects that make system design unique and difficult:
Tradeoffs
- It’s always about tradeoffs. Any component you add to address an issue also comes with drawbacks that you have to deal with
- Often you don’t have comprehensive data to make the tradeoffs.
Ambiguous
- You don’t have perfect functional and non-functional requirements. You rely on experience to put some stake in the ground as a starting point.
Abstract
- The concepts such as load balancing, CDN, CAP theorem, etc. can be abstract and difficult to understand.
Evolutionary
- You don’t build Google infrastructure in one day. Your functional and non-functional requirements change over time. So most of the time, the design will be for the evolution of existing systems. So when is it enough for the current problem?
Practical
- It needs to work for your current problem. You will have to consider team skills, integration with existing systems, and even team culture.
Collaborative
- Many people and teams are involved in the design process. Communication and collaboration are vital.
A quote from Albert Einstein best demonstrates what good design looks like: “Everything should be made as simple as possible, but no simpler.”
System Design Interview
System design interview inherits many of the challenges of real-world system design, and on top of that added time constraints, so what gives? The most significant difference is that a real-world system design needs to produce a workable solution. In contrast, a system design interview is about the process of getting to a solution. From an interview’s perspective, the goal is not to ask you to come up with the right solution in an hour or less. The goal is to assess you as a future team member and to determine your level.
These are the questions in my mind:
- Can you work with me?
- Do you ask the right questions?
- What’s your thought process?
- What’s your experience?
- Are you willing and capable of learning?
- What’s your technical breadth and depth?
Let’s look at two examples to illustrate my point.
Suppose I ask you to design a web crawler. You felt lucky because you just studied the question last night, and you had the perfect architecture memorized and understood. It took you almost no time to draw that impeccable diagram on the whiteboard. Well, bad news for you. 99% of the chance you got it wrong. Why?
In most cases, I am not looking for the perfect answer because, arguably, it doesn’t exist. I care about your thought process. I also care about if you took the time to understand the question, the scenario, and the requirement. We can use a web crawler to index pages for a search engine like google. We can use it to retrieve my competitors’ prices from an e-commerce site. We can also use it to extract yelp reviews for sentiment analysis. Your design is likely to be different in each of those cases. You may say. Well, let me design something very generic and highly scalable to cover all the circumstances. On paper, you can probably draw an architecture diagram that can handle all cases, but how about the tradeoffs? The more components you add, the more complex the system will be; therefore, more cost and more effort to maintain.
Another example: design a device to transport goods from point A to point B. What can it be? A horse, a car, a ship, or even the millennium falcon if I am in a real hurry. So can the millennium falcon perform the task of a horse? Yes, of course, but at what cost?
Conclusion
System design interview originates from real-world system design, but its purpose is to assess you as a future team member; therefore, you need to focus on the process instead of the solution. You need to collaborate with the interviewer, show your thought process, and showcase your experience.
