You can predict most of the question from what the company builds. Interviewers choose problems they have solved at work, because they know where the hard parts are.
A delivery company asks about matching orders to drivers. A storage company asks about keeping files in sync. The product you are interviewing for is the strongest clue you have.
This article maps twenty-two companies to the question to expect. It explains the reasoning behind each match, and lists the four decisions that appear in every round.
Why the product predicts the question
An interviewer has to grade a whole design in about forty minutes. That is much easier on a system they have built themselves.
They already know the trade-offs. They know which follow-up question separates a candidate who understands the design from one who has read a summary. So they pick a problem close to their own work.
There is a second reason. A company wants to know whether you can work on its problems. A candidate who designs a good driver matching service is easy to picture on the maps team.
The question rarely names the company. "Design a system that matches drivers to riders" is the same question as "design Uber". The brand name is removed. The problem is not.
The map, company by company
| Company | What it runs | The question to expect |
|---|---|---|
| Meta | feeds and private messaging | a social media feed |
| X | timelines with very high fan-out | a social media feed |
| a graph of people and connections | a social graph | |
| web search and indexing | a search engine | |
| Amazon | ordering and delivery infrastructure | a notification system |
| Uber | matching riders to drivers by location | a ride sharing service |
| Lyft | the same matching problem | a ride sharing service |
| DoorDash | a three-sided delivery marketplace | a food delivery system |
| Uber Eats | the same marketplace, plus maps | a food delivery system |
| Dropbox | file sync across many devices | a file storage service |
| Box | the same sync problem for companies | a file storage service |
| photo upload and viewing | a photo sharing platform | |
| image discovery at scale | a photo sharing platform | |
| Netflix | video delivery to many regions | a video streaming service |
| Crunchyroll | video delivery to many regions | a video streaming service |
| Spotify | audio streaming and recommendations | a video streaming service |
| Slack | team messages with searchable history | a messaging service |
| Booking.com | inventory that must not sell twice | a hotel booking system |
| Ticketmaster | a large sale in a very short window | a hotel booking system |
| Datadog | a very high write rate from agents | a metrics and monitoring system |
| Stripe | payments that must not run twice | a rate limiter |
| Cloudflare | delivery from servers near the user | a content delivery network |
Two entries deserve a note. Google also asks for a web crawler, because crawling is a separate system from search. Amazon also asks for a key-value store, which is closer to the storage layer its teams build.
What each family actually tests
These companies fall into five groups. Each group has one hard part, and the follow-up questions go there.
Marketplaces and delivery. The hard part is matching supply to demand while both are moving. You need to find nearby drivers quickly, which means indexing a map. You also need an order to move through its states exactly once.
Feeds and social graphs. The hard part is fan-out, which means copying one new post to many readers. You either build each feed when someone posts, or when the reader opens the app. Both answers are correct, and the interviewer wants the cost of each.
Media and file storage. The hard part is large files. You split a file into chunks so an interrupted upload can continue. You then decide what happens when the same file is uploaded twice.
Search and discovery. The hard part is an index that is expensive to build and must stay cheap to query. Crawling, indexing, and serving are three separate systems. Candidates who design them as one lose the round early.
Infrastructure products. The hard part is write volume. Every server sends measurements every few seconds, so the write path needs batching and a store built for time-ordered data.
Grokking the System Design Interview works through most of these designs in full, with the reasoning behind each decision.
What does not change between companies
The question changes. The four decisions inside it do not.
- The numbers. Users, requests per second, storage per year, and the ratio of reads to writes.
- Where the data lives. Which store, and how it is split across machines.
- What happens now, and what happens later. Anything slow moves to a background worker.
- What breaks first at ten times the traffic. Name the part, then say what you would do about it.
An interviewer at a delivery company and one at a storage company grade the same four things. Only the setting is different.
When the map is wrong
The map is a starting point, not a promise. It misses in three common cases.
The interviewer is from another team. A large company staffs interviews from a pool. A payments engineer may interview you for a maps role, and ask a payments question.
The company uses a fixed question set. Some companies standardize the round so candidates can be compared fairly. The question is then chosen for consistency, not for the product.
The round opens one level below. Many interviewers start with a small question and add constraints until it grows. "Design a URL shortener" becomes "now it serves ten million redirects per second".
How to practice with this map
Start with the question that matches your target company. Do it out loud, with a timer, before you read anyone else's solution.
Then practice the two nearest families. Someone interviewing at DoorDash should also design a ride sharing service, because the matching problem is shared.
Finish with one question from a distant family. It covers you against the interviewer from another team, and it is the cheapest insurance in the plan.
Four to six questions is enough. Beyond that you are repeating decisions you have already practiced.
Frequently asked questions
Do companies really ask about their own product? Often, but with the brand name removed. You are more likely to hear "design a system that delivers video to users in many countries" than "design Netflix". The underlying design is the same either way.
What if my target company is not on this list? Look at what the company sells, then find the closest row. A company running a marketplace will ask something shaped like ride sharing. A company selling developer tools will ask something shaped like monitoring.
Should I mention the company's real architecture? Only if you are sure it is public, and only briefly. Interviewers want your reasoning, not a summary of an engineering blog post. Naming a real design and then failing to explain why it works counts against you.
Does the question change with the level? The question often stays the same while the follow-up questions get harder. A junior candidate may only need a working design. A senior candidate is expected to name what fails and what the repair costs.
How many company-specific questions should I practice? Between four and six. Beyond that the decisions repeat, and your time is better spent practicing out loud on the ones you already chose.
Related reading
- System Design Interview Questions, Organized by Difficulty, for choosing the level to practice at
- How to Prepare for a System Design Interview in Four Weeks, for fitting these questions into a schedule
- The System Design Interview, on how the round is structured
- Study Plans, for a week-by-week order
If you need the building blocks these questions assume, Grokking System Design Fundamentals covers them in the order they are usually needed.