Interviews
System design interview questions, worked through
Each problem starts the way a real interview does: clarify the scope, size it, sketch it, then go deep where it is hard. Play the diagram to watch a request move through the design.
On this page
How to answer a system design question in 6 steps
- Clarify the scope. Ask who uses it, what they do most and what can be left out. Write the answers where the interviewer can see them.
- Size it. Turn users into requests per second, storage per year and bandwidth. Round hard: the order of magnitude is what shapes the design.
- Sketch the path of one request. Draw the client, the entry point, the services and where data lives, then walk one read and one write through it.
- Go deep on the hard part. Most problems have one or two: unique IDs, fan-out to followers, keeping two copies in step. Spend most of your time there.
- Name the trade-offs. For each big choice, say what you gave up and when you would choose the other way.
- Say what breaks next. Close with what fails first at ten times the load and how you would see it coming.
Problems, from the basics to the hard ones
Practice with feedback
Open any problem in Interview prep, answer in your own words and get a score with what to fix. Or have Resumely write new system design questions for the role you are applying to.
Common questions about system design interviews
How should I split a 45-minute system design interview?
A workable split is about 5 minutes to clarify, 5 to estimate, 15 for the high-level design and the rest for one or two deep dives and the interviewer's questions. Adjust when the interviewer steers you.
Do I need to know specific tools like Kafka or Redis?
Know what each kind of part does: a queue, a cache, a key-value store, a search index. Naming a tool helps only when you can say why it fits; the interviewer is listening for the reasoning.
How exact do the estimates need to be?
Within a factor of ten is fine. Round to easy numbers, say your assumptions out loud and use the result to make a decision, such as whether the data fits on one machine.
Which problem should I start with?
Start with a Foundation problem such as the URL shortener or the rate limiter: they cover IDs, caching and storage in a small space. Then take one Intermediate and one Advanced problem close to the work of the company you are interviewing with.