We are thrilled to have a guest post from Swati Priyam. Swati is the CEO and founder of Round Robin Labs. She’s a tenured product management veteran. Before she focused on product management, she worked as a software engineer at the travel company, Expedia. Swati holds a master’s degree in engineering from Carnegie Mellon.
System design interview questions are asked because software architecture is one of the key areas in a software engineering role. These questions are asked to software architects, software engineers, entry-level engineers and sometimes even to those who aren’t software engineers. System design questions test the ability of an engineer to build a meaningful application by collaborating effectively with other coders as well as non coders within the organization. In the book ‘The System Design Interview’, authors Lewis C Lin & Shivam P Patel discuss in detail about how to structure your approach to answering questions in a system design interview which will set you up for success. The book not only talks about a useful framework to use as a guide to answer these questions but also provides several examples of design interview situations.
In this book review, I explain each step of the framework and its relevance in nailing any system design interview questions.
THE PEDALS FRAMEWORK - A PROVEN FRAMEWORK FOR CRACKING THE SYSTEM DESIGN INTERVIEW
Step 1: Process Requirements
When an interviewer asks a system design question, the first step is to understand the interviewer’s expectation by asking clarifying questions. What are you trying to build? What features does it have? Are there any constraints? By taking this additional step of asking clarifying questions, it helps the interviewee figure out the hidden questions and expectations of the interviewer.
Step 2: Estimate
Before jumping on to designing the service, it is important to estimate the scale of the system in consideration. Doing these estimations will help you understand if your architected system will actually fulfill the functional requirements, thus enabling you to think better before you jump into designing the service. When you are doing these estimations, the interviewer is assessing your analytical abilities, your assumptions, your judgment and your communication skills.
The book provides 3 frameworks which will help you to prepare for these estimation questions:
Estimating Servers Needed
When asked to estimate servers needed, follow the 3 step process to get to your answer:
Step 1: Work per single CPU core first - How much work can a single CPU handle?
Step 2: Multiply that single core number by the number of CPU cores per server.
Step 3: Multiply that number with the number of servers.
Estimating Storage Needed
When asked to estimate storage needed, follow the 3 step process to get to your answer:
Step 1: Determine the different data types.
Step 2: Estimate space needed for each type.
Step 3: Add and multiply to get the total space needed.
Estimating Bandwidth Needed
When asked to estimate bandwidth, follow the 3 step process to get to your answer:
Step 1: Determine incoming data to the server in a day.
Step 2: Determine total outgoing data from the server in a day.
Step 3: Divide both incoming and outgoing data to estimate bandwidth.
Your design will end up being very different and most likely be incorrect if you calculate incorrectly in this step. So, it is advised to solve estimation questions by building up on some common existing assumptions. The book provides a list of some common assumptions which will prove to be very handy for any interviewee to bring to the table during the interview.
Step 3: Design the Service
In order to outline the system’s functionality, you will need to figure out what to build and how to build it:
Defining the What
An easy way to define the components of a service is to use the CRUD (Create, Read, Update, Delete) framework. Each letter in the CRUD framework corresponds to a possible user action. Each of those user actions will help you further define the services you want to build.
Describing the How
Describing how to build a service usually comes with practice. You would have either designed services in your career before or you would have learnt them in school. The book recommends reading examples on these questions given in the book, building services of your own, practicing answering questions with partners and reading engineering blogs to help strengthen your ability to describe how to build services.
Interviewees tend to make these 3 common mistakes while designing the service.
Not involving the interviewer
Diving into the minutiae
Talking for too long
The book provides effective ways for the interviewees to not fall into these traps during the interview. The book also provides several design strategies as examples which they recommend to use as guidance while attempting a new question on system design.
Step 4: Articulate the Data Model
After defining the system components, it is expected that you articulate the data model which includes defining the tables, the fields, the database options and other data storage required. For choosing the database storage, often the conversation goes into choosing between a SQL and a NoSQL database. It is important for the interviewee to know how these two types of databases and their purposes are different. The interviewee might also be expected to think beyond databases and consider options like distributed file systems and object storage depending on the question asked.
Step 5: List the Architectural Components
While designing the service in Step 3 of the PEDALS framework, we defined the logical architecture of the system explaining how the system works. However, before moving on to talking about scalability, the interviewee is usually expected to address the cloud technologies required for the system and if need be, also the underlying physical technologies and assets for the system in consideration.
Step 6: Scale
In this step, the interviewee is expected to scale the architecture to meet with the estimated scale requirements from Step 2 of the PEDALS framework. The book provides techniques on how to handle different scalability issues such as handling more users and user requests, handling more data reads, avoiding crashes, providing data consistency, improving latencies, identifying and alleviating scalability bottlenecks. It is expected from the interviewee to understand how to scale the proposed solution from 1 to 1000 users, 1K to 10K users, 100K, 500K, 1M users and so on.
Summary
The purpose of the PEDALS Framework is to provide interviewees with a step-by-step flow on approaching a system design question during a short 45 to 60 minute interview session. In most cases, each step of the PEDALS framework should be addressed for a successful interview outcome. The book provides several examples of this type of questions and also explains the different technical concepts you should know to ace your system design interview.