What They Check and How to Structure Your Answer

How this interview differs from algorithms

An algorithms problem has a right answer: the code either passes the tests or it doesn't. In System Design there is no single right answer. Ask ten strong engineers to "design Twitter" and you'll get ten different diagrams — and all ten could get an offer.

Imagine you're an architect, and a client says, "Build me a house." A bad architect immediately sketches a three-story mansion with a pool. A good one asks first: how many people will live there? What's the budget? What's the climate? A home for a family of three in Miami and a dorm for 500 students in Fairbanks, Alaska are completely different projects.

In the interview, you're that architect. The interviewer isn't looking for a "pretty picture"; they're looking at how you think.

What they check	What it looks like in practice
Clarifying the problem	You ask questions instead of rushing to draw
Working with numbers	You estimate load and data volume
Trade-offs	"We could do it this way or that way; I'll pick X because…"
Structure	You move step by step instead of jumping around
Communication	You think out loud and pick up on hints

The key word of the whole interview is trade-off. Every decision gives you something and costs you something. If you name the price of your choice, you already sound senior.

A 45-minute answer framework

The main secret: you need a plan you repeat on every problem. Then even an unfamiliar topic won't throw you off.

Step	Time	What you do
1. Requirements	5–7 min	Functional and non-functional
2. Load estimate	3–5 min	RPS, data volume, peaks
3. API	3–5 min	Key endpoints
4. Data model	3–5 min	Entities, relationships, choice of database
5. High-level design	5–7 min	A simple architecture that works
6. Bottlenecks	10–15 min	Dig into where it hurts
7. Scale and failures	5 min	What breaks and how we survive it

Let's walk through the steps.

1. Requirements

Functional requirements describe what the system does: "a user publishes a post", "sees a feed from friends". Non-functional requirements describe what it has to be like: how many users, acceptable latency, what matters more — availability or strong consistency.

How it sounds: "Let me pin down the scope. Do we need likes and comments, or are we focusing on posting and the feed? How many daily active users do we have? Is it okay if a post shows up for friends a couple of seconds late?"

2. Load estimate

You don't need precision here, you need the order of magnitude. An example calculation:

Parameter	Calculation	Result
Daily active users (DAU)	given	10M
Requests per user	~20 a day	200M/day
Average RPS	200M / 86,400 s	≈ 2,300
Peak RPS	× 3	≈ 7,000

How it sounds: "About 7,000 RPS at peak. A single server with a database won't handle that, so we'll need horizontal scaling and a cache." See how the number instantly turns into an architecture decision? That's the whole reason to compute it.

3–4. API and data model

Sketch 2–3 main endpoints, no more:

POST /posts          {"text": "..."}
GET  /feed?cursor=abc

Then name the core entities (User, Post, Follow) and explain your choice of storage: "Relationships between users are relational, so I'll start with PostgreSQL."

5. High-level design: start simple

First, draw the simplest system that works:

This isn't naivety; it's a deliberate move. You show that you understand the core, and you get a baseline you can improve.

6–7. Bottlenecks, scale, failures

Now you remember your 7,000 RPS and ask yourself: where will it hurt? A single server becomes a bottleneck, and the database drowns in reads. The design evolves:

Always pair every new box with a trade-off: "The cache takes load off the database, but we risk serving stale data. For a feed, that's acceptable." Reason about failures like this: "If one API server goes down, the load balancer sends traffic to the other. If the primary database goes down, we fail over to a replica, but we lose the last few seconds of writes."

The interviewer will often hint where to dig: "What happens with really popular users?" That's not a trap, it's an invitation. Grab the hint.

Common mistakes

• Jumping straight to microservices, Kafka and Kubernetes. It looks like an attempt to impress rather than solve the problem. Add complexity only when the numbers justify it.
• Not asking about load. Without numbers, every decision hangs in the air: you can't explain why you need sharding or why a single database is enough.
• Going silent. The most expensive mistake. The interviewer can't read your mind: silence counts as "doesn't know". Say even your doubts out loud: "I see two options here, let me weigh them…"
• Drowning in one detail. Spending 20 minutes on indexes and never getting to the high-level design. Keep an eye on the clock using the framework.
• Naming a solution without its price. "I'll use NoSQL" is weak. "I'll use NoSQL for horizontal scaling, but give up complex JOINs" is strong.

The takeaway

You now have a skeleton that fits any problem: requirements → numbers → API → data → simple design → bottlenecks → failures. You don't have to know everything in the world. You need to run the conversation with structure, think out loud and name your trade-offs honestly. That's exactly what the next lessons of this course are about.