My dashboardSign in

Frontend system design interview

Six weeks from how a browser paints a page to designing a feed, a chat or a collaborative editor that stays fast.

Start with week 1Open the Frontend board

The interview

You design the client of a real product, such as a news feed, a photo grid, a chat or an editor: its components, its data and state, how it talks to the server, and how it stays fast, accessible and secure.

Your route

6 weeks, 6 phases

The 45 minutes

A way to spend the time that leaves room for the part that’s hard. Practise against it until it feels natural.

  1. 0–5 minRequirementsUsers, devices, networks, and which features are in scope.
  2. 5–15 minArchitectureThe components, who owns which state, and how data flows.
  3. 15–22 minData modelClient-side entities, caches and what is derived.
  4. 22–30 minAPIWhat the client asks the server for, and in what shape.
  5. 30–42 minOptimizationsPerformance, accessibility, i18n and security, for this product.
  6. 42–45 minWrap-upWhat you’d measure, and what comes next.

What interviewers listen for

  1. 01User firstYou start from the people using it: their device, their network, their needs.
  2. 02BoundariesComponents have clear jobs, and every piece of state has one owner.
  3. 03PerformanceYou set a budget and say what you’d measure to keep it.
  4. 04AccessibilityKeyboard, screen readers and other languages come up without prompting.

Week by week

  1. Week 1

    How browsers work

    Know what happens between a byte arriving and a pixel changing.

    You’ll be able to explain

    • The rendering pipeline
    • Layout and positioning
    • The DOM, and why virtual DOMs exist
    • Where application state should live

    PractiseOpen the performance panel on a site you use daily and explain one long frame.

    Check yourselfWhy can changing one CSS property be cheap and another expensive?

  2. Week 2

    Talking to servers

    Choose how the client and server exchange data, and why.

    You’ll be able to explain

    • HTTP, WebSockets, SSE and polling
    • REST, GraphQL and RPC styles
    • Formats and their costs
    • Fetching, caching and keeping data fresh

    PractiseDesign the API for a comment thread twice, once REST and once GraphQL. Compare the requests a page load makes.

    Check yourselfWhen would you pick server-sent events over WebSockets?

  3. Week 3

    Architecture

    Structure an app so it can grow without slowing the team down.

    You’ll be able to explain

    • Single-page versus multi-page apps
    • Component boundaries
    • Micro-frontends and when they pay off

    PractiseSketch the component tree of a product page and mark which component owns each piece of state.

    Check yourselfWhat would make you split this app into micro-frontends, and what would it cost?

  4. Week 4

    The quality bar

    Treat performance, accessibility, languages and security as requirements, not extras.

    You’ll be able to explain

    • Core performance metrics
    • Accessible patterns for custom widgets
    • Right-to-left text and plurals
    • Authentication, tokens and content security

    PractiseUse a product you like with only the keyboard for ten minutes. Write down every place you got stuck.

    Check yourselfWhere should a session token live in the browser, and what attacks does that choice invite?

  5. Week 5

    Performance in depth

    Keep long lists, heavy media and slow networks fast.

    You’ll be able to explain

    • Network and loading strategies
    • Rendering long lists
    • Images and video
    • Infinite scroll or pagination

    PractiseBudget a feed page: how many kilobytes and milliseconds each part may use on a mid-range phone.

    Check yourselfYour feed stutters after 500 posts. What do you check first?

  6. Week 6

    Product designs and mocks

    Run the full interview on the products that come up most.

    You’ll be able to explain

    • A repeatable order: requirements, architecture, data, API, optimizations
    • Choosing the optimizations that matter for this product

    PractiseTwo timed mock interviews, one feed and one real-time product. Score yourself against the four signals.

    Check yourselfWhich optimization did you spend the most time on, and was it the one this product needed?

Common pitfalls

  • Designing the backend instead of the client.
  • Global state for everything.
  • Leaving accessibility until someone asks.
  • Optimizations with no number to justify them.
  • Ignoring slow networks and low-end phones.