Home › Blog › Frontend system design interview: framework and example questions

Frontend system design interview: framework and example questions

A frontend system design interview asks you to architect a client application — a news feed, an autocomplete, a chat app — rather than back-end infrastructure. Interviewers expect you to cover requirements, component structure, state management, the API contract with the server, data fetching and caching, rendering strategy, performance, and accessibility. The strongest answers make explicit trade-offs, such as client versus server rendering or optimistic versus confirmed updates.

A framework for frontend design rounds

  1. Requirements: features, devices, scale of data, offline needs, accessibility.
  2. Architecture: component tree and responsibilities.
  3. Data model and the API contract with the server.
  4. State management: what is local, shared, server-cached or in the URL.
  5. Data fetching: caching, pagination, real-time updates, error states.
  6. Rendering: client, server, static or hybrid.
  7. Performance, accessibility and internationalisation.

Common questions

QuestionKey topics
Design a news feedInfinite scroll, virtualisation, caching, optimistic likes
Design an autocompleteDebouncing, request cancellation, caching, keyboard accessibility
Design a chat appWebSockets, message ordering, offline queueing
Design an image carousel or galleryLazy loading, responsive images, layout shift
Design a collaborative editor (simplified)Real-time sync, conflict handling
Design a data table with large datasetsVirtualisation, server-side sorting and filtering

State: put it in the right place

Much of the signal comes from where you put state. UI state such as an open menu stays local to its component. Server data — posts, users — belongs in a cache layer that handles fetching, deduplication and invalidation rather than being copied into a global store. Shared client state, such as the signed-in user or a theme, goes in a small global store or context. Filters and pagination often belong in the URL so links are shareable and the back button works.

Rendering strategy

Client-side rendering is simple and suits apps behind a login. Server-side rendering improves first paint and SEO for public pages. Static generation suits content that rarely changes, and incremental or hybrid approaches mix them per route. Say which you'd use for each part of the product and why — for example, server-rendering the first page of a public feed for speed and search, then fetching more on the client.

Performance

Worked example: a news feed

Requirements: an infinite feed of posts with text and images, likes and comments, on mobile and desktop web. Components: Feed (fetching and virtualised list), Post (presentation), LikeButton (optimistic update), Composer. API: GET /feed?cursor= returns posts and a next cursor; POST /posts/{id}/like. State: feed pages in a server-cache layer keyed by cursor; likes updated optimistically, rolled back with a toast on failure. Rendering: server-render the first page for speed; fetch subsequent pages on the client as a sentinel element scrolls into view. Performance: virtualised list, lazy images with fixed aspect ratios. Accessibility: semantic article elements, focus management when new posts load, a visible “new posts” button instead of auto-inserting content above the reader.

Real-time updates and offline

Many frontend design questions involve live data. Compare the options explicitly: polling is simple and works everywhere but wastes requests; long polling reduces waste; server-sent events suit one-way streams such as notifications; WebSockets suit two-way, high-frequency updates such as chat or collaborative editing. Mention reconnection with backoff, message ordering and de-duplication, and how you reconcile live updates with cached data. For offline support, describe a service worker caching the app shell, a local store such as IndexedDB for data, and a queue of pending actions replayed on reconnect, with conflict handling when the server state changed meanwhile.

Accessibility and i18n

Mention keyboard navigation, focus management, semantic HTML, ARIA only where native elements fall short, sufficient contrast and respect for reduced-motion preferences. For international products, mention right-to-left layouts, text expansion in translations and locale-aware formatting. These are often where a good answer becomes a strong one.

Practising

Pick three of the questions above and design each aloud in 40 minutes, drawing the component tree and API. A free AI interview assistant such as CoPilot Interview can run the round as a mock interview and push follow-ups like “what happens on a slow 3G connection?”. Pair with our frontend interview questions and React interview questions.

Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly. Everything else on this page applies whichever tool you use, or none.

Frequently asked questions

What is a frontend system design interview?

A round where you architect a client application — components, state, data fetching, rendering, performance and accessibility — rather than back-end infrastructure.

How is frontend system design different from backend system design?

Frontend design focuses on the client: component architecture, state management, rendering strategy and user-perceived performance. Backend design focuses on services, databases, scaling and reliability.

What performance topics should I cover?

Core Web Vitals, list virtualisation, code splitting, image optimisation, caching, and debouncing or cancelling network requests.

Do I need to write code in a frontend design round?

Usually not much; the focus is architecture and trade-offs. Some companies ask for a small component implementation as part of the round.

Practise on real interview questions

Run 145 real interview questions across 10 tracks, answer out loud and see a structured answer to compare with yours. Free, no signup.

Try a practice question