A framework for frontend design rounds
- Requirements: features, devices, scale of data, offline needs, accessibility.
- Architecture: component tree and responsibilities.
- Data model and the API contract with the server.
- State management: what is local, shared, server-cached or in the URL.
- Data fetching: caching, pagination, real-time updates, error states.
- Rendering: client, server, static or hybrid.
- Performance, accessibility and internationalisation.
Common questions
| Question | Key topics |
|---|---|
| Design a news feed | Infinite scroll, virtualisation, caching, optimistic likes |
| Design an autocomplete | Debouncing, request cancellation, caching, keyboard accessibility |
| Design a chat app | WebSockets, message ordering, offline queueing |
| Design an image carousel or gallery | Lazy loading, responsive images, layout shift |
| Design a collaborative editor (simplified) | Real-time sync, conflict handling |
| Design a data table with large datasets | Virtualisation, 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
- Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift are the metrics to name.
- Virtualise long lists so only visible rows are in the DOM.
- Code-split by route and lazy-load heavy components.
- Optimise images: responsive sizes, modern formats, explicit dimensions to prevent layout shift.
- Debounce and cancel requests in search inputs; cache recent results.
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