How to Approach a Frontend System Design Interview

Every lesson so far in this course has covered a specific piece of frontend system design knowledge — rendering strategies, state management, performance, architecture at scale, design systems. A "design X" interview prompt tests something different and additional: whether you can apply that knowledge live, to an underspecified problem, in a way that demonstrates reasoning rather than recitation. This lesson is the framework; the next three apply it to specific, real prompts.

Why the prompt is deliberately vague

"Design a Twitter-like feed" is not a spec — it's an invitation to ask questions, and part of what's being evaluated is whether you notice that. Jumping straight to "I'd use SSR with ISR and virtualize the list" without first establishing what "good" means for this specific product risks solving a problem the interviewer never actually posed. A senior engineer's first instinct in an ambiguous real-world request is rarely "start building" — it's "what are we actually optimizing for here," and an interview is testing whether that instinct is real or performative.

A repeatable structure

1. Step 1

   Clarify requirements

   Scale (thousands or hundreds of millions of users?), update frequency (does content change in real time?), and who the audience is (logged-in only? public and indexed?).

2. Step 2

   State the constraints that follow

   From the answers above: e.g. 'high write volume plus real-time expectations' or 'mostly-read, SEO-sensitive, infrequently-changing' — translate requirements into the actual technical pressures they create.

3. Step 3

   Propose an approach, naming trade-offs explicitly

   Not just what you'd do, but what you're giving up to get it — speed vs. cost, freshness vs. simplicity, flexibility vs. consistency.

4. Step 4

   Identify what you're deliberately NOT optimizing for, and why

   A strong answer names the corners being cut on purpose — e.g. 'I'm not solving offline support here because it wasn't a stated requirement' — rather than silently ignoring them.

5. Step 5

   Invite pushback

   State assumptions out loud so the interviewer can redirect if a requirement you guessed at was wrong — this is a conversation, not a monologue.

Questions worth actually asking

Concrete, not generic: What scale? (A feed for a startup's 10,000 users and a feed for a platform with hundreds of millions have genuinely different right answers — the second can justify infrastructure complexity the first can't.) How fresh does this need to be? (Does new content need to appear in real time, or is "eventually, within a few seconds" fine?) Who's the audience, and does SEO matter? (A logged-in-only dashboard has different rendering-strategy pressures than a public, crawlable feed.) What's the device/network profile of real users? (A performance budget for a primarily-mobile, emerging-market audience looks different from one for a primarily-desktop, enterprise audience.)

Why naming trade-offs beats naming conclusions

The weakest version of an answer states a conclusion: "I'd use SSR." The strong version states the trade-off that conclusion represents: "I'd use SSR here because this content needs to be indexed and the audience skews mobile on average connections, which makes fast, real first-content matter more than the added server infrastructure cost — though if this were a logged-in-only dashboard instead, I'd lean CSR." The second version demonstrates the actual reasoning process this whole course has been building toward, and it's what transfers to a follow-up question the interviewer asks that wasn't in your prepared answer.

"It depends" is a correct answer, said correctly

Frontend system design has few universally correct answers, and an interviewer asking a follow-up like "what if this needed to support offline use?" is often specifically testing whether you can adapt your reasoning rather than defend your first answer as the only one. "It depends" said with nothing else attached is a weak non-answer. "It depends on X — if X is true, I'd reconsider toward Y, because Z" is the strongest possible answer, because it shows you know exactly which variables the decision actually hinges on, rather than having memorized one fixed "correct" architecture regardless of context.

What to remember

• Treat an ambiguous "design X" prompt as an invitation to clarify requirements first — scale, freshness, audience — not a cue to start proposing a solution immediately.
• Translate requirements into the technical pressures they create before proposing an architecture, so the proposal is visibly grounded in the stated constraints.
• Name trade-offs explicitly ("this costs us Y to get X") rather than stating conclusions alone — the reasoning is the actual signal being evaluated.
• "It depends" is a strong answer exactly when you name the specific conditions the decision hinges on — it's a weak one when it's used to avoid committing to any reasoning at all.