Free lesson · Frontend System Design

You think you know what this round is. You probably don't.

Easy10 min readfrontendsystem-design

Here's the assumption almost everyone walks in with: a frontend system design round is a backend system design round with React bolted on top. You'll draw some boxes, mention a load balancer, sketch a database, and then - because it's "frontend" - you'll add a little client box on the left and call it a day.

Sit with that assumption, because it's the single fastest way to get a "no hire" from someone who designs interfaces for a living.

I came into my first one believing something slightly different but equally wrong. Because I'm self-taught, I assumed the round was a test of API knowledge - did I know what IntersectionObserver was, could I explain the event loop, did I know the difference between localStorage and a cookie. I'd memorized a pile of trivia. I sat down, the interviewer said "design a news feed," and I started listing browser APIs like I was reading a glossary. Twenty minutes in, she stopped me and asked, gently, "Okay - but how does the feed behave when the user is on the subway and the network drops mid-scroll?" I had no framework for that question. I knew every API I'd need to answer it. I just didn't know that that was the question being asked.

That gap - between knowing the pieces and knowing which decision the pieces are in service of - is the entire round. Let me make it concrete.

What a backend round optimizes for, and what a frontend round optimizes for

A backend system design round is, at its heart, about handling scale on infrastructure you control. You own the servers. You own the database. You decide the replication strategy, the sharding key, the queue. The adversary is load - millions of requests, terabytes of data, the thundering herd. Your job is throughput, consistency, and availability across machines you provision and can reason about deterministically.

A frontend system design round inverts almost every one of those assumptions. You are designing for a single user on a device and network you do not control and cannot predict. There is no "scale to a million requests" - there is one person, on one device, which might be a flagship phone on office WiFi or a four-year-old Android on a 3G connection in a moving train. The adversary is not load. The adversary is variance and constraint: network variance, device variance, the 16-millisecond budget you have to render a frame before the user perceives jank, the fact that your JavaScript bundle has to travel across the world before a single pixel appears.

Here is the difference stated as plainly as I can:

Notice the row I want you to stare at: what "correct" means. On the backend, correctness is usually binary - the transaction committed or it didn't, the query returned the right rows or it didn't. On the frontend, "correct" is a spectrum of experience. A feed that loads in 400ms and a feed that loads in 4 seconds both technically "work." One gets you hired and one doesn't, and the difference is entirely in the decisions you made about perceived performance - skeleton screens, optimistic updates, prefetching, where you put the loading boundary.

graph LR
    subgraph Backend["Backend SD: you control this"]
        LB[Load Balancer] --> S1[Server]
        LB --> S2[Server]
        S1 --> DB[(Database)]
        S2 --> DB
    end
    subgraph Network["The gap you DON'T control"]
        N[Variable network<br/>50ms to 4000ms]
    end
    subgraph Frontend["Frontend SD: you design for this"]
        Device[One device<br/>unknown CPU/RAM] --> Render[16ms frame budget]
        Render --> UX[Perceived performance<br/>+ accessibility]
    end
    Backend --> Network
    Network --> Frontend

This diagram shows three zones. On the left, the backend zone, with a load balancer feeding two servers that share a database - everything you control as a backend engineer. In the middle, the network gap, labeled as variable, ranging from fifty milliseconds to four thousand milliseconds, which you do not control. On the right, the frontend zone: a single device with unknown CPU and memory, constrained by a sixteen-millisecond frame budget, where your real job is perceived performance and accessibility. The arrow flows left to right, showing that the frontend engineer inherits everything after the uncontrollable network gap.

Important: The line that separates a backend round from a frontend round is the network boundary. Everything after the response leaves the server - the journey across an unpredictable network, the parse, the render, the interaction - is your domain. If your answer never crosses that line, you're answering the wrong question.

So what is actually being evaluated?

Interviewers are not scoring you on whether you can recite the WebSocket handshake. They're scoring four things, and if you know what they are, you can deliberately demonstrate each one.

1. Breadth: do you consider the things a senior frontend engineer considers?

When a strong candidate hears "design an image gallery," their mental checklist fires automatically: How do images load - lazily? What's the placeholder strategy? How big is the bundle? Is it accessible to a screen reader? What happens on a slow connection? How does state survive a refresh? A weaker candidate hears "image gallery" and thinks only about the grid layout.

Breadth is the surface area of considerations you bring unprompted. You don't need to go deep on all of them - you need to name them, so the interviewer knows you'd catch them in real work.

2. Depth: can you go two or three levels down on at least one thing?

Breadth without depth reads as shallow - like you've memorized a checklist but never shipped anything. So you pick one or two areas and you go deep. If you mention caching, don't just say "I'd cache the results." Say: "I'd cache by query string in an in-memory LRU on the client, evict after the user clears the input, and fall through to the HTTP cache for the static assets - and I'd be careful that stale suggestions don't outlive a logout." That's depth. That's the sound of someone who's been burned by a stale-cache bug at 2am.

3. Communication: are you reasoning out loud, or performing a memorized answer?

This is the one self-taught engineers, including me, tend to underrate. The interviewer cannot see your thinking. If you go quiet and draw for ninety seconds, they have no idea whether you're being brilliant or stuck. The round is fundamentally a collaboration simulation - they're asking "what would it be like to design something with this person?" Narrate the tradeoff. Say "I'm choosing X over Y because..." out loud, every time.

