Frontend System Design Interview Guide

A repeatable structure candidates can follow in a 45–60 minute frontend system design interview. Use it as a script, checklist, and evaluation rubric.

1. Interview structure

A strong frontend system design answer is not just a whiteboard diagram. It is a sequence of decisions that moves from requirements to architecture to state, APIs, performance, safety, and operational quality.

2. RADIO answer format

R — Requirements

• Core product flows
• User types and permissions
• Scale assumptions
• Latency and correctness expectations

A — Architecture

• Main UI surfaces
• Rendering strategy
• Realtime vs request-response flows
• Boundaries between client and server responsibilities

D — Data Model

• Core entities
• Client state shape
• Normalization where relevant
• Transient state vs durable state

I — Interfaces

• Read APIs
• Mutation APIs
• Realtime events
• Error states and retries

O — Optimizations and Tradeoffs

• Render performance
• State management tradeoffs
• Caching and invalidation
• Accessibility, security, and resilience

3. State management answer

State management is important, but the strongest answer is not “I would use Zustand” or “I would use Redux.” The strongest answer is to explain what state exists, who owns it, and why that split is correct.

How to talk about state

• Local UI state: open panels, hover states, active tabs, modal visibility.
• Shared client state: filters, selection state, temporary workflow state, optimistic queues.
• Server state: fetched resources, paginated lists, mutation results, cache freshness.
• Hot interaction state: editor state, drag state, request lifecycle, composition state.

When React Query is relevant

• Feed pages and cursor pagination
• Jira board fetches and issue detail panels
• Comments history, revision history, filters, and side panels
• Optimistic mutations where server data remains central

When React Query is not the core answer

• Collaborative editor document state
• Selection, pending ops, rebasing, undo stack
• Fast per-keystroke interaction loops

When Zustand or Redux may be relevant

• Shared client-side interaction state across multiple surfaces
• Board interaction state in workflow-heavy UIs
• Complex selection, filtering, or temporary interaction state

4. API and data contracts

Good frontend system design answers define APIs precisely enough to explain pagination, optimistic updates, retries, and error handling.

• Prefer cursor pagination for unstable ranked lists.
• Use idempotency keys where retries could duplicate actions.
• Keep payloads small and explicit.
• Batch requests where possible and avoid request waterfalls.
• Design with HTTP/2 multiplexing in mind, but still reduce request count and payload size.
• Design realtime events as patches when full reloads are too expensive.

5. Performance checklist

• Focus first on above-the-fold work and first meaningful interaction.
• Virtualize long lists and grids to bound DOM and layout cost.
• Use route and component-level bundle splitting; remove dead code via tree shaking.
• Debounce and throttle high-frequency input and scroll handlers.
• Use modern image formats (WebP/AVIF) and lazy loading for offscreen media.

Network and delivery checklist

• Enable Brotli/gzip compression for text assets.
• Cache static assets aggressively at CDN edges, but avoid caching personalized HTML.
• Use stale-while-revalidate patterns where freshness can lag slightly.
• Define behavior for weak networks, high latency, and partial failures.

6. Accessibility and security

• Keyboard navigation and focus management
• Screen reader support and semantic roles
• I18n readiness (copy expansion, RTL, locale-aware formatting, pluralization)
• Mobile-first constraints (touch targets, input latency, low-memory devices)
• Offline behavior (read-only fallback, queued writes, replay strategy)
• XSS-safe rich content handling
• Permission boundaries and unsafe client trust assumptions

7. Reliability and observability

• What fails if the network drops?
• What retries safely, and what should not retry automatically?
• What metrics would reveal user pain quickly?
• Define product analytics for key funnels and regression detection.
• Plan A/B testing with feature flags, guardrails, and fast rollback.
• Cover critical paths with tests and CI/CD gates before release.
• How would you debug production divergence or bad client state?

8. Question-specific patterns

News Feed

Emphasize React Query, normalization, cursor pagination, optimistic mutations, and realtime reconciliation without reordering visible rows.

Autocomplete

Emphasize request lifecycle, cancellation, stale response protection, keyboard navigation, and IME handling more than generic global state tools.

Collaborative Docs

Emphasize editor store, pending ops, rebasing, comments anchoring, offline replay, and why React Query is only secondary here.

Jira Board

Emphasize normalized board state, optimistic drag-and-drop, workflow validation, permission boundaries, and local drag state versus server-backed board data.

9. Candidate closing script