System Design Interviews

As I network through tech I frequently hear newcomers ask how to answer system design questions. I’ll try to clear that up in this post.

Why am I being asked to design a parking lot?

If you’re comfortable writing code and work on multi-component projects, then you might be familiar with maximizing reuse without high coupling. In an interview, they will test this with an object oriented design questions. In a service-oriented world, we are now being asked to do this with systems.

These concepts are inconsistently taught across all programs. Unlike a for loop, interviewers can’t always expect a candidate to be familiar with systems and services. Unfortunately, the interviewers are given a checklist and if it contains system design, they ask it. More bad news: the recruiters aren’t told what’s on the list. As a result, you and your interviewer have different ideas about what’s going to be asked.

How To Learn This

Question and Answer Format

Question

Questions will be phrased as: “design a system to XYZ”, “design a pre-existing software system”, “draw the architecture for XYZ”. Examples:

  • Existing software: Uber, Lyft, Facebook Messenger, Amazon retail website, Google Search, DNS, Expedia, Docker, GitHub, WordPress, any website you can think of.
  • Interview problems: Parking garage, generic search engine, inventory management system, hotel guest management system, log aggregation

Anything can come up here depending on how prepared or creative the interviewer is.

Boxes and Lines

The answer is going to be boxes and lines.

Boxes_and_Lines

Approaching the Question

Clarifying Questions and Requirements

If you’ve done any preparation or any interviews, you will know you need to ask clarifying questions and get the requirements. Treat your unimplemented solution as a black box and try to describe the inputs and the outputs. Take Twitter for example:

  • Are tweets text only?
  • How will customers get data out of the system? Browser, phone, REST API?
  • Can a customer send one tweet at a time or many?
  • Do users have accounts or is this anonymous?
  • Is user following enabled?
  • Are there multiple feeds or one giant aggregated feed of tweets?

You might be thinking “Do you even know how Twitter works?” If you are, good. You need to make sure you and the interviewer are on the same page. You can’t come up with a design that has every current Twitter feature so make sure to scope it down to a few specific features. Saying “I’m going to implement user accounts, tweeting text only, and retrieving messages without the follower system as my first round” is extremely helpful. The interviewer will know that you are aware that there are more features and are choosing to defer than rather than forgetting them. This also makes the problem easier. If you don’t specify which aspects you are implementing, you and your interviewer will have different ideas about a good answer.

Note: These interviews are 45 to 60 min. It’s better to start small and then discuss enlarging the scope with the interviewer than the other way around.

Always identify the data.

The data tells you a lot about the design. What data is being sent? What data is being stored? Does the data need to be sorted? How quickly does the data need to be available? This provides another way to get requirements. Example:

  • How will data be searched? Maybe we start with hashtag search only.
  • Can anyone see all tweets or are some tweets restricted viewing? We can start with all public.
  • When we search for tweets, do we return all of them that match or only the top 100 most recent? Let’s do all of them at first for simplicity.

The Boxes

What are the boxes? Don’t be thrifty on the boxes. Boxes are more easily grouped than separated. You can do a “discovery” style and follow a single piece of data through the system.

For example, a customer hits the “Tweet” button from their browser. This goes to some server, the TweetManager. The tweet needs to be stored and show up in the user’s page and the global feed (as per requirements of no custom feeds). The tweet also needs to be searched later by hashtags (as per requirement of hashtag search only). This tells us we need a place to store the whole tweet, TweetStore. We might also need to store user information that can reference their tweets, UserStore and maybe UserManager. Somewhere else, we need to support hashtag searches, SearchTagManager and/or HashTagStore. Finally, we can throw in notifications for fun and have  NotificationManager. Here’s what that looks like:

Twitlines

  1. The user tweets and the tweet is sent to the TweetManager (here we assume that the user is logged in and is who their cookies or headers say they are).
  2. The TweetManager stores the Tweet in the TweetStore. At this point it is linked to the user that posted it.
  3. The TweetManager sends the hashtags in the tweet along with a reference to the tweet in the TweetStore.
  4. The HashtagManager adds the tweet reference to the list of all tweets related to that hashtag in the hashtag store (this creates a link to the tweet store).
  5. The TweetManager sends a completed message to the notifier which then shows everyone logged in that a new tweet has been posted.

