Product added to cart
How to Whiteboard for System Design Interviews
Whiteboarding is common throughout tech interviews for many reasons, but mostly for its simplicity. Armed with a whiteboard and marker, candidates are free to illustrate their thoughts in an efficient way.
System design questions, commonly asked of software engineers, engineering managers and technical program managers, are infamously ambiguous and complex. They're practically made for whiteboarding, as enumerating requirements and outlining a high-level system diagram are critical first steps.
So what's the most effective way to use the whiteboard when answering system design interview questions? We wrote this article to guide you.
In the past, whiteboarding sessions mostly happened during on-site interviews. These days, due to COVID-19, most system design rounds are conducted virtually using an online whiteboarding tool like Zoom White Board, Miro, or Whimsical. Either way, the process is the same. We encourage you to try a few to get a feel for the process. Your target company may have a preferred platform; ask your recruiter if you'll have your choice or be expected to use something specific. If so, practice using that as you work through practice questions. Ultimately, there are six main steps you need to follow to best whiteboard system design questions. We'll use the question "Design Instagram" as an example, and talk you through the steps. Let's get to it!
Six Tips for Whiteboarding System Design Questions
1.) Clarify & Record Requirements
Because system design questions are often vague, you'll need to begin by breaking up the problem into smaller, more manageable pieces. There are many ways to do this. When it comes to system design, it would be best to make a bullet-point list of the design requirements. Restate the prompt, then gather information. What load will your system have to handle on a daily basis? What sort of data will be stored? How often will it be accessed? Changed?
These requirements will drive your component decisions, so make sure you spend plenty of time here. List the requirements you've defined (e.g. 100,000 users daily, each sharing ~5 photos, roughly 5MB each in size) to get a sense of the traffic your system will need to handle. There are lots of resources out there to help you run back-of-the-envelope calculations, so it may be helpful to memorize a few key numbers. Once you have a defined set of requirements, you'll be able to stay organized and to treat each idea separately. Your component decisions will also be made easier as inefficient approaches are easily eliminated. The overall effect is that your answer should be much clearer and structured when designing your system and communicating with your hiring manager.
How to do this on a whiteboard: List requirements in bulletpoints. Write out the simple formula used to arrive at a number for daily/monthly/annual traffic. Keep this visible in one of the corners of your screen as you work through the rest.
Example: "Design Instagram" clarifying requirements
In this example, we know our system will need to include a few key features, such as functionality for:
- Uploading images from a mobile client
- Users following other users
- Generating a feed from images
- At scale: 10 million users, 2 photos per month, 5MB per photo
In total, this gets you to a baseline of 1.2 petabytes of data per year. Your system must handle this level of traffic, and ideally scale up.
Make sure you're aligned with your interviewer before moving on. Keep these requirements visible on your screen as you design your system; you should refer back often as you begin to diagram.
2.) Diagram a Quick Data Model
The next step is to begin to define the data model. Different data will need to be stored and accessed differently. Fundamentally, diagramming the relationships between the different data types you'll handle will help eliminate many component decisions that don't make sense.
How to do this on a whiteboard: For relational data, add small tables (2 columns) for each database you'll use. One column will hold the ID (e.g. "name" for a "users" table) and the other will hold the data itself (e.g. "name" will be stored as a string in the "users" table.) See below for details.
Example: "Design Instagram" data modelling
Generally, we need to store users, photos, and "user interactions." You'll need to choose between a relational vs. non-relational database. We'll go with a relational database structure for now - something like MySQL or Postgres – because you can imagine that relational queries, like "fetch all photos posted by X user" will be run frequently.
If we're using a relational database, we may draw three tables on our whiteboard. One for users, one for photos, and one for user interactions. Our data models for the user and photo databases will look something like this:
3.) Decision Points (Note Throughout!)
Some candidates tend to forget to make note of the takeaways or key points. While drawing your diagrams, you should always list the takeaways your hiring manager should be focused on. Clearly communicate the key points involved in your system design. For system design-specific whiteboarding, this also means you should be clearly explaining the trade-offs involved in your system design decisions along with why your design choices are most appropriate to the problem space.
How to do this on a whiteboard: You can choose how you'd like to emphasise your decision points or takeaways - you might star or circle key components, note choices in parentheses, or underline. It's up to you, but be consistent.
Design trade-offs, especially, will most likely be the most important takeaways you'll need to make frequent notes of during your whiteboarding sessions. Which, brings us to our next tip:
4.) Take Notes
One of the best pieces of advice for all interview whiteboarding, not just system design, is to remember to take notes on your whiteboard. Before you begin, you should designate an area of the whiteboard to notes you'll take throughout the process.
Tip: As you build your system, make sure to include notes regarding design trade-offs and takeaways.
These notes can help provide additional clarification and make your overall design diagrams much more digestible and easy to understand. This is the area where you should include key concepts so that you do not need to constantly be re-explaining or re-referring to the same thing over and over. Your notes section will also allow you to easily reference information that you already went over. Chances are, especially when considering the complex nature of system design diagrams, you'll need to refer back to previously defined components. Your notes section will help keep this organized. Otherwise, candidates can run the risk of rambling and hard-to-understand answers.
How to do this on a whiteboard: Dedicate a corner of the board for your notes, and add sequentially. Keep them organized & legible to you can refer to them later, if needed.
5.) Diagram Your Design: Start Simple, Then Scale Up
Start with the simplest design first, talk through the component relationships and tie them back to the requirements you defined early on, then elaborate as you scale your system. Talk through your decisions, and be sure to check-in frequently to make sure you're on the right track. If you need additional guidance on how to do this, watch the videos we've embedded below. It might be tricky to diagram as you speak, but you'll improve with practice. Remember that system design whiteboarding sessions are meant to showcase your high-level decision making and domain knowledge. Thankfully, simplicity works best. Components and component relationships can and should be represented cleanly.
How to do this on a whiteboard: Here's where your creativity can shine through. At the most basic level, components are represented with simple shapes (for example, databases are often represented with cylinders) and relationships are represented with arrows. There aren't many strict conventions, so be sure to label everything and be consistent.
Don't worry too much about your drawing skills. If you're interviewing remotely, the interviewer will have you use an online whiteboarding tool (we like whimsical - check it out in use in the videos below.)
Example: "Design Instagram" system diagram
A common approach is to start with the backend; often you might start with your databases, as you've just finished defining your data model.
For example, we've chosen to use one database for metadata, AWS's S3 for object storage (photos), and a cache for quick data retrieval.
Later on as we think about scaling up, we'll add a load balancer to route requests to the appropriate services, helping us avoid overloading any components deeper down the stack.
6.) Keep Things Legible
This, of course, mainly applies to on-site interviews which utilize a physical whiteboard. However, even if you are using a virtual whiteboarding program, you must always ensure that your whiteboard is easy to read and understand. You should avoid chicken scratch and convoluted diagrams, whenever possible. In the end, if your hiring manager is struggling to comprehend your whiteboard, then your system design experience will be lost in translation. This, as you can imagine, is incredibly counter-productive in your interviews. One actionable tip is to maintain some white space. In other words, be sure to leave some space between points or diagrams to keep things legible.
August 15, 2022How to amplify your productivity with a whiteboard
July 18, 2022How to Whiteboard for System Design Interviews
June 06, 2022How to Keep Your Board Clean
May 31, 2022Benefits of Having a Noticeboard in the Office
May 31, 2022Glass Board vs Whiteboard