How to Use the Whiteboard in System Design Interviews by@anthonypelle
1,822 reads
1,822 reads

How to Use the Whiteboard in System Design Interviews 

by Anthony PellegrinoAugust 28th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

In this article, I'll outline the six steps you can follow to effectively whiteboard every system design interview question that may come your way.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - How to Use the Whiteboard in System Design Interviews 
Anthony Pellegrino HackerNoon profile picture

Abstract by Oleg Shcherba

You'll likely be asked some system design questions when interviewing for a software engineering position at many tech companies today.

These interview questions are often as challenging as they are important.

You'll find that many recruiters or hiring managers will ask you to use a whiteboard to outline your designs as you answer the questions.

Many candidates may feel a bit intimidated by this or even dread the whiteboard, considering aspiring software engineers are frequently asked to complete coding questions using a whiteboard or even a piece of paper.

This is, of course, significantly more difficult than using an IDE, hence the potential feelings of dread or anxiety some may feel about using them.

Even so, you shouldn't be stressed about whiteboarding for system design interview questions.

Unlike coding interview questions, the whiteboard is actually a massive help when asked to design a particular technical system in a short time.

Given that these interview questions are typically ambiguous and complex, the whiteboard makes listing requirements and drafting high-level design diagrams incredibly straightforward.

So, what's the best way to do it?

In this article, I'll outline the six steps you can follow to effectively whiteboard every system design interview question that may come your way.

In years past, most candidates were interviewed on-site at companies, often using whiteboards in conference or meeting rooms.

However, in the wake of the COVID-19 Pandemic and the ongoing (and growing) popularity of remote work, many software engineering candidates are using virtual whiteboarding tools such as Zoom White BoardMiro, or Whimsical.

While the process I'm about to cover remains the same, virtual whiteboard or otherwise, you may find whiteboarding with these tools a bit awkward if you're not used to it.

So, it's recommended that you practice beforehand so it's all smooth sailing come interview day.

The Six Steps for Whiteboarding System Design Questions

For the purposes of this article, I'll use the "Design Instagram" question to demonstrate each of these steps.

1.) Clarify & Document System Requirements

So, the hiring manager has just asked you to "Design Instagram." They will likely provide you with some general requirements that your design will need to account for (in this case, users must be able to upload and share images), but expect the interview question to be intentionally vague and open-ended.

Because of this, it's best to begin by breaking the question down into smaller, more manageable chunks.

You can do this in several different ways.

For example, you can make a simple list of system requirements on the side of the whiteboard.

Don't hesitate to ask your interviewer for clarification. Clearly restate the question before diving into it headfirst.

Sometimes candidates may have misunderstood or missed something, and reiterating the problem gives your hiring manager the chance to clarify or correct you if necessary.

But don't stop there. Be sure to ask plenty of questions to tease out all the necessary (your interviewer will be expecting and evaluating you on the questions you ask).

What amount of traffic will this system need to handle on a daily basis?

What types of data will it need to store?

Needless to say, these system requirements will influence your design decisions, so you must clarify and understand them before moving forward.

Then, as you reiterated the question, repeat and list these requirements.

From here, it'll be easy to stay organized as you flesh out your solution to the problem and effortlessly eliminate inefficient or sub-par design approaches.

So, if we're thinking about our "Design Instagram" example:

We know that this system will require a few things right off the bat, such as:

  • Users can upload images from a mobile client,
  • Users can follow other users,
  • The system will need to generate a feed of images that updates over time,
  • The system must scale to millions of users and millions of photos per month,

Suppose we're accounting for 10 million users who post 2 images every month at 5MB per image. In that case, that gets us up to 1.2 petabytes of data per year.

It's always helpful to keep these requirements visible on the whiteboard as you go along. Then, you can quickly return to them or refer to a particular one while fleshing out your design or explaining your decisions.

2.) Sketch Your Data Model

Once you have all the requirements established, you'll need to define the data model of your design.

Of course, different data will have different needs regarding how it is stored and accessed.

As you begin diagramming how the different data types in your system will interact, it'll become easy to see what component decisions make sense and which don't for your particular system.

So how do you do this on a whiteboard?

It's simple.

Make a small table with 2 columns for each database that'll be used for the relational data of your system.

One column will be for the id. So, for example, the id for a "users" table would be "name."

The other column is meant for the data itself. For example, in this "users" table, "name" is stored as a string, as you can see below:

