I have been a technical program manager now for over ten years at a mix of big tech (FAANG) and startups. I have been on both sides of dozens and dozens of interviews for TPMs. The one area of weakness that I constantly see (and the area that I struggled with the most in the beginning) is the system design interview.

The purpose of the system design interview is to assess the ability of a candidate to build end to end software systems made of up different technologies. The system design interview is a core part of most software engineering hiring loops. It is now becoming more common for companies to expect TPMs to also have some system design experience. You should not be surprised to have a system design interview thrown in the loop.

There are a ton of great resources for preparing for system design, some of which I’ve listed at the end of this article. However, most of these resources are targeted at software engineers and not technical program managers. That doesn’t mean you shouldn’t study them – you absolutely should! But there are some key differences you should be aware of that these resources might not cover. Given the lack of resources specific to TPMs, here’s my attempt to provide my perspective on these differences and better prepare TPMs for system design.

Before we get started

Before I jump in, keep in mind that the TPM is a very broad title, with some companies expecting more of the T (Technical) and other companies expecting more of the PM (program management) part. Try to get a feel of where a company falls by reading the role descriptions carefully and looking up current TPMs at the company to see what their past looks like. Example: If most TPMs in a company come from a software engineering background, you can expect more of the T. That said, this should be a good summary of TPM expectations for most large tech companies (FAANG style).

The System Design Walkthrough

The System Design is primarily lead by the candidate, not the interviewer. This is especially true for TPMs, who are expected to show more leadership and initiative than a software engineer might. If a TPM knows the right answers but is constantly asked for them through the interview, that’s considered a red flag. But even if you stumble on a few technical spots, leading throughout the entire interview is a good sign. It shows that you can drive ambiguous projects.

Write everything down on the whiteboard. It makes you seem confident and slows down the pace, giving you time to think and less time for extra questions at the end.

Always explain out loud what you are thinking. It’s a little awkward at first since most techies are introverts that prefer to think through before speaking. But interviews like to know what options you have considered. What you decide not to do can be just a valuable as what you do decide to do.

Here’s a walkthrough of a typical system design. Get familiar with these 4 parts of the interview so that you can lead the interview.

1. Problem Scoping

The interview will start with a problem statement that requires a system that you will design. Generally software engineers will be given something a little more specific and technical like “design a system to sort popular products across x categories”. For TPMs, you can expect something more vague and open like “Design a food delivery service to help local restaurants grow”.

TPMs are expected to have more product and program management sense than engineers. This means that rather than diving directly into the problem, you need to take the time to scope the problem. For some reason, many TPMs who are great program managers forget to inject this skill into the system design – perhaps because they think system design is purely technical. Don’t make this mistake. Before jumping into the technical details, you need to drive clarity about the problem. You do this by asking questions and stating assumptions. Some good starting questions might be:

What is the problem we are trying to solve?
What is our timeline? What are our resources?
Who are the types of users?
How many users will we have?
How much data should we expect to store?

After I state a question, I like to make up a reasonable answer (“Let’s say we have plenty of resources, but we need to launch this in less than 6 months since restaurants need to grow quickly”). This shows I can make good assumptions and also allows me to steer the flow of the problem. For example, if I make an assumption that the number of users is low, I don’t need to worry about scaling (but keep in mind these assumptions could change later on). If the interview doesn’t like your assumptions, they can always jump in.

Use Cases

Now, we can take the the problem and craft some use cases and features. Break up the features by the type of user. For example, for our food delivery we might have:

Customer
- View local restaurants
- Order food for delivery from home
- View order history
Restaurant Owner
- Input menu items and prices
- View/Fulfill customer orders

Those are probably the minimum features we want to build to support an MVP. We could easily think of more to add such as rating restaurants, tracking order status, analytics, etc. As a TPM, I recommend going beyond the minimum use cases. There won’t be time to implement anything more than the basics, but it shows you have some product sense and can think beyond the basics.

Metrics

This is also a really good time to bring up metrics. It’s not difficult and Interviewers love hearing about metrics, especially as a TPM where you are responsible for ensuring the success of the system. There are two parts to this. First, state what the goals are for the system. For our food delivery service, we could say “We want to increase overall number of sales and delivery sales”. The second part is how will you measure it? “We can track number of orders or revenue”. Don’t forget the metrics, it’s an easy checkmark win.

2. High Level Design & Architecture

Now that we’ve defined the problem and laid out a few use cases, we can start thinking about the solution. If you haven’t yet, grab a marker and draw out the basic components and flow of the system. Always start simple and add complexity as needed. The good news is that 90% of the problems follow a similar pattern.

Front End Clients
1. Customer Client (Mobile or web app)
2. Admin Client (Mobile or web app)
Back End
1. API Gateway (or Webserver)
2. API Services
  1. User API
  2. Order API
3. Database

3. Core Components

Deep dive into each component to explain what kind of technology it will use and how it will interact with our data (inputs and outputs). Usually you will not be expected to write out any code. You can write out some simple pseudocode if helps show your logic.