We also have Login and ‘A’ which is searching by hashtag.

Note: This is a simplified example. I would strongly discourage using this answer in an interview because it doesn’t scale, has high latency, and will likely result in data inconsistency.

Hey, Where Are My Tables?

You may be tempted to say one of your boxes will be a SQL database and start describing your schema in detail. Don’t. Don’t do this unless the interviewer asks you to go into details. If you focus on details, you won’t have time to answer the whole question. However, having them at the ready doesn’t hurt in follow up questions.

Grouping

It turns out I have 3 storage boxes and 3 service boxes. Do they all need to be separate or can some be together? There are many driving factors for doing this:

  • Minimize coupling: you should minimize lines between two boxes for a single “trip” through the system
  • Follow the K.I.S.S. rule: you should not have to fan out to turn one tweet into 5 calls to other boxes
  • Asynchronous vs. Synchronous: know which lines need to be blocking and which can be done asynchronously. In some systems, the different types of calls go to different boxes (not always).

A simple grouping might be all the logic in one box and all the data in another:

Group

Scalability

Scalability is challenging. In these questions, you can either predict how to scale the system or you can do this exercise repeatedly:

  1. A significant political event is happening. A few key individuals are sending out tweets through the event. Everyone on the planet is trying to search for tweets with the event hashtag at the same time.
  2. Identify what will break first and how it will break. If it breaks, does it break only the overloaded part of the system or other parts too? In this case, the hashtag manager can actually be scaled to tolerate the number of requests. However, the data store (no matter what store you use) will be in trouble.
  3. Discuss or draw a way to solve this. The most common answers to this are asynchronous communication with queuesreplicas, and some form of sharding.

Often you need to do one or two examples to show you understand what scaling is and how to alter a system to support more traffic.

New Features

You’re feeling great because you drew boxes and lines. You came up with your own scaling answers before the interviewer asked. Then the interviewer throws a giant wrench into your answer: I want you to implement followers, identity verification, and malicious account detection.

If you only have 5 minutes left, feel free to verbally explain while waving your hands at your diagram. Throw a quick machine learning trained fraud box and a service that requests identity verification through a third party vendor. Usually when these features are requested near the end of the interview it isn’t about implementing them but about discussing how you can grow your solution. If you can’t discuss the solution, it might look like you copied it from a book.

Follow Up Questions

  • Why is this data here and who can access it?
  • How long does it take to complete one customer request?
  • Why are these two components separate or together?
  • Can you make this more generic or into a platform? How would you covert this into a Software as a Service product?

I Did All The Right Things And All I Got Was This T-Shirt

I’ve had too many interviews where the interviewer was stubborn, critical, condescending, dismissive, and basically an asshole. It’s almost impossible to succeed in these cases unless you fit their mold perfectly and even then it’s not a guarantee. Here are some signs that it might not be your answer that’s at fault:

  • Your interviewer is flipping between high level criteria and specific technologies (i.e. we need a customer service but please use AWS lambda)
  • Your interviewer is telling you where to draw your lines without explaining why
  • Your interviewer is repeatedly cutting you off when you try to ask clarifying questions and replies with “just implement it the way it is”
  • Your interviewer says “uhhh” a lot and doesn’t seem to know where he or she is going with the question
  • Your interviewer changes the question halfway through: did I say architecture? I meant library
  • You were incorrectly leveled by your recruiter (surprise!) and you feel deeply in over your head.

Leveling?

All companies put their applicants into buckets that are highly variable but sort of follow this structure:

  • 0 to 2 years of experience: entry level
  • 2 to 5 years of experience: mid level
  • 5+ years of experience: senior level
  • 12+ years of experience: principle or CTO level

Highly variable by company, geographic area, job role, and how the recruiter feels that day.

I think it’s unreasonable to ask an entry level applicant a design question because they may or may not have encountered them. If an applicant is on a border of experience levels, they may ask this question to see which bucket they fit in. Finally, as above, recruiters and interviewers don’t talk.

In Conclusion

Just don’t draw a single box with a SQL database schema as your answer. Good luck!

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s