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
Use these primary references to verify the technical models behind this guide.
Editorial reviewProduct claims were checked against the current experience. Technical references use primary documentation where the guide depends on platform or framework behavior. Found an issue? Send a correction.
Turn the guide into a retry
Choose one section, practice it under interview conditions, review the evidence, and repeat the same skill with a new prompt. Improvement becomes reliable when it survives a different context.
Start a mock interview