Why System Design Questions?

Turning binary trees upside down on a whiteboard is a cool skill set, however, it only gets one so far in one’s tech career. Usually, junior to mid-level software engineering positions require coding chops and as one interviews for senior positions, the candidate is expected to demonstrate proficiency in designing applications consisting of several loosely coupled subsystems that work in tandem to deliver a service catering to several million users. The complexity of these systems spans a spectrum with some as narrow in functionality as a cache and some as broad and wide in scope as an Uber or Twitter.

You may wonder the rationale behind such questions in interviews and there are several good reasons why system design questions are an interview favorite. Some reasons to ask candidates system design interview questions are:

Does the candidate comprehend the bigger picture?
Is the candidate cognizant of trade-offs when making design choices?
Can the candidate arrive at a reasonable architecture?
Can the candidate use the right technology for a problem?
Test the breadth and depth of a candidate’s knowledge.

Interview coding problems usually have a binary outcome, either the candidate is able to work out the right solution or not. The candidate’s solution can be executed against sample data and tested for correctness especially when the candidate solves the problem on a laptop instead of a whiteboard. Either the candidate gets the coding problem right or not. However, the same isn’t true of system design interview questions. These questions are for the most part open-ended and subjective, used to plumb the depth of a candidate's knowledge on a broad range of computer science topics. Very often these questions will have multiple right answers or different answers under varying constraints and requirements.

What is System Design?

At the heart of system design questions are distributed systems. With the advent of web 2.0 and the plethora of internet companies, it is essential that services such as Uber, Lyft, Twitter, Pinterest, etc. continue to run without interruption and have the ability to scale to serve the entire world population if need be. The “system” usually refers to such a product and is composed of several other sub-services which in turn may themselves be entire systems in themselves.

System design means fleshing out higher level details for creating a service from scratch. We can keep the design as abstract or granular as we like but usually it stops short of actual implementation logic and code. The design usually encompasses the following:

Overall architecture with a whiteboard diagram/illustration
Interaction of the various components among themselves
Data flow in the system
Control flow in the system
Database schema design
Hardware estimations
Public APIs

Remember, unlike coding problems there’s no silver bullet for a system design question. System design questions require candidates to explain how smaller systems can be orchestrated to build one larger system. Sometimes, the candidate may be asked to get into the finer details of a particular component but generally these interview rounds are code-free. As a candidate, consider the system design round as a technical presentation accompanied by a lot of whiteboard-ing.

Expectations in a System Design Interview

Unlike coding interviews, a candidate can hand-wave and talk in abstractions during a system design interview. There’s no compiler to nit-pick or corner-case test cases to execute, nevertheless, the system design interview still serves as a litmus test to the professional and technical maturity of a candidate. Generally an interviewer observes the following competencies in a candidate’s performance during a system design interview:

Comprehension of the problem
Requirements clarification. The number of users to be supported by the system. The number of expected API invocations. Uptime requirements or service level agreement (SLA) to be supported.
Use of appropriate technologies. For instance, when designing a search engine, the several million links should be processed in parallel using a Big Data technology such as Spark or MapReduce instead of processing them serially.
Use the right plumbing. For instance, does the candidate use a message bus such as Kafka to decouple two services or use remote procedure calls (RPC) for interaction between the two services.
Use of the right storage medium. For example, can the candidate distinguish between the appropriate use case for SQL versus NoSQL databases.
Interfaces. How to design the public and private interfaces for REST APIs, classes, sub-systems etc.
Scaling. Can the system be scaled to meet increasing demand? For example, a database may need to be partitioned and distributed as the load on the system increases.
Optimizations. Can the candidate appropriately apply optimizations. For example, data sent over the network or stored in a database can be compressed to save space with the trade-off that the decompression must take place before use.
Maintainability. Can the candidate think about design tradeoffs that may affect future maintainability and sustainability of the system. For example, when designing a cloud-service the candidate may suggest ways to avoid vendor lock-in so that the service can be easily ported across different vendor clouds.
Reliability: Can the candidate design a system that meets reliability requirements. For instance, can the system tolerate data center failures, machine failures, software failures etc.

Preparing for System Design Interview

There’s no better preparation for system design interviews than actually working with and contributing to the source of both private and public distributed systems. Books can help too, especially when learning the theory of distributed systems. We would suggest reading the book designing data intensive applications for all readers to get started with distributed systems. Reading up on the documentation of existing open-source distributed systems such as Hadoop, Cassandra, Google Borg, Kuberetes, Kafka etc and latest research papers in the field is a great way to enhance one’s understanding of the design of such systems.

However, to be fair, most software developers don’t interact with distributed systems as part of their day to day activities. Most of us work on already mature systems where incremental features are added or maintenance work is in progress. Rarely do we get to work on a truly distributed system with millions of users being built from scratch. It is this lack of exposure rather than incompetency that most software engineers don’t fare well in system design interviews. Gaining expertise in system design will not happen overnight and require years of working in, reading about and designing distributed systems.

Most candidates will need a shot-in-the-arm or a magic pill to help prepare for system design interviews in just a few weeks rather than progressively develop their system design expertise over several years. There are several paid courses on the market with varying quality and usability for system design interview prep with Grokking the being the first of its kind. Our goal is to open-source system design preparation for all candidates and provide free high quality curated content for system design preparation. You can start off by reading our first blog on designing a URL shortener.