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:

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."