One-Page Checklist for Interviews

7 minsystem designchecklistcheatsheet

This guide is part of the FrontendAtlas frontend interview preparation roadmap, focused on interview questions, practical trade-offs, and high-signal decision patterns.

A quick mental map for any front-end system design interview. Use this to keep your answer structured under pressure.

Before you start (30–60s)

  • Clarify users: public vs internal, mobile vs desktop.
  • Clarify goals: SEO? fast first load? logged-in speed?
  • Scope v1: must-haves vs nice-to-haves.

Five-step flow (the spine)

  1. Clarify: users, use cases, non-goals.
  2. Decompose: name core components.
  3. Choose rendering/architecture: with a reason.
  4. Cross-cutting: performance, a11y, i18n, testing.
  5. Trade-offs & next steps: v1 now, scale later.

Rendering choice: quick picks

ContextLeaningWhy
Public marketing / SEOSSR / SSGFast first paint, indexable content
Internal dashboard / authCSRSimple deploy, fast iteration
Mixed static + interactiveIslands / HybridStatic shell; hydrate only what’s needed
Very large org / many teamsMicrofrontendsTeam autonomy, independent deploys

State, data flow & fetching

DecisionDefaultNotes
State splitUI local • minimal global • server cacheNormalize server data by id
FlowUnidirectionalView → Action → Store/Cache → View
FetchingOn demand + prefetchPrefetch likely next route; use cursors
RefreshBackground on focus/reconnectKeep UI responsive while refreshing

Caching & invalidation

LayerUseInvalidation
HTTP / CDNStatic assets, GET APIsTTL, purge on deploy
App memoryNormalized entitiesTag/event-based after writes
Service WorkerShell + recent data, offlineVersioned precache; sync queue

One-liner: “SWR for reads; tag-based invalidation on writes.”

Real-time & offline

  • Start simple: polling → upgrade to SSE/WebSocket if needed.
  • Offline: SW cache shell, queue writes, handle conflicts (version/merge).

Performance quick fixes (symptom → fix)

  • Page feels slow to load: optimize images, inline above-the-fold CSS, split bundles.
  • Clicks feel laggy: reduce JS, debounce handlers, move heavy work off main thread.
  • Layout jumps around: reserve dimensions for images/ads, load fonts predictably.
  • Scrolling is janky: virtualize long lists, throttle scroll, keep frames smooth.

Cross-cutting essentials

  • a11y: semantic HTML, focus order, keyboard support, contrast.
  • i18n: text expansion, RTL, locale formats (dates/numbers/currency).
  • Testing: happy paths + errors + empty states; contract tests for APIs.

Close strong (1–2 sentences)

“For v1, I’d ship X for speed. If Y becomes a priority, we’ll evolve to Z. Trade-offs: we optimize for A now, and revisit B at scale.”

Phrases that score

  • “Given the need for X, I’d pick Y because it optimizes for Z.”
  • “Must-haves for v1 are…, nice-to-haves later are…”
  • “We’ll keep UI state local, minimal global, and treat server data as a cache.”
  • “We’ll start with polling; if interaction requires it, move to SSE/WebSocket.”

Red flags to avoid

  • Jumping into diagrams without clarifying scope.
  • Listing buzzwords without a reason tied to context.
  • Designing for a billion users in v1.
  • Forgetting a11y/i18n/offline or error/empty states.
  • Rambling without structure.

Mini runbook (10–15s to say out loud)

  1. “Users & goals are …; v1 scope is …”
  2. “Components: …”
  3. “Rendering: choose … because …”
  4. “Perf/a11y/i18n considerations: …”
  5. “Trade-offs now; next steps at scale: …”