InterviewLane
Back to System Design
System Design
easy
mid

Can you walk me through the high level design of your current or past frontend system?

Structure: business context → user flows → architecture (rendering, state, routing, auth) → data layer (APIs, caching, realtime) → observability → key tradeoffs → what you'd change. Talk about decisions and constraints, not features. Bring a diagram.

4 min read·~30 min to think through
Sign in to bookmark & track progress

An HLD (high-level design) walk-through is a senior interview staple. The goal: show you reason about systems, not features. Have a story prepared.

Skeleton

  1. Context (30s) — what the product does, scale, who uses it.
  2. Key user flows (1m) — the 2–3 flows that drove architecture.
  3. Architecture diagram — boxes + arrows. Draw it.
  4. Per-layer detail: rendering, state, data, auth, observability.
  5. Tradeoffs — the choices you made and the rejected alternatives.
  6. What you'd change — honest assessment.

What to include

Rendering

  • SSR / SSG / CSR / RSC split per route + why.
  • Edge vs origin rendering.
  • Hydration strategy.

State

  • Server state (React Query / SWR / RTK Query).
  • Client state (Zustand / Redux / Context).
  • URL state (filters, deep links).
  • Persistence (localStorage, IndexedDB, server).

Data layer

  • REST / GraphQL / RPC?
  • Caching strategy (HTTP + client cache).
  • Realtime (WebSocket / SSE / polling).
  • Optimistic UI patterns.

Routing

  • App router / file-based / programmatic.
  • Code splitting strategy.
  • Protected routes.

Auth

  • Provider (OAuth, custom).
  • Session storage (cookie vs token).
  • Authorization at component + API level.

Observability

  • RUM (web-vitals).
  • Error tracking (Sentry).
  • Custom analytics events.
  • Logging.

Build + deploy

  • Bundler, CI gates, preview deploys.
  • CDN, image pipeline.
  • Feature flags.

What to leave out

  • Implementation minutia ("we used useCallback here").
  • Brand-new buzzwords without justification.
  • Org politics.

Tradeoffs section

This is where seniority shows. For each major decision, state:

ts
Decision: Adopted Next.js App Router.
Why: SSR for SEO on marketing routes, RSC to ship less JS, file-based routing kept the team productive.
Tradeoff: Less mature than Pages Router at the time; some libraries weren't compatible.
Rejected: Vite + custom SSR. Faster dev, but more glue, less prerendering story.

Scale numbers

If you can: traffic (DAU/QPS), data size, perf targets (LCP, INP). Concrete numbers > "lots of users."

What you'd change

Pick 2–3 honest things:

  • "I'd move state X from Redux to React Query — it's server state."
  • "Our image pipeline still serves JPEG; we'd add AVIF."
  • "Bundle budget wasn't enforced in CI; regressions slipped in."

Shows reflection without trashing past colleagues.

Common pitfalls

  • Listing features ("we have login, profile, ...") instead of design.
  • "We just used React" — not a design.
  • Skipping tradeoffs.
  • No diagram.

Interview framing

"I'd start with the product context and the 2–3 user flows that drove design — say, an authenticated dashboard with realtime data and a public marketing surface. Then a layered diagram: rendering split (SSG marketing, SSR/RSC for SEO routes, CSR for the app), state separation (React Query for server, Zustand for client, URL for filters), data layer (REST + WebSocket for realtime, optimistic UI for sends), auth via httpOnly-cookie sessions, observability via Sentry + web-vitals. Then I'd walk through 2–3 explicit tradeoffs — choosing the App Router and what I'd give up — and end with what I'd change today. The key is reasoning, not feature list."

Follow-up questions

  • •What was the hardest tradeoff?
  • •Walk through your data fetching architecture.
  • •What would you change if you started over?

Common mistakes

  • •Feature list instead of design.
  • •No tradeoffs articulated.
  • •Buzzword soup without justification.
  • •Skipping observability.

Performance considerations

  • •Walk through perf budget, bottlenecks identified, and the wins shipped (with numbers).

Edge cases

  • •If the system is small, talk through the constraints that made it small.
  • •If you joined late, talk about what's there and what you'd change.

Real-world examples

  • •Linear's HLD blog posts, Vercel architecture talks, GitHub Universe sessions on frontend infra.

Senior engineer discussion

Senior signal: clear layering, named tradeoffs with rejected alternatives, scale numbers, and honest 'what I'd change'. Junior signal: 'we used X, Y, Z'.

Related questions