System Design Interview: A Process That Survives an Open Prompt
System design interviews are conversations, not architecture drawing contests. The strongest candidates clarify the problem, make assumptions visible, and adjust the design as constraints change.
Quick answer
Start with the outcome you need
You are looking for a clear system design process that works across common interview prompts instead of memorizing one ideal architecture.
What to remember
The prompt is vague on purpose
Design a system for sharing short videos is not missing information by accident. The vagueness is the test. What you choose to pin down first, and what you are willing to declare out of scope, is most of your score.
Candidates who start drawing immediately are answering a question nobody asked. Candidates who ask three sharp scoping questions have already demonstrated the behaviour the round exists to measure.
Scope, then estimate, then design
Scope: who uses this, what are the two or three operations that matter, and what is explicitly excluded. Say the exclusions out loud so the interviewer can redirect you if they disagree.
Estimate: daily active users, requests per second, read to write ratio, storage growth per year. Rough is fine and the arithmetic can be loose. The point is that the numbers determine the design, and a design with no numbers under it is a diagram rather than an argument.
Only then design, and let the estimate drive it. A read to write ratio of a thousand to one makes the caching conversation the interesting one. Heavy writes make storage and partitioning the interesting one. Saying that out loud shows the design came from somewhere.
Commit to a decision and name what it costs
The most common failure at mid level is refusing to choose. Listing three databases with their trade-offs and moving on reads as knowledge without judgment.
Choose one. State the property that made you choose it, the cost you are accepting, and the condition that would change your mind. That last part is what separates a defensible decision from a preference.
When the interviewer pushes back, do not fold immediately and do not dig in. Ask what they are optimising for, and adjust if the new constraint warrants it. Handling pushback well is often scored more heavily than the original choice.
Finish by naming the next bottleneck
Strong candidates close by saying where this design breaks next. At ten times the traffic, the single write path becomes the limit. This one line demonstrates you understand your own design has a boundary.
Cover the operational reality briefly: what you would monitor, what failure looks like to a user, how you would roll out a change safely. These are rarely asked directly and almost always noticed.
If you ran out of time on a component, say which one and how you would approach it. An acknowledged gap is much better than a component quietly skipped.
Practice checklist
- 01Practise three scoping questions before any design discussion.
- 02Do the estimate out loud, and state what it implies for the design.
- 03Take one explicit position and name the cost you are accepting.
- 04Prepare a condition that would make you choose differently.
- 05End every practice answer by naming the next bottleneck.
- 06Rehearse being pushed back on: ask what they are optimising for.
Questions to practice aloud
Which requirement has the greatest impact on the architecture?
What is the expected read-to-write ratio?
Where can the system tolerate eventual consistency?
How would the design evolve at ten times the traffic?
Frequently asked questions
How much detail is expected in the estimate?+
Enough to shape the design. Rough orders of magnitude for traffic, read-write ratio, and storage growth are sufficient. Precision is not the point; letting the numbers drive a decision is.
What if I do not know the internals of a component I need?+
Say what you need it to guarantee and what you would verify before relying on it. Interviewers accept a bounded gap stated clearly. Confident invention fails at the first specific follow-up.
Should I draw a diagram?+
After scoping, yes, and keep it simple. The diagram supports the argument rather than replacing it. Time spent making it complete is usually time taken from explaining why it looks that way.