SEE ALSO: The System Design Interview, an online course based on PEDALS™
I’m excited to announce the launch of a brand new online course: the System Design Interview. It’s hosted on our Teachable platform.
I’ve noticed that system design (SD) questions become remarkable popular across a range of different roles from software engineering to product management. I’ve also found that system design questions have been common with both experienced and entry-level roles.
However, in my review of current interview prep materials for SD questions, I’ve found that most materials aren’t as helpful or comprehensive as advertised. One of the biggest problems is the lack of a clear-cut, definitive framework to help candidates navigate their way through an SD question. And hence, my co-author, Shivam P. Patel, and I devised a new framework called PEDALS™.
What is the PEDALS Method™?
PEDALS™ is a framework for answering system design interview questions.
You can think of it as a checklist: it reminds us what components to discuss to make sure we have a complete and thoughtful answer. It prevents us from forgetting critical steps.
PEDALS stands for:
I’ll summarize each one of the components below.
What are system design questions?
System design questions test one’s ability to build software systems from scratch. Here are some examples:
Design an API for a payment provider.
Design an order inventory system.
Design a question and answer website like Quora.
Create a back-end system that created unique IDs.
What are interviewers looking for?
Software engineers and architects are most likely to get system design (SD) questions. However, the following folks get SD questions too:
SD questions appear at the interview because the roles above play a big part in building software systems that scale. Unlike the pre-Internet era, a modern application must work across thousands of servers, ready to serve millions and perhaps billions of users.
Interviewers love SD questions because it tests a candidate’s ability to:
Specify system requirements clearly
Articulate the desired system behavior
Specify constraints
Contribute to technical brainstorming
Point out technical drawbacks
Decide between technical tradeoffs
As a result, during the SD question, the interviewer wants you to specify:
The key services, preferably in RESTful API format
Define the data model
Define the cloud architecture, with an emphasis on scale
How to approach system design questions with pedals
Process requirements
What we really mean when we say process requirements is “clarify” the question:
Going further:
What are the goals or outcomes?
What are the constraints?
What features should be left out?
Many candidates forget to clarify the requirements. They jump in, finding they forgot an important goal. Other times, they fail to scope the problem, allowing their response to run too long, covering minutiae that the interviewer doesn’t care about. Both mistakes can result in rejection.
Estimate
This is an optional step, but sometimes interviewers want candidates to estimate, as part of processing the requirements:
If you’re familiar with Fermi or market sizing questions, doing a quick back-of-the-envelope estimate shouldn’t intimidate you.
Design the service
This is about fleshing out key components of the service. For example, to build an online video service, you might consider services that:
Videos: allow users to view, upload, or delete
Users: allow for creation, viewing, modification, or deletion
Etc.
Articulate the data model
This is about defining the database tables and the corresponding fields. If you defined the API well, then each service endpoint should be a corresponding DB table.
For example, with an online video service, there should be a videos and users table, among others.
From there, interviewers want you to specify the fields inside each table. For example, with the user table, some potential fields can include:
username
first_name
last_name
email
user_id
create_date
modify_date
List the Architectural Components
Listing the architectural components is about cloud architecture diagrams. That is, what cloud services do you need to enable your service? Do you need a server like Amazon’s EC2? Or simple file storage like Amazon’s S3?
If you’re not comfortable drawing cloud architecture diagrams, do take a moment to practice.