4. Tradeoff reasoning: do you understand that every choice has a cost?

There are no free wins in frontend system design. Server-side rendering improves first paint but costs you server complexity and time-to-interactive. Aggressive caching improves speed but risks staleness. Prefetching improves perceived speed but wastes bandwidth and battery. The senior signal is not picking the "right" option - it's naming what each option costs and choosing deliberately for the stated requirements.

mindmap
  root((What's<br/>evaluated))
    Breadth
      Unprompted checklist
      Surface area of concerns
    Depth
      Two or three levels down
      Real production scars
    Communication
      Reasoning out loud
      Collaboration signal
    Tradeoff reasoning
      Every choice has a cost
      Choosing deliberately

This is a mind map with a central node labeled "What's evaluated," branching into four areas. Breadth, which covers your unprompted checklist and the surface area of concerns you raise. Depth, meaning going two or three levels down and showing real production scars. Communication, which is reasoning out loud and signaling that you'd be a good collaborator. And tradeoff reasoning, the understanding that every choice has a cost and that you choose deliberately for the requirements.

The trap of "just build the component"

There's an opposite failure mode worth naming, because it catches strong coders. Some candidates hear "design autocomplete" and immediately start writing a React component. They get a working typeahead in fifteen minutes. And they still get dinged - because a system design round is not a coding round. The interviewer wanted to hear you reason about debouncing strategy, request cancellation, cache invalidation, accessibility for keyboard and screen-reader users, and what happens when two responses arrive out of order. The component is the least interesting part. If you jump straight to code, you've skipped the entire thing being measured.

Warning: Writing working code quickly is not the goal in a system design round. It can actively hurt you, because it signals you skipped requirements, architecture, and tradeoffs to get to the part you're comfortable with. There's a separate round - the machine-coding / LLD round - where the code is the deliverable. Know which room you're in.

This is exactly why frontend interviewing splits into two distinct round types, and conflating them is one of the most common reasons capable engineers underperform:

We'll spend whole modules on each. For now, the only thing you need internalized: the question's phrasing tells you which game you're playing, and the games reward opposite instincts.

Why this round exists at all

It's worth understanding the interviewer's actual motivation, because it changes how you answer. A company doesn't run this round to find out if you've read the right blog posts. They run it because, on the job, you will constantly face ambiguous, under-specified problems - "make the dashboard faster," "users say search is broken on mobile" - and they need to know how you decompose those. The round is a compressed, 45-minute simulation of that decomposition. Every artifact you produce - the clarifying questions, the architecture sketch, the tradeoff you name - is evidence about how you'd behave on the team.

That reframe matters because it tells you what to optimize. You are not optimizing for the most clever architecture. You are optimizing to look like someone who would be safe and productive to hand an ambiguous problem to. That person asks before assuming. That person names what they're not covering. That person says the cost out loud.

Interview: Open every frontend system design round by establishing which round it is and what the constraints are, out loud: "Before I design anything, I want to confirm - is this a high-level architecture discussion, or do you want me to build a working component? And who's the user - are we optimizing for a global audience on variable networks, or a specific platform?" Two sentences. They instantly mark you as someone who's done this for real, because real frontend work never starts without those answers.

The same prompt, two rounds: "design search"

The fastest way to feel the difference is to take one word - "search" - and watch how a backend round and a frontend round pull it in opposite directions.

In a backend round, "design search" becomes a question about indexes and scale. How do you build an inverted index? How do you shard it across machines? How do you rank results, handle a billion documents, keep query latency under 100ms at the server, replicate for availability? The user is an abstraction - a query string arriving at your service. The whole problem lives on infrastructure you own.

In a frontend round, the exact same words become a question about the experience of typing. How do suggestions appear as you type without hammering the server on every keystroke? What happens when a slow response for an old query arrives after a fast response for a new one? How does a screen-reader user know results appeared? What shows while results load - a spinner, a skeleton, the previous results dimmed? How does the result list behave when it's 10,000 items long on a low-end phone? The server's inverted index is someone else's problem - you consume an endpoint. Your problem starts the moment the response crosses the network and has to become a usable, fast-feeling, accessible interface.

Same two words. Two completely different rounds, because the adversary is different - load on one side, variance and constraint on the other. If you walk into the frontend version and start talking about sharding the index, you've answered the backend question in the frontend room, and the interviewer's note will read "didn't understand what we were asking."

Note: This is also why "full-stack" candidates sometimes underperform in a pure frontend round despite being strong engineers: their instinct pulls toward the server, where they're comfortable, and away from the perceived-performance and accessibility decisions the round is actually probing. Knowing which room you're in lets you consciously steer toward the right adversary.

What you should carry out of this lesson

The thing I wish someone had told me before my first round: this is not a knowledge test. You can know every browser API on earth and fail it, and you can be fuzzy on the exact IntersectionObserver signature and pass it - as long as you reason like someone who designs interfaces under real constraints. The round measures judgment, demonstrated through breadth, depth, communication, and tradeoffs, on a problem where the network is hostile, the device is unknown, and "correct" means the experience stays good when conditions get bad.

Knowing what's measured is half the battle. The other half is having a repeatable way to demonstrate it under time pressure, so you don't freeze the way I did when she asked about the subway. That repeatable way has a name, and it's the next lesson: a framework called RADIO, plus one addition of my own that turns the gaps in your knowledge from a liability into a senior signal.

Back to Frontend System Design