FrontendInterviews.dev

. Frontend System Design Interview Guide (Candidate Script + Checklist + Cheatsheet)

Medium•

Create a repeatable approach a candidate can follow in a 60-minute frontend system design interview.

Goal:

  • If a candidate follows the structure, they produce a strong answer.
  • Interviewers can score consistently.
  • Covers: FR/NFR, architecture, routes, state, APIs, performance, a11y, security, reliability, observability, testing, CI/CD.
Quick Links:

A universal, staff-friendly structure for frontend system design interviews: set the contract, prioritize FR/NFR, design architecture, routes, state, APIs, then cover performance, a11y, security, reliability, observability, and testing.

Start here for the full hub: Frontend System Design Interview Questions.

HLD interview focus: Requirements, architecture, tradeoffs, data flow, and scaling decisions. Any implementation snippets shown are optional unless explicitly asked.

Say:

“Frontend system design is huge. In 60 minutes we can’t cover everything. Let’s agree on scope and depth. I’ll list functional and non-functional requirements, then propose a high-level architecture, then go deeper into routes, state, APIs, and performance/security/a11y/ops.”

  1. Functional Requirements (FR)
  2. Non-Functional Requirements (NFR)
  3. High-Level Architecture / Component HLD
  4. Page Routes + Wireframe-level screen map
  5. State Management (state variables + transitions)
  6. API Design (UI data + user action APIs)
  7. Web Performance (Network + Rendering)
  8. Accessibility (A11y)
  9. Security
  10. Reliability / Availability
  11. I18n + Mobile + Offline
  12. Observability + Analytics + A/B Testing / Feature Flags
  13. Testing + CI/CD
  14. Wrap-up: tradeoffs + next steps

Must-have:

  • Browse/list view (search/filter/sort/pagination)
  • Detail view
  • User actions (CRUD or domain actions)
  • Auth states (guest vs logged-in)

Nice-to-have:

  • Realtime updates
  • Offline support
  • Power user features
  • Advanced personalization
  • Performance: LCP/INP targets, p95 API budgets
  • Reliability: graceful degradation, retries, partial failures
  • Security: XSS/CSRF/CORS/CSP, input validation
  • A11y: keyboard navigation, semantics, ARIA labels, contrast
  • Scalability: expected scale + growth
  • Observability: logs/metrics/traces + error tracking
  • Privacy/compliance constraints
  • Maintainability: modularity, typed contracts, tests

System architecture includes: client (UI+state+caching), BFF/API gateway, services/data stores, CDN/caching layers, observability.

Component HLD includes: AppShell, pages, shared components, data layer (React Query/SWR), shared UI patterns.

Staff signal: separate URL state vs server state vs local UI state.

If it’s shareable/bookmarkable and affects fetching → put it in the URL:

  • search query, filters, sort, pagination, selected tab

Pick SSR/ISR/CSR based on SEO, personalization, freshness, auth.

List page:

  • Items: id, title, subtitle, status, updatedAt, permissions
  • Pagination: cursor/nextCursor/totalCount
  • Filter options and metadata

Detail page:

  • Full entity fields + related entities
  • Permission flags

Staff signal: frontend-friendly payloads to avoid waterfalls.

Read APIs: list endpoint (filter/sort/pagination), detail endpoint, user/session, metadata.

Write APIs: define optimistic update plan, rollback UX, idempotency if needed.

Error contract: consistent codes + fieldErrors.

Concurrency: ETags/versioning and 409 conflict handling UX.

Four buckets:

1) URL state

2) Server state (React Query/SWR)

3) Local UI state (modals, drafts, selection)

4) Global UI state (toasts, theme, flags)

Call out 3–5 critical transitions (filter change, create optimistic, auth change).

Network:

  • Compression (Brotli/gzip)
  • CDN caching for static assets; avoid caching personalized HTML
  • Batch requests; avoid waterfalls
  • HTTP/2 awareness
  • SWR caching
  • Image optimization (WebP/AVIF, loading="lazy")

Rendering:

  • Virtualization
  • Above-the-fold focus
  • Bundle splitting
  • Tree shaking
  • Debounce/throttle

A11y: semantic tags, keyboard navigation, focus management, contrast, ARIA labels.

Security: XSS protection, CSP, CORS allowlist, CSRF tokens + SameSite cookies, rate limiting.

Reliability: partial failures, retries, offline baseline.

Ops: observability, analytics, feature flags, testing (unit/integration/e2e), CI/CD.

Key Takeaways

  • ✓Start with timeboxing and scope agreement.
  • ✓FR/NFR first, then architecture, then routes/state/APIs.
  • ✓Always include performance (network+render), a11y, security, reliability, and ops.
  • ✓Make state separation explicit (URL/server/local/global).
  • ✓End with tradeoffs + next steps.
Previous
Frontend System Design Interview Questions (Hub)
Complete & Next
News Feed (e.g. Instagram)