A frontend system-design interview is a collaborative modeling exercise. The strongest candidates keep the discussion anchored to users and constraints while making responsibilities, data movement, and failure behavior visible.
Start with the product contract
- Identify primary users and the critical journey.
- Clarify scale, latency, availability, offline, device, browser, accessibility, localization, and security constraints.
- Separate hard requirements from assumptions that can be revised.
- Name the quality attributes that will drive architecture decisions.
Draw responsibilities and flows
- Start with the browser surface and major product domains.
- Add data sources, edge or backend-for-frontend boundaries, storage, realtime channels, and third-party systems only when relevant.
- Label important connections with the data or event that moves across them.
- Walk through one read path, one write path, and one failure path.
Cover frontend-specific depth
- Rendering strategy and navigation
- State ownership, server state, and cache invalidation
- Network resilience, retries, idempotency, and offline behavior
- Bundle delivery, performance budgets, images, and long tasks
- Accessibility, internationalization, security boundaries, analytics, and observability
Communicate the tradeoff
- State the decision.
- Name the constraint that makes it reasonable.
- Explain the cost or failure mode it introduces.
- Describe the signal that would cause you to revisit it.
- Avoid presenting a library choice as the architecture itself.
A strong closing review
- Restate the critical path and quality attributes.
- Identify the largest remaining risk.
- Explain how you would test and observe the system.
- Offer one deliberate extension if requirements or scale change.
Primary sources
Editorial review
Product claims were checked against the current experience. Found an issue? Send a correction.