#What the interviewer is looking for
AddedA system design interview is not a quiz with one right answer. It is a simulation of the most senior part of an engineer's job: someone hands you a vague goal ("design a photo-sharing app"), and you turn it into a design that works, at a scale you have agreed, with costs you can name. The interviewer is not waiting for you to say "Kafka". They are watching how you get from the vague goal to a defensible design.
A good mental model: the interviewer is writing a report while you talk. Every few minutes they jot down evidence: "asked about read/write ratio before choosing a database", "estimated 17 K QPS and used it to size the cache", "noticed the single point of failure on their own". At the end they turn those notes into a recommendation. Anything you think but don't say is invisible to that report. Anything you say without a reason ("I'd use Cassandra") is weak evidence; the same choice with a reason and a trade-off ("writes dominate and we only read by user id, so a wide-column store partitioned by user fits; we give up ad-hoc queries") is strong evidence.
So the round rewards the habits of a lead engineer in a design review: pin down the problem, put numbers on it, build something that works end to end, then go deep where it is hard and say what you are trading away.
The signals
Every company writes its own rubric and keeps it private, but the themes are the same everywhere. Hello Interview, a popular prep site, groups them into problem navigation, solution design, technical excellence, and communication and collaboration (checked October 2026). In plain terms:
| Signal | Strong evidence | Weak evidence |
|---|---|---|
| Scoping (problem navigation) | Asks questions whose answers change the design; writes down 3–5 core features and the numbers to design for; says what is out of scope | Starts drawing boxes in minute two; asks 15 questions that don't matter; never states the scale |
| A working design | Every agreed feature has a path through the boxes; data has a home; the design would actually run | Lots of components, but one requirement has no path (uploads go nowhere, the feed is never built) |
| Trade-offs and depth | Names at least two options for a hard part, picks one with a reason tied to the requirements, knows what breaks first | Buzzwords without reasons; "it scales horizontally" with no mechanism; can't answer "what happens when this node dies?" |
| Communication | Thinks aloud, checks in at phase boundaries, adapts when given a hint, keeps the board readable | Long silences while drawing; defends a mistake after being told; the interviewer has to drag the design out |
How the bar changes with level
The same prompt is used at several levels; what changes is how much you drive and how deep you go. This summary follows Hello Interview's write-up of expectations per level (Evan King, a former Meta staff engineer; checked October 2026):
| Level | Breadth | Depth | Who drives |
|---|---|---|---|
| Mid-level | Broad, basic knowledge; expect "what does an API gateway actually do?" for every box you draw | Textbook understanding is enough | You lead requirements, API and the high-level design; the interviewer steers the later questions |
| Senior | Fundamentals are assumed and not probed unless you show a gap | Go deep in about two places, ideally from real experience (why this partition key, what the failure looks like) | You drive, spot what makes this system hard, and point out your own design's weak spots |
| Staff and above | Assumed complete | Deep in several areas, ideally with insight the interviewer may not have | You run nearly the whole session as a peer |
For Rohit, interviewing as an experienced full-stack engineer, the senior row is the target: finish a working design early enough to spend real time on two deep dives, and raise the weaknesses before the interviewer does.
How it is scored
At most large companies each interviewer writes structured feedback (evidence per signal) and a recommendation on a scale such as strong no hire → no hire → hire → strong hire. A debrief or hiring committee reads all the rounds together, and the design round often weighs heavily in the level you are offered, not only in yes or no. Two practical consequences follow:
- Evidence beats impressions. "Candidate said the cache could serve stale feed items for up to 30 seconds and that this is acceptable because likes are eventually consistent" can be written down and defended in a debrief. "Seemed smart" cannot.
- Running out of time is the most common failure. Hello Interview's delivery guide calls failing to deliver a working system the most common reason mid-level candidates fail. A complete but plain design beats a brilliant half of one.
Both candidates end with the same boxes: load balancer, stateless API servers, Redis cache, MySQL with read replicas, S3 and a CDN. Candidate A drew them in the first eight minutes and spent the rest explaining what each box does. Candidate B spent ten minutes on requirements and estimates, then drew the same boxes, saying for each why it is there and what it costs. Who scores better, and on which signals?
Show answer
Candidate B, on every signal except perhaps speed.
- Scoping: A never established the scale or the read/write ratio, so there is no evidence A knows why this design fits. B's ten minutes produced numbers (say 17 K feed QPS, 100:1 reads to writes) that the design visibly answers.
- A working design: identical boxes, so on paper this is a tie. But B can show each feature's path through the boxes because B wrote the features down first.
- Trade-offs: A's explanations are definitions ("Redis is an in-memory store"). B's are decisions ("reads outnumber writes 100 to 1, so a cache in front of MySQL takes most of the load; we accept up to 30 s of staleness on like counts").
- Communication: B checked in at phase boundaries and tied the design to agreed requirements; A lectured.
- The lesson: the same diagram can be a weak or a strong interview. The reasons attached to the boxes are what gets scored.