Try not to mention too many specific platforms and instead keep it generic (SQL instead of Postgres; NoSQL instead of MongoDB). This is also a good time to pro-actively bring up trade-offs in the design. Otherwise you will likely be asked about it later, so better to choose the trade-offs yourself 🙂

Database

It’s generally easiest to start with the database design and then flow outwards from there. Think about all the data you will need to store to make the system work.

Decide whether you are going to go with SQL or NoSQL. This seems to be a really popular question in system design. You can usually get away with either choice for most designs, but you must explain the reasoning. If you aren’t sure, usually SQL is a good choice.

For SQL:

Highly structured data; lots of relationships; well known technology

For NoSQL

Large amount of data; data is unstructured; low latency

Once you’ve made the decision, start drawing out your database tables or document structure. This part is important since it signals whether you can model data correctly in the system. For our food delivery, we might have 4 tables: CUSTOMER, ORDER, STORE, and MENU

Write out the columns needed for each table, but keep it to the minimum necessary. Explain why a column is needed. For example, the address of a customer is needed so we know where to deliver the food.

Data Flows

Explain how the users will interact with the system. Map your use cases and features we discussed earlier to actual components.

Let’s start with the customer (the business owner side is very similar)

View local restaurants
- Customer app will send a HTTP request to Store API (REST service) with location
- Store API service will query STORE table and return all restaurants within 10 mile radius
- Customer app will display list of return stores
Order food for delivery from home
- Customer can select from list of nearby stores retrieved
- Customer app will load menu items by sending a request to Store API with selected store id
- Store API will query MENU table with by store id and return all menu items
- Customer app will display list of returned menu items
View order history
- Customer app will send request to Order API with customer id
- Order API will query ORDER table with customer id
- Customer app will display list of orders sorted by recent date

4. Technical Discussion

The final part of the interview can go in a lot of different directions depending on the interviewer. You can expect topics like trade-offs, optimizations, scaling, additional features, etc. The goal is to poke at your design and make sure you understand its limitations and how you might be able to fix them. Here’s a few examples:

Trade-offs

Should we create a single system for all restaurants or duplicate for each restaurant?

OK answer: Duplicate the system for each restaurant so that we can reduce complexity.

Good answer: Single back end system for all restaurants to keep resource cost down. Could also use single mobile app for all restaurants. This will require only one login and can share customer info across restaurants. Other option is to white label single mobile app for each. This gives better branding for each restaurant, but requires more login/apps for end user.

Scaling

What if we scaled this to 10,000 restaurants? How could we scale this system?

OK answer: We could run the database/system on a bigger CPU or add more memory (vertical scaling).

Good answer: A large number of restaurants means that will have a lot of rows to read in our growing database. We could shard (split) the database by region (maybe by county for instance). This would vastly increase the speed of looking up nearby restaurants since we would only need to lookup those in the customer’s region.

Add Feature: Notifications

We’re currently missing a way to notify customers that their order is on the way and when it will arrive. How can we fix this?

OK answer: We can add another API endpoint to check the status and have the app query this endpoint regularly to refresh status. Not great since we have to constantly ping the service and user might not have the app open

Good answer: We can add a Notification Service that uses SMS or In app push notifications to update the customer on their phone. What are the trade-offs of SMS vs push notifications?

Pro Tips

The system design interview is very open ended and is primarily led by the candidate, and not the interviewer. Leverage your strengths here by directing the conversation in areas that you know well. If you are really solid at talking about use cases, spend time laying out the main use cases, and then talk about edge cases or other interesting scenarios. If you have a specific skill in databases, talk a little more in depth about databases. As a bonus, this also leaves less time to discuss areas where you may be weaker. Don’t worry too much about spending too much time in one area or getting down a rabbit hole – the interviewer will definitely interject to steer you back or move onto the next topic, and this isn’t a negative thing unless you are really off topic.
Once you have covered the overall design and components, it’s better to go deep in one area or feature than try to cover everything at a medium level. The goal isn’t to do an exhaustive design over everything, but enough to make sure that you could do a full design. Covering one part in depth can show this better than a weak design with more overall coverage.
For metrics, it can be tempting to use “customer satisfaction”, but this is generally not a good metric. It is difficult to measure and usually doesn’t align with the goals.

Summary

The system design interview doesn’t have to be difficult. Look at this as an opportunity to show your strengths. As a TPM, pay extra attention to discussing the product aspects and success metrics. Prove your leadership by driving clarity about the problem. Guide the interviewer through the solution. Know how to dive deep in a few areas, but don’t spend too much time studying to become an expert. Your time is better spent practicing different problems. See how far you can get in 45 minutes. It’s actually not that long.

Want to see more examples?

👇

Get my complete playbook to crushing the System Design Interview for Technical Program Managers. Includes 6 full length problems and solution based on real questions asked by top tech companies.

Get it now!