I've sat on both sides of frontend system design interviews — as the candidate, and later as the person deciding whether to move someone forward. The candidates who struggle almost always make the same assumption: that there's a correct architecture they're supposed to arrive at, and the interview is testing whether they know it.
That's not what's being evaluated. There usually isn't a single correct answer. What's being evaluated is whether you can reason through tradeoffs out loud, with someone watching.
What's actually being scored
Four things, roughly in this order of importance:
- Do you clarify the problem before solving it? "Design a news feed" is not a spec. Is it real-time? How many items? Infinite scroll or pagination? Mobile-first? Candidates who start drawing boxes immediately are already behind candidates who spend two minutes asking questions.
- Can you break the problem into components with clear responsibilities? Not "which library," but which piece owns which concern — data fetching, caching, rendering, state.
- Do you understand the tradeoffs of your own choices? If you say "I'd use optimistic updates here," the follow-up is always "what happens when the request fails?" If you don't have an answer ready, it signals you reached for a pattern without understanding why.
- Do you think about the non-functional stuff unprompted? Performance on a slow connection, accessibility, error states, loading states. Most candidates only address these when asked. The strongest candidates bring them up before they're asked.
A framework that actually works under pressure
When I'm interviewing, I want to see something like this sequence, even loosely:
Clarify requirements. Scale, real-time-ness, target devices, must-have vs nice-to-have. Say the constraints out loud even if you're guessing — "I'll assume this needs to support ~10k concurrent users, tell me if that's wrong" is a strong opening.
Sketch the component tree and data flow. What owns state, what's derived, where does data enter the system (API, WebSocket, local cache) and how does it get to the UI.
Talk about the boundary cases before being asked. What happens offline. What happens when a request is slow. What happens with an empty state, or 10,000 items instead of 10.
Name the tradeoff, not just the choice. "I'd cache this client-side for speed, at the cost of potentially stale data for a few seconds — acceptable here since this isn't financial data" is a complete answer. "I'd cache this" is not.
The mistake that sinks otherwise-strong candidates
Jumping straight to code, or straight to a specific library, before the problem is even scoped. It signals pattern-matching instead of reasoning — exactly the "memorize the syntax, skip the thinking" habit that tutorials train people into and interviews are specifically designed to catch.
If you only take one thing from this: the interviewer isn't trying to catch you not knowing something. They're trying to watch you think. Slow down and let them.