What would this look like for our "Design Instagram" example?

Well, our system will need to store several kinds of data, specifically users and images, along with user interactions (such as following, liking, etc.)

When it comes to storing these things, you'll have to decide between using relational or non-relational databases.

For our purposes, it's best to go with a relational database - maybe MySQL or Postgres. The reason is that our system will frequently run relational queries such as "fetch all images that X user posted."

So, when we're whiteboarding this system design question, we should make three separate tables - a users table, an images table, and a user interactions table.

3.) Make Note of Your Decisions Points As You Go

Don't forget that this is an interview no matter the system in question.

Hiring managers ask tech candidates system design questions to discover and evaluate how they think and solve complex ambiguous problems.

Of course, they'd like to see that you're capable of artfully designing a technical system, but if that's all you do, you'd be selling yourself short.

So, as you're designing your system on the whiteboard, don't forget to note and explain the design decisions you're making along the way.

A significant part of this is outlining the trade-offs and takeaways of any particular choice.

Be sure to clearly explain to your interviewer why your decisions or component choices are the most appropriate or effective for the problem at hand.

Luckily, a whiteboard makes this rather easy. For example, you can underline, circle, star, or make parentheses to emphasize your points or provide important context for your design.

4.) Take Notes Right on the Whiteboard

Just as you should note and emphasize your design decisions on the whiteboard, you should also do so in general for everything else relating to your design.

It's best to decide on a specific area you can return to throughout your design for note-taking. Usually, one of the corners is best.

As we mentioned, hiring managers use system design questions to evaluate your problem-solving skills and how you think.

Of course, these people are human beings - they're not mind readers. So, these notes can provide the context or clarification necessary for interviewers to understand your thought process.

Abstract by Oleg Shcherba

For example, in our "Design Instagram" example, you can note why you used a relational database. In this case, it was because our system would frequently be running relational queries.

A notes section also helps make the system design diagram easier to understand.

Otherwise, you may find that you need to repeatedly explain yourself or re-explain some component or decision over and over, which is obviously less than ideal.

Nevertheless, these notes aren't only for your interviewer.

Given how complex and multifaceted system design questions tend to be, you'll likely need to reference or re-reference previously defined components.

Your notes section will make it easy to do that and help avoid rambling or confusing your interviewer.

5.) Flesh Out Your Design

Now comes the fun part.

It's time to start diagramming your system design.

Remember to always start simple and then scale up as you go.

We've already broken up the problem into more manageable chunks in the beginning, so this shouldn't be too hard.

Outline the most straightforward design first. Note how the components work together and always tie them back into the system requirements you established initially.

As you continue to scale up your design, frequently check in with the interviewer. If you're not on the right track or missed something important. They will redirect you if necessary.

While this part is the real bread and butter of system design interview questions, it can be challenging for some candidates to both diagram their solutions while also speaking and explaining as they go along.

But, if you practice answering system design questions beforehand, you'll quickly get the hang of it.

The whiteboard gives you a lot of possibilities for how you actually outline your design. For example, you can use a variety of shapes to designate various components.

Databases are typically represented as cylinders, relationships as arrows, etc.

Chances are, your interviewer will not have any strict format on how to draw your components (if they do, they'll tell you). So, you can be a bit creative here if you wish.

So, what would this look like for our "Design Instagram" example?

Many people start their diagrams with the backend.

We could begin ours with the database considering we had previously defined our data model earlier.

For example, we'll have one database for metadata, another for storing objects (in this case, images) using Simple Storage Service on AWS (Amazon S3), and finally, a cache for retrieving data quickly.

So, our Instagram design could look something like this:

Considering our system needs to scale and be capable of handling millions of users, we can add a load balancer into the mix to prevent any of the components from overloading.

6.) Be Legible At All Times

That said, you'll need to keep everything legible and readable as you whiteboard your system designs.

It'll do you no good if your brilliant design is gibberish to your interview.

This goes for both your notes that you take throughout and the design diagram itself.

Of course, this won't necessarily be something you need to worry about if you're using a virtual whiteboard program. Even so, you still need to make sure your diagrams are clean, tidy, and easy to follow.

For instance, take a look at our final Instagram system design diagram:

And there you have it! Follow these six easy steps on effectively whiteboarding system design interview questions, and you'll be in good shape for your upcoming tech interviews.

For more system design interview prep, be sure to check out