What to expect in a system design interview

Most prompts are intentionally underspecified. "Design Instagram", "design a rate limiter", and "design Ticketmaster" are not complete product specs. The missing details are part of the interview.

The interviewer is watching how you create structure. Do you ask the right questions? Do you identify the hard part of the problem? Do you make reasonable assumptions? Do you explain tradeoffs clearly?

There is usually no single correct answer. A strong design is not the fanciest architecture. It is a design that matches the agreed requirements and makes its tradeoffs obvious.

Coding interviews usually converge toward a known solution. System design interviews do not. You are building a design in front of another engineer, and the conversation matters as much as the diagram.

Expect interruption. That is normal. The interviewer may push you toward scale, consistency, latency, reliability, or product behavior. Treat those prompts as signal, not as attacks.

The best mental model is a design review. You propose. They probe. You adjust. Your job is to keep the room oriented while the system gets more detailed.

Most rubrics boil down to four signals.

Problem navigation: can you turn a broad prompt into a focused scope?

Design fundamentals: can you define APIs, data, services, storage, async work, and request flows that fit the problem?

Depth: can you explain bottlenecks, failure modes, consistency, latency, and scaling choices when asked?

Collaboration: can you work with the interviewer, take hints, and communicate assumptions without sounding hand-wavy?

A candidate can know a lot of technologies and still fail if the design feels unstructured. A candidate can pass with a simple design if the reasoning is crisp.

Most interviews follow a predictable arc.

First, clarify scope. Ask what users can do, what scale matters, and which quality matters most: latency, consistency, availability, durability, cost, or speed of iteration.

Second, define the core data and APIs. This keeps the design grounded. If you cannot name the entities and operations, your architecture will drift.

Third, draw the high-level design. Start with the simplest working system. Show write paths and read paths. Add caches, queues, indexes, or CDNs only when they solve a requirement.

Finally, go deep. The interviewer will usually steer you toward the real challenge: contention, fanout, ranking, storage, failure recovery, consistency, or scale.

The strongest candidates sound like people you would trust in a real design meeting.

They say things like: "I am assuming reads are much more frequent than writes", "I would keep payments strongly consistent", and "I am going to park recommendations unless you want to include them."

That style does two things. It makes the design easier to follow, and it gives the interviewer chances to correct scope early.

Weak candidates often perform at the interviewer. Strong candidates collaborate with them.

Mid-level candidates usually need a complete, reasonable design. Clarify the problem, draw the main components, and understand the common building blocks.

Senior candidates need judgment. Move through the basics quickly, then spend time on tradeoffs, bottlenecks, failure modes, and operational reality.

Staff-level candidates need to lead the conversation. The interviewer is looking for framing, prioritization, crisp communication, and decisions that would hold up in a messy production system.