Lead Frontend Developer — Hard-Level Engineering & Interview Guide

Foreword

This guide is built for interviewing — and being — a Lead Frontend Engineer at the bar of companies like Anthropic, Facebook (Meta), Airbnb, Uber, Stripe, Vercel, and ThoughtWorks. It is intentionally harder than the average React-interview cheat sheet: it expects the candidate has shipped at scale, has opinions backed by production scars, and can reason from first principles.

The guide follows the natural arc of a frontend system from zero to production — each section covers decisions, trade-offs, hard questions, model answers, and deep-dive references. Use the navigation on the left; use the search box to jump fast. Every coloured reference link goes to canonical documentation (MDN, web.dev, React docs, Next.js docs, RFCs, engineering blogs).

01Project Inception — From Zero to Plan (Deep Dive)

The first 2–4 weeks of a frontend project determine the next 2 years. A Lead is judged less on writing code than on asking the right questions before any code is written. This section is the full curriculum for becoming exceptional at inception — read it in order, do the exercises, then re-read it before any project kickoff.

# <Project Name> — Engineering Brief
Owner: <name>  ·  Status: Draft / Approved  ·  Last updated: <date>

## 1. TL;DR (3 sentences max)
What we're building, who for, why now.

## 2. Problem Statement
The user / business pain in 1–2 paragraphs. Cite evidence
(metrics, support tickets, user interviews). No solutions yet.

## 3. Users & Jobs-to-be-Done
Primary persona(s) and the specific jobs they're hiring this
product to do.

## 4. Goals
Measurable success criteria (leading + lagging metrics).
"We will know this worked when X moves from Y to Z by <date>."

## 5. Non-Goals
Explicit list of what we are NOT solving in this project.
The most-referenced section after launch.

## 6. Solution Sketch
High-level approach (no architecture yet — that's the next doc).
1–2 paragraphs + a sketch if helpful.

## 7. Open Questions
Top 5–10 unanswered questions, each with named owner and due date.

## 8. Risks & Mitigations
Top risks (technical, organizational, market) with mitigation
plans or "accepted risk" call-outs.

## 9. Milestones & Sequencing
30 / 60 / 90 day plan with dependencies. No specific dates yet.

## 10. Stakeholders & Decision Owners
RACI for the major decisions.

## 11. Appendix
Research, links to design docs, ADRs, related projects.

| ID  | Risk                              | Cat | P | I | Score | Strategy | Owner | Status |
|-----|-----------------------------------|-----|---|---|-------|----------|-------|--------|
| R01 | API not ready by week 6           | Dep | 4 | 5 | 20    | Mitigate | Sara  | OPEN   |
| R02 | Design system v3 breaks v2 callers| Tec | 3 | 4 | 12    | Mitigate | Mark  | DONE   |
| R03 | Single Bus Factor on TanStack mig | Peo | 3 | 5 | 15    | Mitigate | Lead  | OPEN   |

             User Activities (horizontal — left→right in user time)
        +-------+-------+-------+-------+
        | Find  | Try   | Buy   | Use   |
        +-------+-------+-------+-------+
Backbone| story | story | story | story |    ← essential MVP slice
        +-------+-------+-------+-------+
Walking | story | story | story |       |    ← release 2
Skeleton| story | story |       |       |    ← release 3
        +-------+-------+-------+-------+

02Tech Stack Selection

Tech stack is a 5-year decision dressed as a 2-week task. The Lead's job is to make this decision visible, justified, and reversible where possible.

2.1 The Decision Axes

2.2 The 9-Question Decision Framework

Borrowed from Spotify's tech-radar process and adapted for FE:

1. Does it solve our actual problem? Not "is it cool" — "does the constraint exist?"
2. What is the total cost of ownership over 3 years? Licensing, hosting, hiring, switching costs.
3. How big is the community? Stack Overflow tag count, npm weekly downloads, GitHub contributors, conference talks last 12 months.
4. What is the bus factor? One maintainer = high risk. Foundation-backed (Linux Foundation, OpenJS) = safer.
5. What does the next version look like? Roadmap public? Breaking changes telegraphed?
6. How does it interop with the rest of the stack? Does it force decisions in adjacent layers (Next.js forces Vercel-friendly choices)?
7. What does the exit look like? Can we migrate off in 6 months if needed?
8. How does it perform on our hot path? Build a tracer-bullet prototype and measure.
9. Who already knows it on the team? Internal capability is a free advantage.

2.3 Anti-patterns Lead Candidates Should Articulate

• Resume-driven development: picking the technology because it's hot, not because it fits.
• Sunk-cost decisions: "we already started with X, so we must continue" — even when X is failing.
• Lowest-common-denominator: picking only what the most junior engineer already knows — caps ambition.
• "Just use whatever": the inverse of analysis paralysis. Lead candidates have opinions backed by evidence.

2.4 Hard Questions

2.5 References

• State of JS 2024 results
• State of CSS 2024
• ThoughtWorks Technology Radar
• npm trends comparison
• Bundlephobia — bundle size impact
• Moiva — package comparison
• Fowler on Microservices (FE parallels)

03Architecture & ADRs

Architecture is the set of decisions that are expensive to reverse. A Lead documents them so the next Lead doesn't have to re-derive them.

3.1 Architecture Decision Records (ADRs)

Introduced by Michael Nygard in 2011 (canonical post). Every significant decision gets a numbered Markdown file in docs/adr/:

# ADR-0023: Adopt Module Federation for Cross-Team UI Sharing

## Status
Accepted — 2026-04-10

## Context
We have 6 product squads each shipping their own React app. Shared components
are copy-pasted across repos and drift. Build-time npm packages cause coordinated
deploys and a 30-minute release cycle.

## Decision
Adopt Module Federation (Webpack 5 / Rspack) to load shared remotes at runtime.
Host the design system as a federated remote consumed by all six apps.

## Consequences
+ Independent deploys of design system without consumer rebuild.
+ Sub-second hot-swap when a fix ships.
- Runtime coupling: a broken remote breaks consumers.
- Shared deps (React, Router) require strict version negotiation.
- New observability requirement: track remote load failures per consumer.

## Alternatives Considered
- Build-time npm packages with changesets (current state): rejected — release coupling.
- Web Components: rejected — interop friction with React state.
- Single-spa: rejected — heavier than Module Federation for our use case.

## References
- Module Federation docs: https://module-federation.io/
- Zack Jackson talks on YouTube (creator)
- Our PoC results: docs/poc/module-federation-2026-Q1.md

3.2 The Frontend Architecture Layers

Modeled after the C4 model adapted for FE:

3.3 Composition Patterns at Scale

3.4 The Hard Architectural Trade-offs

3.5 Hard Questions

3.6 References

• ADR community resources
• ADR templates & examples
• C4 Model
• Micro-Frontends (Fowler/Jackson)
• Module Federation handbook
• Spotify FE engineering
• Airbnb engineering OSS
• Uber Engineering — Web

04Foundation Setup — Day 1 to Week 4

The platform decisions made before any feature ships will be inherited by 100 future engineers. A Lead invests in foundation as if onboarding the team they don't have yet.

4.1 The Day-One Checklist

1. Repo created; default branch protection on; required reviewers configured.
2. Conventional commits enforced via commitlint.
3. Node version pinned (.nvmrc + engines field) and reproduced in CI.
4. Package manager pinned (packageManager field in package.json — Node 16.9+).
5. TypeScript with strict: true; noUncheckedIndexedAccess, exactOptionalPropertyTypes on.
6. Linter + formatter: Biome OR ESLint flat config + Prettier; rules committed.
7. Pre-commit hooks: Husky + lint-staged (or simple-git-hooks).
8. CI pipeline running on PRs from minute one — even if it just lints.
9. Renovate or Dependabot configured for dependency PRs.
10. License file, README, CODEOWNERS, CONTRIBUTING.md.
11. Security: npm audit in CI, Snyk/Socket integration, SBOM generation.
12. Editor config: .editorconfig, recommended VS Code extensions in .vscode/extensions.json.

4.2 TypeScript Configuration (Production-Grade)

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2023", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "jsx": "react-jsx",
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "isolatedModules": true,
    "verbatimModuleSyntax": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,
    "incremental": true,
    "paths": {
      "@app/*": ["./src/app/*"],
      "@ui/*": ["./src/ui/*"]
    }
  }
}

Reference: tsconfig reference · Total TypeScript — tsconfig cheatsheet

4.3 CI Pipeline Anatomy

Target: PR-to-feedback < 5 minutes. Anything slower kills iteration velocity.

4.4 Hard Questions

4.5 References

• Conventional Commits
• Semantic Versioning
• changesets — versioning monorepos
• Renovate
• GitHub Actions concurrency
• Playwright sharding

05Design System & UI Foundation

A design system is product infrastructure — not "a folder of components." A Lead treats it with the same rigor as an API.

5.1 The Layered Token Architecture

The mature pattern adopted by Material 3, Adobe Spectrum, Carbon, and Polaris:

Tools: Style Dictionary, Tokens Studio (Figma), Specify, W3C Design Tokens spec.

5.2 Component Architecture Patterns

Headless / Behavior + Presentation Split

Modern best-practice. Headless libraries (Radix UI, React Aria, Headless UI, Ark UI) own behavior, accessibility, keyboard, focus. Your team owns visuals. The split lets the design system evolve visually without re-implementing accessibility every time.

// Headless + styled (shadcn/ui style):
import * as Dialog from '@radix-ui/react-dialog';

export function ConfirmDialog({ children, ...props }) {
  return (
    <Dialog.Root {...props}>
      <Dialog.Overlay className="overlay" />
      <Dialog.Content className="content">
        {children}
        <Dialog.Close className="close" />
      </Dialog.Content>
    </Dialog.Root>
  );
}

Compound Components

Parent component coordinates child state via Context. Used by Reach UI, Radix, Headless UI, and any modern Tabs/Accordion/Select.

Polymorphic Components (“as” prop)

Allow consumer to render the component as any HTML element. Hard to type correctly — see Ben Ilegbodu — polymorphic components in TS. React Aria uses a different pattern (slots).

Slot Pattern

Allow the parent to pass an element rather than children, useful for swapping the underlying element while keeping props/behavior. Implemented in Radix via asChild.

5.3 Storybook in Production

• Every component has stories that double as documentation and as tests via interaction testing.
• Visual regression via Chromatic, Percy, or Playwright snapshots gated on PR.
• a11y addon running axe-core on every story.
• Component testing mode for running stories as test fixtures.
• Story-driven design reviews — designers approve in Chromatic UI before merge.

5.4 Hard Questions

5.5 References

• designsystems.com
• Atlassian Design System
• Adobe Spectrum
• IBM Carbon
• Shopify Polaris
• GitHub Primer
• Radix UI
• React Aria
• shadcn/ui
• Brad Frost — Atomic Design

06State Strategy

"What state library should we use?" is the wrong question. "What kinds of state exist in our app, and where does each live?" is the right one.

6.1 The Four Kinds of State

6.2 Client-State Library Comparison

6.3 The Cache-Invalidation Question

Phil Karlton: "There are only two hard things in Computer Science: cache invalidation and naming things." TanStack Query won the FE space because it answered this:

• Stale time — how long data is considered fresh; no refetch within this window.
• Cache time / gcTime — how long unused data stays before garbage collection.
• Refetch on window focus / reconnect / mount — automatic background refresh policies.
• Optimistic updates with rollback on failure.
• Query keys as cache keys — hierarchy enables targeted invalidation: ['user', userId, 'posts'].
• Mutations + automatic invalidation — declarative dependencies.

6.4 Hard Questions

6.5 References

• TanStack Query docs
• Zustand docs
• Jotai docs
• Redux Toolkit
• XState (Stately)
• TkDodo's blog — Query internals
• Kent C. Dodds — Application state with React

07Data Layer & Caching

The data layer determines perceived performance more than any single rendering optimization. Network latency is your dominant cost.

7.1 REST vs GraphQL vs tRPC vs RPC

7.2 The Cache Hierarchy

A modern FE has at least 4 caches on the path from server to user:

1. Browser HTTP cache — governed by Cache-Control, ETag, Last-Modified.
2. Service Worker cache — programmable via the Cache API and Workbox.
3. In-memory client cache — TanStack Query / Apollo normalized cache.
4. CDN cache — Cloudflare, Fastly, Akamai; tags, surrogate keys, soft-purge.

Lead-level understanding: each layer has different invalidation primitives. The challenge is consistent purge semantics across them. Stripe and Shopify use surrogate keys + tag-based purge to cascade invalidations.

7.3 HTTP Cache Headers — The Set That Matters

Cache-Control: public, max-age=31536000, immutable    # versioned static assets
Cache-Control: private, no-cache                       # HTML for authed pages
Cache-Control: public, s-maxage=60, stale-while-revalidate=600  # SWR pattern at CDN
ETag: "abc123"
Vary: Accept-Encoding, Accept-Language, Cookie

Reference: MDN HTTP caching · RFC 9111 · web.dev — SWR.

7.4 The N+1 Anti-pattern (Client Side)

// ❌ N+1: fires N requests sequentially
const users = await fetch('/api/users').then(r => r.json());
for (const u of users) {
  u.posts = await fetch(`/api/users/${u.id}/posts`).then(r => r.json());
}

// ✅ Batch + parallel
const users = await fetch('/api/users').then(r => r.json());
const postsByUser = await Promise.all(
  users.map(u => fetch(`/api/users/${u.id}/posts`).then(r => r.json()))
);
users.forEach((u, i) => (u.posts = postsByUser[i]));

// ✅✅ Batch endpoint (best)
const users = await fetch('/api/users?include=posts').then(r => r.json());

7.5 Hard Questions

7.6 References

• web.dev — HTTP cache
• RFC 9111 — HTTP Caching
• TanStack Query caching
• Sam Newman — BFF pattern
• GraphQL best practices
• tRPC docs

08Authentication & Identity

Auth is where security and UX collide. A Lead FE knows the protocols deeply enough to push back on bad backend designs.

8.1 Standards You Must Know

8.2 The OAuth 2.1 Flow (Authorization Code + PKCE)

1. Client generates a random code_verifier, derives code_challenge = SHA256(verifier).
2. Redirect to /authorize?response_type=code&client_id&redirect_uri&scope&state&code_challenge&code_challenge_method=S256.
3. User authenticates; provider redirects to redirect_uri?code=xxx&state=yyy.
4. Client POSTs code + code_verifier to /token; receives access_token, id_token (OIDC), maybe refresh_token.
5. Client calls APIs with Authorization: Bearer <access_token>.

PKCE makes the flow safe for public clients (SPAs, mobile). Reference: OAuth 2.1 draft · OIDC spec · oauth.net/2.1

8.3 Token Storage — The Hard Decisions

8.4 WebAuthn / Passkeys — The Future

Passkeys are FIDO2 credentials synced via platform cloud (iCloud Keychain, Google Password Manager, 1Password). UX: tap fingerprint, in. Security: private key never leaves device, public key on server; phishing-proof because the key is bound to the origin.

// Register a passkey
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,       // server-provided random
    rp: { id: 'example.com', name: 'Example' },
    user: { id: userId, name: email, displayName: name },
    pubKeyCredParams: [{ alg: -7, type: 'public-key' }],
    authenticatorSelection: { residentKey: 'required', userVerification: 'preferred' },
  }
});
// Send credential.response to server for verification

Reference: passkeys.dev · WebAuthn guide · W3C WebAuthn L3

8.5 Authorization (AuthZ) — Not Auth (AuthN)

Patterns:

• RBAC — Role-Based Access Control. Roles → permissions. Simple, scales poorly with edge cases.
• ABAC — Attribute-Based. Decisions on user/resource attributes. Flexible.
• ReBAC — Relationship-Based. Google Zanzibar paper; OpenFGA, SpiceDB, Permify. Best for "user can edit doc because they're in group that owns folder."

Reference: Google Zanzibar paper · OpenFGA

8.6 Hard Questions

8.7 References

• OAuth 2.1
• OIDC Core 1.0
• OAuth 2.0 for Browser-Based Apps
• OWASP Authentication Cheat Sheet
• passkeys.dev
• FedCM (Chrome)

09Routing

Routing is the public API of your app. URLs are forever; design them like they will be.

9.1 URL Design Principles

• Resource-oriented nouns: /users/:id/projects/:slug, not /getUserProject.
• Hackable — users can guess parent routes by truncating segments.
• Stable — set up redirects for any breaking change. Search engines and bookmarks live forever.
• Sharable — state critical to reproducing the view is in the URL (filters, sort, page, tab).
• Localizable — locale either in subdomain (en.example.com), path (/en/products), or via Accept-Language. Decide consciously.
• Type-safe at the boundary — runtime validate params (Zod) at the loader.

9.2 Router Landscape

9.3 Next.js App Router — The Patterns to Know

• Nested layouts — shared shell across child routes; preserved on navigation.
• Loading.js / Suspense — instant loading UI while data streams.
• Error.js — per-segment error boundary.
• Parallel routes — render multiple slots simultaneously (dashboard with sidebar + content).
• Intercepting routes — modal overlays that survive refresh (Instagram-style photo modal).
• Route groups — folder-as-segment escape: (marketing) doesn't add a URL segment.
• Dynamic segments + generateStaticParams — SSG for known paths, fallback for unknown.

9.4 Hard Questions

9.5 References

• React Router
• TanStack Router
• Next.js App Router
• Tim Berners-Lee — Cool URIs don't change

10Forms & Validation

Forms are where 80% of conversion lives. Lead candidates know forms cold.

10.1 Library Picks (2026)

10.2 Validation Schemas

• Zod — most popular; great DX; chained API.
• Valibot — tree-shakable, smaller bundle (a fraction of Zod).
• ArkType — fastest at runtime; TS-syntax inspired DSL.
• Standard Schema — emerging interop spec so libraries can target multiple validators.

10.3 The Hard Form Problems

• Async validation — username availability, debounced calls, race condition handling (latest-only wins).
• Cross-field rules — confirm password matches, end date after start date.
• Conditional fields — schema that changes based on prior selections; z.discriminatedUnion.
• Multi-step wizards — partial submit + draft persistence; URL state per step.
• Server-returned validation errors — surface per field with translated messages; 422 with field map.
• Optimistic + offline submission — local-first persist; sync queue; conflict resolution.
• Accessible errors — aria-describedby, aria-invalid, error list with focus management, screen reader announcement.

10.4 Hard Questions

11Internationalization (i18n & l10n)

i18n done badly is impossible to fix later. Done well, it's invisible.

11.1 The Vocabulary

11.2 The Common Mistakes

• String concatenation — "You have " + n + " items" breaks for word order in other languages. Use ICU MessageFormat.
• Hard-coded plural rules — many languages have more than 2 plural forms (Arabic has 6, Russian 4). Use CLDR plural rules.
• Date / number formatting with manual code — use Intl.DateTimeFormat, Intl.NumberFormat, Intl.RelativeTimeFormat, Intl.ListFormat.
• Pixel-based layouts — Japanese text is shorter, German much longer; layouts must flex.
• Forgetting RTL — use logical CSS properties (margin-inline-start, padding-block-end).
• Sortable strings — use Intl.Collator, never String.prototype.localeCompare without options.
• String IDs as English — use stable hashes/IDs so source English can change without breaking IDs in translation memory.

11.3 Modern Tools

• Lingui — extracts strings via Babel/SWC plugin; ICU MessageFormat support.
• FormatJS / react-intl — long-time standard.
• i18next — popular, framework-agnostic.
• next-intl — Next.js-native.
• Crowdin / Lokalise / Phrase — TMS for translator collaboration.

11.4 Hard Questions

12Testing Pyramid & Quality Strategy

A Lead designs the test strategy — not just writes tests. The shape of the test portfolio is a leadership artifact.

12.1 The Modern Test Portfolio (post-Trophy / post-Pyramid)

Kent C. Dodds proposed the "Testing Trophy" — emphasizing integration over unit. Honeycomb / Spotify use a different shape. The truth: shape depends on product. Below is a sane default for a modern web product.

12.2 The Test-Strategy Question

Decisions a Lead makes explicitly:

• What flakiness rate is acceptable? Typical target: < 1% per E2E. Above that, automation becomes a tax.
• Who fixes flakes? "Last green pipeline" owner or a dedicated quality engineer.
• What's mocked vs real? Default: mock network at MSW boundary, run real timers, real fetch. Mock 3rd-party SDKs at module boundary.
• What's covered by E2E vs integration? Rule: E2E for cross-team contracts (auth → product → checkout); integration for within-team.
• How is test data managed? Test factories (e.g., fishery); avoid hand-rolling fixtures.
• How are flaky tests quarantined? Auto-quarantine after N flakes; assign ticket to owner; remove from blocking after fix.

12.3 Hard Questions

12.4 References

• Testing Trophy
• React Testing Library
• Mock Service Worker
• Playwright
• Vitest
• Chromatic
• Pact

13Performance Engineering

Lead-level perf is not "make Lighthouse green." It's "set budgets, instrument them, defend them, and explain the trade-offs."

13.1 Core Web Vitals (2026 state)

13.2 Performance Budgets

A Lead defines budgets per route, not per app:

# perf-budget.yaml
routes:
  /:
    js: 170kb
    css: 30kb
    lcp_p75: 2.0s
    inp_p75: 150ms
  /product/[id]:
    js: 220kb
    images: 600kb
    lcp_p75: 2.5s
  /admin/*:
    js: 500kb        # power user, larger budget acceptable
    lcp_p75: 4.0s

Enforce via Lighthouse CI, size-limit, bundlewatch, or Calibre on every PR; block merge if violated.

13.3 The Perf Diagnostic Playbook

1. Capture: WebPageTest from a representative location with throttled connection (Slow 4G, Moto G Power); record filmstrip + waterfall + Lighthouse trace.
2. Classify: which CWV is failing? LCP → asset on critical path. INP → main-thread work. CLS → layout instability.
3. Diagnose: open trace in DevTools Performance; look at long tasks, layout shift regions, LCP element selection.
4. Hypothesize: one change, predict impact.
5. Implement & measure: A/B in production via feature flag, or controlled lab measurement at minimum.
6. Lock it in: add a budget assertion so regression breaks CI.

13.4 LCP Playbook

• Identify LCP element (DevTools surface; PerformanceObserver in code).
• If image: fetchpriority="high", AVIF/WebP, responsive srcset, preload hint, no lazy loading for above-fold.
• If text: font-display: swap; preload critical fonts; self-host (Google Fonts CDN adds DNS + TLS hops).
• Reduce render-blocking CSS: inline critical, async load rest.
• Defer non-critical JS; code-split aggressively.
• Improve TTFB: edge SSR or static; cache HTML at CDN.
• 103 Early Hints for known critical resources.

13.5 INP Playbook

• Find long tasks > 50ms via Long Animation Frames API (replaces Long Tasks).
• Yield to the main thread: scheduler.yield(), requestIdleCallback, React's useTransition.
• Virtualize long lists (TanStack Virtual, react-window).
• Memoize expensive recomputations; React Compiler does this automatically.
• Move heavy work to Web Workers (Comlink for ergonomic RPC).
• Avoid synchronous reflow in event handlers (read all then write all).

13.6 CLS Playbook

• Always set width/height on images and embeds OR aspect-ratio.
• Reserve space for ads, banners, dynamically inserted content.
• Animate transform/opacity only; never width/height/top/left for animations.
• Font swap: size-adjust, ascent-override on @font-face; or use font-display: optional.
• Avoid inserting DOM above existing content unless triggered by user interaction (which excludes from CLS).

13.7 Real User Monitoring (RUM)

• Use the web-vitals JS library to capture CWV in production.
• Send to a backend: SpeedCurve, Calibre, Datadog RUM, Sentry Performance, Vercel Speed Insights, your own.
• Slice by route, device, region, connection, build hash — find where regression lives.
• Alert on p75 regression of any CWV by > 10% over 24h.

13.8 Hard Questions

13.9 References

• web.dev — Learn Performance
• Web Vitals overview
• Chrome DevTools Performance
• WebPageTest
• Lighthouse CI
• Calibre engineering blog
• Harry Roberts — perf writing
• 3perf.com

14Accessibility (a11y)

Accessibility is a competitive advantage hiding behind a compliance label. Lead candidates treat WCAG as a floor, not a ceiling.

14.1 The Standards Landscape (2025+)

14.2 The Four Principles (POUR)

1. Perceivable — text alternatives, captions, contrast ≥ 4.5:1 (normal text), structure conveyable in multiple ways.
2. Operable — full keyboard, no time traps, no flashing > 3/s, skip links, focus visible.
3. Understandable — readable language, predictable navigation, error identification and suggestion.
4. Robust — works with current and future AT; valid HTML, ARIA used correctly.

14.3 ARIA — The Five Rules

1. Don't use ARIA — use semantic HTML when it exists.
2. Don't change native semantics — never put role="button" on an h1.
3. All interactive ARIA must be keyboard-accessible.
4. Don't use role="presentation" or aria-hidden="true" on focusable elements.
5. Every interactive element needs an accessible name.

Reference: W3C — Using ARIA · ARIA Authoring Practices Guide

14.4 Focus Management — The Hard Part

• Route changes in SPAs — focus a heading or a skip-link target; announce via live region.
• Modals — trap focus inside; restore to triggering element on close; use inert attribute on background.
• Drag and drop — provide a keyboard alternative (arrow keys + space).
• Toasts / notifications — role="status" for polite, role="alert" for assertive; don't steal focus.
• Async content — aria-live="polite" regions; aria-busy="true" while loading.
• Focus visible — never outline: none without a replacement; use :focus-visible for keyboard-only rings.

14.5 Testing Approach

14.6 Hard Questions

14.7 References

• WCAG 2.2 spec
• ARIA Authoring Practices Guide
• WebAIM
• The A11Y Project
• Adobe React Aria
• Deque axe-core
• Inclusive Components — Heydon Pickering

15Security

A Lead FE thinks like an attacker. Every input is hostile until proven otherwise.

15.1 OWASP Top 10 (2021) — Frontend Lens

15.2 XSS — The Three Types

• Stored — payload saved server-side, served to others. Most dangerous.
• Reflected — payload in URL/query, executed on render.
• DOM-based — client JS writes attacker input to DOM unsanitized.

React escapes string interpolation by default. The remaining holes:

• dangerouslySetInnerHTML — use DOMPurify or html-react-parser with allowlist.
• href={userInput} — javascript: URI is XSS. Allowlist protocols (https, http, mailto, tel).
• style={userInput} — CSS injection (data exfiltration via background-image: url(...)).
• Third-party libraries that document.write or set innerHTML internally.

15.3 Content Security Policy (CSP)

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{random}' https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: blob: https:;
  font-src 'self' data:;
  connect-src 'self' https://api.example.com https://*.sentry.io;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests;
  report-uri /csp-report;
  report-to default;

Nonce-based CSP (random nonce per request, applied to legitimate inline scripts) is the modern default. 'unsafe-inline' for scripts is a deal-breaker — use nonces or hashes.

Reference: web.dev — Strict CSP · content-security-policy.com

15.4 Trusted Types (the modern XSS firewall)

A browser API that prevents passing strings to DOM XSS sinks (innerHTML, document.write) unless wrapped in a policy-approved type. Google deployed it to reduce XSS to near-zero on their consumer products.

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types my-policy

Reference: web.dev — Trusted Types · W3C Trusted Types spec

15.5 Security Headers (the full set)

Audit: securityheaders.com · Google CSP Evaluator

15.6 Supply Chain Security

• Lockfile hygiene — never auto-merge dependency PRs without review.
• Snyk / Socket.dev / GitHub Dependabot — scan for known CVEs and malicious packages.
• SBOM (Software Bill of Materials) — CycloneDX or SPDX format; CISA mandates for federal contracts.
• Pinned versions — no ^ or ~ for production deps in lockfile.
• Subresource Integrity (SRI) for any CDN-loaded script.
• npm install discipline — review postinstall scripts; consider --ignore-scripts.

15.7 Hard Questions

15.8 References

• OWASP Top 10
• OWASP Cheat Sheet series
• web.dev — Security
• CryptoCat YouTube — security explainer
• Socket.dev — supply chain
• Google Project Zero blog

16Observability

If it's not measured, it doesn't exist. Frontend observability is harder than backend because you can't put a debugger on the user's browser.

16.1 The Three Pillars (+ Two)

16.2 Error Tracking — Production-Grade

• Source map upload on every deploy; never serve source maps publicly.
• Release tagging — every error tagged with build hash + version; regression detection automated.
• User context — anonymized user id, plan, locale, but redact PII.
• Breadcrumbs — last N navigations, network calls, console messages.
• Error boundaries in React at route + feature granularity with fallback UI + automatic report.
• Unhandled rejection + window.onerror capture for what bypasses boundaries.
• Sample rate — for high-traffic apps; bias toward keeping rare errors.
• Alerting — new error type within 24h → on-call ping; spike of existing error > threshold → ping.

16.3 Distributed Tracing on the Client

OpenTelemetry JS lets you create spans on the client and propagate W3C traceparent headers to your backend. Result: a single trace from user click to database query.

// Client-side span
const tracer = trace.getTracer('frontend');
const span = tracer.startSpan('checkout-submit');
try {
  await fetch('/api/checkout', {
    method: 'POST',
    headers: { /* OpenTelemetry auto-injects traceparent */ },
    body: JSON.stringify(data),
  });
} finally {
  span.end();
}

Reference: OpenTelemetry JS · W3C Trace Context

16.4 Analytics & Product Telemetry

• Schema-first events — typed event schema (Avro / JSON Schema); contract enforced in code.
• Server-side or client-side? Client = user behaviour, latency, errors. Server = revenue, authoritative state. Both for accuracy.
• Consent & privacy — IAB TCF v2.2, OneTrust, native consent banner; honor consent flags before any tracking.
• Avoid third-party trackers on critical path — load async, after LCP; ideally proxy server-side.

16.5 Hard Questions

16.6 References

• OpenTelemetry
• Sentry JS docs
• web.dev — RUM best practices
• Honeycomb — Observability-Driven Development

17CI/CD & Release Engineering

"How often can you ship safely?" is a leadership metric. The answer should be "any time we want, and we have."

17.1 Release Strategies

17.2 Feature Flags — Done Right

• Use a real flag platform: LaunchDarkly, Split, Unleash, ConfigCat, GrowthBook (OSS), Statsig.
• Three flag types: release (short-lived, deleted after rollout), experiment (A/B with metrics), permission (long-lived; access control).
• Maintain a flag inventory with TTL; auto-create cleanup tickets when a release flag passes 30 days.
• Default state should be safe (off).
• Server-side resolution prevents flicker; client-side allows fast UI swap.
• Test both branches in CI.

17.3 The Deployment Pipeline (Lead-quality)

17.4 Hard Questions

17.5 References

• Pete Hodgson — Feature Toggles
• trunkbaseddevelopment.com
• DORA metrics
• LaunchDarkly engineering blog

18Deployment, CDN & Edge

Where your code runs is as much a decision as what it does. The edge is no longer optional.

18.1 The Edge Landscape

18.2 What to Run at the Edge

• Auth checks (validate session cookie at the edge, redirect or return 401 instantly).
• A/B test bucketing (consistent hashing on user id; pick variant; pass via header to origin).
• Geo-based redirects / personalization.
• Bot detection / WAF rules.
• HTML rewriting (HTMLRewriter API in CF Workers).
• Cache key normalization.
• Image optimization.

18.3 CDN Patterns

• Surrogate keys / Cache Tags for tag-based purge (Fastly, Cloudflare Enterprise).
• SWR (stale-while-revalidate) headers to serve stale instantly while refreshing background.
• ISR (Incremental Static Regeneration) for content that changes per minute, not per request.
• Tiered caching — Cloudflare Argo / Fastly origin shielding.
• Cache key normalization — strip non-meaningful query params; canonicalize trailing slash.

18.4 Hard Questions

18.5 References

• Cloudflare Workers
• Vercel Edge Functions
• WinterCG — common runtime spec

19Documentation & Knowledge

Engineering culture is what survives the engineers leaving. Documentation is its substrate.

19.1 The Four Document Types

Reference: Divio Documentation System — the four-quadrant model.

19.2 What "Good" Looks Like

• Onboarding doc — new engineer can ship a PR on day 2, not day 12.
• Architecture overview — a single page diagram + 200 words; not a 40-page wiki nobody reads.
• Runbook per page for every alert that pages someone.
• Code lives next to docs — Storybook stories are docs; TSDoc is docs.
• Docs in the repo, reviewed in PR, not in a separate Confluence.

19.3 Hard Questions

20Code Review Culture

Code review is the highest-leverage activity in any engineering org. A Lead designs the system as deliberately as any other.

20.1 Principles (Google's eng practices, adapted)

• Review for the change as it stands, not for what you would have written.
• Approve when the change improves the codebase, not when it's perfect.
• Comments are categorized: blocker (must fix), suggestion (consider), nit (style preference), question, praise.
• Code review SLA: first response within 4 working hours; full review within 24h.
• Small PRs (< 400 LoC) get reviewed; large PRs get rubber-stamped or postponed.
• Author responds to every comment (even "noted" or "wontfix because X"). No silent ignore.

20.2 The Tooling Matters

• CODEOWNERS for automatic reviewer assignment.
• Required CI green before merge.
• Stacked PRs for large changes (Graphite, Sapling, git-branchless).
• AI review (CodeRabbit, Greptile, Diamond) as first-pass — humans focus on architecture.
• Merge queue (GitHub, Aviator, Mergify) to test mainline state.

20.3 Hard Questions

20.4 References

• Google Engineering Practices
• Michael Lynch — How to Make Your Code Reviewer Fall in Love
• Graphite — stacked PRs
• Sapling (Meta)

21Browser Internals

A Lead reasons about performance from how the browser actually works — not from React's abstractions.

21.1 The Rendering Pipeline

1. Parse HTML → DOM tree. Streaming parse; can be paused by script tags (unless async/defer).
2. Parse CSS → CSSOM. Render-blocking.
3. JavaScript execution — can read/write DOM and CSSOM; blocks parser unless deferred.
4. Render tree — DOM × CSSOM, omitting display:none nodes.
5. Layout (reflow) — compute geometry for every render-tree node.
6. Paint — fill pixels into layers (a layer per "compositing trigger": transform, opacity, will-change, video, canvas).
7. Composite — GPU stitches layers together for the final frame.

The fast path bypasses layout and paint — only composite. That's why transform and opacity animations are 60fps-cheap while top/width are expensive.

21.2 The Event Loop

┌─────────────────┐
│   Macrotask     │  ← one per loop turn (setTimeout, setInterval, I/O, UI events)
├─────────────────┤
│   Microtasks    │  ← all drained before next macrotask (Promise.then, queueMicrotask, MutationObserver)
├─────────────────┤
│  requestAnimationFrame callbacks  │  ← before paint
├─────────────────┤
│   Style + Layout + Paint           │
├─────────────────┤
│  requestIdleCallback (if time)     │
└─────────────────┘

Implications: a Promise chain runs before the next setTimeout(0) callback. queueMicrotask lets you piggyback work without yielding to the browser. requestAnimationFrame aligns work with the paint cycle (~16.67ms at 60Hz, 6.94ms at 144Hz).

21.3 Memory Management

• V8 uses generational garbage collection: young generation (Scavenger, fast), old generation (Mark-Sweep + Mark-Compact, slower).
• Common leaks: forgotten event listeners on detached DOM, large closures captured by long-lived callbacks, growing arrays in modules, third-party scripts.
• Diagnose with Chrome DevTools → Memory tab → Heap snapshot + Allocation timeline.
• WeakRef / FinalizationRegistry for advanced cache scenarios.
• Profile memory across page navigations in SPAs — leaks compound.

21.4 The Critical Rendering Path

Sequence to first paint: HTML byte → DOM → render-blocking CSS → first layout → first paint. JS in <head> blocks DOM parse. JS without defer/async blocks parsing. CSS in <head> blocks render. Optimizing this path is the foundation of LCP optimization.

21.5 Hard Questions

21.6 References

• How Browsers Work
• Chrome — Inside the browser series
• Browser Engineering (online textbook)
• Jake Archibald — The event loop talk
• HTML spec — event loops

22JavaScript Mastery

Past the bootcamp basics. Closures, iterators, generators, proxies, decorators, the proposals pipeline.

22.1 Closures & Lexical Scope

A closure is a function bundled with its lexical environment. The hardest production bug is usually a stale closure — a callback captured an old version of state.

// Stale closure trap
function setupCounter() {
  let count = 0;
  setInterval(() => console.log(count), 1000);  // forever logs 0
  count++;  // unreachable; the closure already captured count=0 at scheduling
}

// In React
function Counter() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => setCount(count + 1), 1000);  // stale; count is always 0
    return () => clearInterval(id);
  }, []);  // ← empty deps array = closure baked at mount
  // FIX: setCount(c => c + 1) — functional update reads latest
}

22.2 Iterators & Generators

// Custom iterable
class Range {
  constructor(start, end) { this.start = start; this.end = end; }
  *[Symbol.iterator]() {
    for (let i = this.start; i <= this.end; i++) yield i;
  }
}
for (const n of new Range(1, 5)) console.log(n);

// Async iterators for streams
async function* readLines(file) {
  for await (const chunk of fs.createReadStream(file)) {
    for (const line of chunk.toString().split('\n')) yield line;
  }
}

22.3 Proxies — Use Sparingly

const observed = new Proxy(target, {
  get(t, key, recv) { trackRead(t, key); return Reflect.get(t, key, recv); },
  set(t, key, val, recv) { const r = Reflect.set(t, key, val, recv); trigger(t, key); return r; }
});

Proxies power MobX / Vue reactivity / Valtio. Cost: every access goes through a trap; not free. Use for tooling, not hot paths.

22.4 Patterns Worth Knowing

• AbortController — cancellation for fetch, listeners, custom async; chainable via signals.
• Structured Clone — built-in deep clone (structuredClone(obj)).
• Symbol — unique keys; well-known symbols (Symbol.iterator, Symbol.asyncIterator, Symbol.toPrimitive).
• WeakMap / WeakSet / WeakRef — for caches that shouldn't prevent GC.
• Optional chaining + nullish coalescing — but beware a?.b() short-circuits the whole expression.
• Tagged templates — secure-string DSLs (e.g., SQL via Drizzle).
• Pipeline operator (Stage 2 proposal) — functional chaining.
• Decorators (Stage 3) — class & field metadata.
• Records & Tuples (Stage 2) — value-type immutable structures.
• Iterator helpers (Stage 4 — shipping) — .map().filter().take() on iterators.
• Temporal API (Stage 3) — modern date/time replacing Date.

22.5 Hard Questions

22.6 References

• You Don't Know JS (Kyle Simpson)
• Dr. Axel Rauschmayer — Exploring JS
• TC39 proposals
• V8 engineering blog

23TypeScript Advanced

Beyond strict: true. The type system is a Turing-complete logic programming language — and a Lead uses it that way (judiciously).

23.1 Type-Level Tools

• Conditional types — T extends U ? X : Y.
• Mapped types — { [K in keyof T]: U }.
• Infer keyword — extract types within conditionals: type Awaited<T> = T extends Promise<infer U> ? U : T.
• Template literal types — type-level string manipulation.
• Variadic tuple types — spread in tuples.
• Discriminated unions — narrow by literal tag.
• Branded types — nominal typing via intersection: type UserId = string & { __brand: 'UserId' }.
• const generics — preserve literal types via const T extends ....
• satisfies operator — assert shape without widening.

23.2 Practical Patterns

// Type-safe event emitter
type Events = {
  login: { userId: string };
  logout: { reason: 'manual' | 'timeout' };
};
class Emitter<E extends Record<string, unknown>> {
  on<K extends keyof E>(event: K, handler: (payload: E[K]) => void) { /* ... */ }
  emit<K extends keyof E>(event: K, payload: E[K]) { /* ... */ }
}
const bus = new Emitter<Events>();
bus.emit('login', { userId: 'abc' });  // ✅
bus.emit('login', { reason: 'manual' });  // ❌ TS error

// Builder pattern with type accumulation
class QueryBuilder<T = {}> {
  select<K extends string>(key: K): QueryBuilder<T & Record<K, unknown>> { /* ... */ }
  where(...): this { /* ... */ }
  execute(): T { /* ... */ }
}
const result = new QueryBuilder().select('id').select('name').execute();
// result is { id: unknown; name: unknown }

23.3 The TypeScript Anti-Patterns

• any — opt-out of typing. Use unknown instead and narrow.
• as Type casts without runtime checks — bypass the type system at trust boundaries.
• Overly-clever types that take 5 minutes to understand. Aim for "ergonomic for the consumer, simple-ish in implementation."
• Re-exporting types from node_modules creating circular type dependencies.
• Massive single index.d.ts — type errors become slow.

23.4 Performance of the Type System

At Lead scale (50k+ TS files), type-check time matters. Tactics:

• tsc --diagnostics to see hot paths.
• Avoid deep recursion in conditional types.
• Prefer interfaces over type intersections for object shapes (faster to merge).
• incremental: true for build cache.
• Project references for monorepo.
• Migrate to TypeScript native port (Go-based, 10× faster — coming).

23.5 Hard Questions

23.6 References

• Total TypeScript — Matt Pocock
• Type-Level TypeScript
• Type Challenges
• TS Performance Wiki

24Modern CSS

CSS in 2026 is no longer the language CSS was in 2016. Container queries, layers, scope, view transitions, has(), and color spaces are production-ready.

24.1 Container Queries

.card {
  container-type: inline-size;
  container-name: card;
}
@container card (min-width: 400px) {
  .title { font-size: 1.5rem; }
}

Queries the component's own width, not the viewport. Game-changer for design systems.

24.2 Cascade Layers

@layer reset, base, components, utilities;

@layer reset { /* normalize.css */ }
@layer base { body { font-family: sans-serif; } }
@layer components { .btn { padding: 0.5rem 1rem; } }
@layer utilities { .text-sm { font-size: 0.875rem; } }

Layered cascade beats specificity wars. Later layers always win over earlier (unlayered styles beat layered).

24.3 CSS :has() — The Parent Selector

/* Card with an image gets extra padding */
.card:has(img) { padding-bottom: 2rem; }

/* Form with invalid input shows error styling on the wrapper */
.form-row:has(input:invalid) { border-color: red; }

/* Hide siblings of focused element */
.menu li:not(:has(a:focus)) { opacity: 0.5; }

24.4 View Transitions API

// SPA route change with cross-fade
document.startViewTransition(() => {
  updateDOMForNewRoute();
});

// CSS to customize
::view-transition-old(root) { animation: fade-out 0.3s; }
::view-transition-new(root) { animation: fade-in 0.3s; }

Cross-document view transitions (Chrome 126+) enable transitions across full page loads — previously only possible in SPAs.

24.5 Modern Color & Typography

• color-mix(in oklch, ...) — programmatic color mixing in perceptual color spaces.
• oklch() / oklab() — perceptually uniform color; better for design tokens than HSL.
• color() with display-p3 — wide-gamut for compatible screens.
• relative color syntax — derive variants: oklch(from var(--primary) calc(l - 0.1) c h).
• text-wrap: balance — heading line-balancing.
• text-wrap: pretty — better line-breaking in paragraphs.
• variable fonts — single file, axis-controlled (weight, width, slant); often smaller than 4 static files.

24.6 Scroll-Driven Animations

@keyframes reveal { from { opacity: 0; } to { opacity: 1; } }
.card {
  animation: reveal linear;
  animation-timeline: view();
  animation-range: entry 0% cover 30%;
}

Native CSS scroll-linked animation. No JS, no IntersectionObserver. Chrome 115+, Firefox preview, Safari coming.

24.7 Logical Properties (RTL-Ready)

24.8 Hard Questions

24.9 References

• web.dev — Learn CSS
• Una Kravets — 1-line layouts
• CSS-Tricks Almanac
• Stephanie Eckles — modern.css
• Every Layout — Heydon & Andy

25React Internals

A Lead understands what React does to memory and to the main thread — not just what hooks do.

25.1 The Reconciliation Model

React maintains two trees: current (committed) and work-in-progress (rendering). On a state change, React builds the WIP tree by re-rendering components, diffs against current, and commits changes to the DOM in a single batched flush. Since React 18, this is interruptible — concurrent rendering means the WIP tree can pause for higher-priority work (user input).

25.2 Fiber Architecture

Each component instance gets a "fiber" — a JS object holding component type, props, state, effects, and pointers to parent/child/sibling fibers. The reconciler walks fibers, not directly the DOM. Walking is cooperative — React can yield between fibers if the deadline expires.

25.3 Hooks — How They Actually Work

Each fiber has a linked list of hook instances. On render, React positionally matches calls — first call is the first hook in the list, second is the second, etc. That's why hooks must always be called in the same order (the "no conditional hooks" rule). The hook list is recreated on every render of the same fiber.

25.4 React 19 Highlights (deep)

• use() — read a promise or context conditionally. Suspends the calling component until the promise resolves. Enables RSC's "await data inline."
• React Compiler (Forget) — analyzes components at build, inserts memoization automatically. Removes 90%+ of manual useMemo/useCallback.
• Actions & useActionState — async transitions; pending state, optimistic updates, form integration.
• useOptimistic — built-in optimistic UI primitive.
• Refs as props — no more forwardRef in most components.
• Document Metadata — <title>, <meta> inside components are hoisted to <head>.
• Resources — <link rel="stylesheet" precedence> deduped and reordered automatically.
• preinit / preload / prefetchDNS — programmatic resource hints.
• Improved hydration errors — diffs reported clearly.

25.5 Server Components — The Mental Model

RSC are components that render on the server and ship a serialized tree (not HTML) to the client. The client merges them with client components ("islands"). RSC can:

• Use async/await for data fetching inline.
• Access the server filesystem, environment, databases directly.
• Ship zero JS to the client (the RSC payload describes the tree, not the source).

RSC cannot:

• Use state hooks (useState, useReducer) — they have no client lifecycle.
• Use effect hooks.
• Attach event handlers (unless via client component child).
• Use browser APIs.

'use client' at the top of a file marks everything in that module as client. A server component can import and render a client component, but not vice versa.

25.6 Hard Questions

25.7 References

• React reference docs
• Dan Abramov — Overreacted
• Andrew Clark — React Fiber Architecture
• Josh Comeau's React posts
• Official React blog

26Networking

HTTP/3, WebTransport, WebSockets, Server-Sent Events, BroadcastChannel — picking the right transport is a Lead decision.

26.1 HTTP Evolution

26.2 Real-time Transports

26.3 Picking Between WS and SSE

SSE wins for server-push-only data: simpler protocol (just HTTP), auto-reconnect with last-event-id resume, works with HTTP/2 multiplexing, no CORS gymnastics, easy to scale (CDN-friendly). LLM streaming is the classic 2024+ use case. WebSocket wins when client also pushes frequently (chat input, mouse cursors in collaborative editor).

26.4 Hard Questions

26.5 References

• High Performance Browser Networking — Ilya Grigorik (free)
• web.dev — HTTP/2 & HTTP/3
• MDN — Server-Sent Events
• W3C WebTransport spec

27Web Standards & Platform APIs

The platform shipped a lot in 2023-2025. Lead engineers should know what's possible without npm install.

27.1 APIs Worth Knowing

• IntersectionObserver — lazy-load, infinite scroll, ad viewability without scroll listeners.
• ResizeObserver — element-size-aware layouts.
• MutationObserver — react to DOM changes (third-party iframes, legacy code).
• PerformanceObserver — capture LCP, FID/INP, long tasks, layout shifts.
• Long Animation Frames (LoAF) — replaces Long Tasks; catches the things hurting INP.
• Navigation API — replaces History API + popstate; promise-based, intercept-able.
• View Transitions — animated state changes between DOM trees.
• Popover API — native popovers without JS (Chrome 114+, Safari 17+).
• Dialog element — native modal with backdrop, ESC handling, focus trap (partial).
• BroadcastChannel — cross-tab messaging.
• File System Access API — read/write user files (Chrome only).
• Web Share API — native share dialog on mobile.
• WebAuthn / Passkeys — phishing-proof auth.
• FedCM — federated identity replacing third-party cookies.
• Web Workers / Service Workers / Shared Workers — different scopes of off-main-thread.
• WebAssembly + WASI — near-native compute in browser.
• Web Bluetooth / USB / Serial / HID — hardware access (Chrome).
• Web Speech API — text-to-speech and speech-to-text.
• Web Animations API (WAAPI) — programmatic CSS animations.
• Web Locks API — coordinate across tabs (e.g., one tab leader for IndexedDB writes).
• Storage API — quota estimates, persistent storage requests.
• OffscreenCanvas — canvas rendering on a Web Worker.

27.2 Hard Questions

27.3 References

• MDN Web APIs index
• web.dev — Long Animation Frames
• Chrome Platform Status
• Popover API
• caniuse.com

28PWA & Offline-First

Service workers are how the web shipped its strongest feature in the last decade. Most teams still don't use them well.

28.1 The Service Worker Lifecycle

1. Register — JS calls navigator.serviceWorker.register('/sw.js').
2. Install — once per version; cache assets via caches.open(...).addAll(...).
3. Activate — clean up old caches; self.clients.claim() for instant control.
4. Fetch — intercept every navigation and asset; programmable caching.
5. Update — browser checks sw.js for byte changes; new SW installs in background, waits for tabs to close.

28.2 Cache Strategies

Workbox abstracts these as one-liners. Reference: Workbox docs.

28.3 Hard Questions

28.4 References

• web.dev — Learn PWA
• Service Worker Cookbook
• Workbox
• Local-First Web

29Frontend System Design — Framework

FE system design is the most distinctive part of a senior-to-staff interview. There's a structured way to approach every problem.

29.1 The RADIO Framework

Popularized by GreatFrontEnd; the most cited framework for FE system design.

1. Requirements clarification
2. Architecture / high-level design
3. Data model
4. Interface (API + component API)
5. Optimizations (perf, a11y, security, offline, error handling, scaling)

Reference: GreatFrontEnd — RADIO framework

29.2 Requirements — The Right Questions

• Functional: what does the user do? Main flows? Edge cases?
• Audience: who, where (geo), what devices, what network?
• Scale: DAU/MAU, concurrent users, peak QPS?
• Non-functional: p95 latency, accessibility, SEO, offline support, localization?
• Constraints: existing backend, tech stack, team skills, deadline?
• Out of scope: what won't you discuss (auth, signup, billing)?

29.3 Architecture Diagrams

Draw three boxes minimum: client, server (or BFF/API gateway), backend (services + data store). Add CDN/edge layer. Identify the network hops. For each hop, label payload shape and frequency.

29.4 Data Model

List entities, their relationships, the shape returned to the client. Mention normalization (cache shape) vs denormalization (transport). Discuss pagination strategy (offset/cursor/keyset). Discuss freshness — what's cached for how long.

29.5 Interface

API endpoints (REST or GraphQL queries). Component API — what the consumer sees: props, callbacks, slots. Loading/error/empty states explicitly defined.

29.6 Optimizations Checklist

29.7 References

• GreatFrontEnd System Design
• System Design Primer (general)
• JS Questions (for warm-up)

30Design: News Feed

The canonical FE system-design question. Used at Meta, Twitter, LinkedIn, TikTok.

30.1 Requirements (clarify first)

• Vertical infinite scroll, posts with text/image/video, like/comment/share.
• Personalized ranking (server-side); client just renders.
• 10M DAU; reads >> writes.
• Web + mobile web; deep links; share-to-anywhere.
• Real-time new-post indicator ("3 new posts" pill at top).

30.2 Architecture

• SSR or RSC for initial page (SEO + fast LCP for the first 5–10 posts).
• Client-side hydration; subsequent pages fetched via cursor pagination.
• Edge cache for unauth feed (logged-out homepage); per-user cache for auth feed (short TTL).
• WebSocket or SSE for new-post notifications (push count, not the posts themselves).
• Image CDN with responsive variants (srcset, AVIF), video as HLS/DASH.

30.3 Data & Pagination

// Cursor-based pagination (preferred over offset)
GET /feed?cursor=eyJ0cyI6MTcwOH0&limit=20

{
  posts: [...],
  nextCursor: "eyJ0cyI6MTcwOX0",
  hasMore: true
}

Cursor pagination handles "new posts arriving while user scrolls" correctly (offset would skip or duplicate). Stable across sessions when cursors are opaque ts+id tuples.

30.4 Virtualization & Memory

• Use TanStack Virtual or react-window with measured heights. Naive infinite scroll renders 100s of DOM nodes — memory grows.
• Recycle DOM via virtualization OR unmount far-offscreen posts and remount on re-entry (LRU).
• content-visibility: auto on each post — skips render for off-screen items.
• Image lazy-load with IntersectionObserver; loading="lazy" attribute as fallback.

30.5 Optimistic Interactions

• Like: increment count immediately, POST in background; rollback on error.
• Comment: append optimistic comment with grey state; replace with server response or retry.
• De-duplicate concurrent mutations.

30.6 Performance Targets

• LCP < 2.0s p75 (above-fold first post + image).
• INP < 100ms (like button must feel instant).
• Scroll FPS > 50 on mid-tier Android.
• Initial JS < 200KB compressed.

30.7 Edge Cases

• Post deleted while user viewing — fade-out with explanation.
• Network drops mid-scroll — show "tap to retry" within the empty space.
• Auto-play video on Wi-Fi only; respect prefers-reduced-motion.
• Same post viewed in multiple tabs — like state sync via BroadcastChannel.

30.8 References

• Meta — Relay Modern (feed data fetching)
• Twitter Engineering blog
• Airbnb — Engineering & Data Science

31Design: Collaborative Editor (Google Docs / Figma / Linear)

The hardest problem in FE system design — concurrency, consistency, and offline.

31.1 The Core Question: OT vs CRDT

31.2 Architecture (CRDT-based, like Yjs)

• Client maintains a local Y.Doc instance — single source of truth for the user.
• Edits are local mutations; converted to binary "updates" by Yjs.
• Updates sync via WebSocket to a server (or directly to peers via WebRTC).
• Server is "dumb" — relays updates and persists snapshot+log.
• Conflict resolution is automatic by CRDT properties — concurrent edits merge deterministically.
• Presence (cursors, selections) on a separate ephemeral channel.

31.3 Hard Sub-problems

• Garbage collection — CRDT tombstones accumulate; periodic compaction needed.
• Initial load — load snapshot then replay since-snapshot updates. Latency budget matters.
• Permissions — server can't trust client; document-level ACL gate on the WS.
• Undo/redo — local undo stack vs collaborative undo (only undo your own changes).
• Large documents — chunking strategies; lazy-load offscreen pages.
• Offline edits — local IndexedDB persistence; reconcile on reconnect.
• Cursor presence — debounce broadcast; subscribe only to visible users.

31.4 Linear's Sync Engine — Worth Studying

Linear ships an in-process client database synchronized with the server; all UI reads from the local store; all writes go through optimistic mutation + reconciliation. Result: every interaction is instant. Reference: Linear engineering — scaling sync.

31.5 Hard Questions

31.6 References

• Yjs documentation
• Automerge
• Liveblocks blog
• Figma — multiplayer tech
• Linear Sync Engine
• CRDT.tech (resource hub)

32Design: Autocomplete / Typeahead

Looks simple. Has every interesting FE problem in 30 lines of code.

32.1 Requirements to Clarify

• Latency target — feels instant means < 100ms perceived.
• Trigger threshold (2 chars? 1 char?).
• Recent / popular suggestions even without typing.
• Keyboard navigation (Up/Down/Enter/Esc).
• Accessibility — ARIA combobox pattern.
• Result count, ranking, highlighting.

32.2 Architecture

• Client debounces input (~150-300ms).
• Request only if query changed; AbortController cancels in-flight on new input.
• Cache key by query string; LRU eviction.
• Prefetch popular suggestions at idle.
• Server: dedicated search service (Elasticsearch / Algolia / Typesense / Meilisearch) — frontend hits this directly with auth token.
• Edge caching for popular queries; bypass for personalized.

32.3 The Race Condition Trap

// ❌ Race: user types "ne", "new", "news" — responses may arrive out of order
async function search(q) {
  const res = await fetch(`/search?q=${q}`);
  setResults(await res.json());
}

// ✅ AbortController cancels prior
let ctl;
async function search(q) {
  ctl?.abort();
  ctl = new AbortController();
  try {
    const res = await fetch(`/search?q=${q}`, { signal: ctl.signal });
    setResults(await res.json());
  } catch (e) { if (e.name !== 'AbortError') throw e; }
}

32.4 Hard Questions

32.5 References

• Algolia engineering blog
• APG Combobox

33Design: Video Player

Video is where FE meets media engineering. Adaptive bitrate, DRM, captions, low-latency.

33.1 Core Concepts

• HLS (HTTP Live Streaming) — Apple's protocol, m3u8 manifest + .ts/.mp4 segments. Default for web/iOS.
• DASH — Google/Netflix; xml manifest + MP4 segments. Common for Android/desktop.
• WebRTC — for <500ms latency (live shopping, interactive).
• LL-HLS — low-latency HLS (sub-3s).
• MSE (Media Source Extensions) — JS API for ABR streaming via append-buffer model.
• EME (Encrypted Media Extensions) — for DRM (Widevine, FairPlay, PlayReady).
• Players — Shaka (Google, supports DASH+HLS), Video.js, HLS.js, dash.js, Mux Player.

33.2 The ABR (Adaptive Bitrate) Loop

1. Player downloads manifest with multiple quality levels.
2. Measures bandwidth via segment download time.
3. Chooses next segment quality based on bandwidth + buffer level + heuristics.
4. Aims to keep buffer 10-30s, never empty.
5. Throttles up on stability, throttles down on stall risk.

33.3 Hard Sub-problems

• Autoplay restrictions — muted required on most browsers; user gesture required for sound.
• Captions — WebVTT format; accessibility critical (FCC compliance for streaming services).
• Subtitle styling — render in DOM (more control) or via native track (better a11y).
• Picture-in-picture — PiP API.
• Background playback — Media Session API for lock-screen controls.
• Watch history / resume — debounced position save.
• DRM provisioning — license server, key rotation.
• Analytics — startup time, rebuffer ratio, average bitrate, quality switches, errors. QoE (Quality of Experience).

33.4 References

• MDN — MSE
• Shaka Player docs
• Mux engineering docs
• Netflix Tech Blog

34Design: Chat / Realtime Messaging

Slack, WhatsApp Web, Discord — same problem, similar architecture.

34.1 Architecture Sketch

• WebSocket connection per user; sticky-routed to a "channel server."
• Server fan-out to all members of the channel (room).
• Message persisted to DB before fan-out (durability).
• Sequence number per channel for ordering; client uses this to detect missed messages on reconnect.
• Read receipts via separate lightweight events (debounced).
• Typing indicators via short-lived events (TTL 5s).
• Presence — heartbeat over WS; aggregated to "online/offline/idle" indicator.

34.2 Client-Side Data Model

• IndexedDB for offline persistence; messages keyed by (channel_id, sequence).
• Optimistic local-id for sent messages; reconcile to server-id on ack.
• Read-only normalized cache (Apollo-style) for users, channels, members.
• Virtualized message list (huge channels render only visible window).

34.3 Hard Sub-problems

• Reconnection without missing messages — on reconnect, client sends last_seq; server replays from durable log.
• Order across servers — sticky routing keeps per-channel order; cross-channel order is per-channel only.
• Mute / DND / per-channel notification settings — server-evaluated.
• End-to-end encryption — Signal Protocol; client-side encryption; server never sees plaintext.
• Edit and delete — append "edited" event; client rewrites local state.
• Rich content — markdown, mentions, attachments; lazy-load attachments.
• Notifications — push via FCM/APNs when web app closed.

34.4 References

• Slack Engineering blog
• Discord Engineering
• Signal Protocol docs

35Design: A Company-Wide Design System

Not "a component library." A product with users, an API, a migration story.

35.1 Requirements

• 50 product teams; 5 product brands sharing a design language.
• Web + React Native (or Flutter); shared design tokens.
• Accessible by default (WCAG 2.2 AA minimum).
• Independent versioning; consumers upgrade at their pace.

35.2 Architecture

• Token layer (JSON, generated to CSS vars, iOS XCAssets, Android XML).
• Primitives layer (Box, Stack, Text, Button, Input — built on Radix / React Aria).
• Patterns layer (Card, Modal, Toast, Form — composed primitives).
• Templates layer (Dashboard shell, Marketing landing, Settings page).
• Per-brand theme overrides via tokens, not forks.

35.3 Operating Model

• Central DS team owns the platform; product teams contribute via federated model (RFC + PR).
• Office hours, Slack channel, monthly demo.
• Metrics: adoption rate (% PRs using DS components), versions in use, time-to-upgrade.
• Quarterly migration goals; codemods for every breaking change.

35.4 Hard Questions

35.5 References

• Nathan Curtis — Contributing to a DS
• GitHub Primer Foundations
• Adobe Spectrum tokens

36AI in the Frontend

In 2026, a Lead FE is judged on two AI dimensions: how they ship AI features, and how they use AI in their own workflow.

36.1 Building User-Facing AI Features

• Vercel AI SDK — high-level wrapper for streaming, tool calling, RAG, multi-model.
• LangChain.js / LangGraph.js — orchestration of multi-step agent flows.
• LlamaIndex.ts — RAG-focused.
• Streaming UI patterns — Server Components + RSC streams, Edge functions piping SSE.
• Tool calling — model returns structured calls; FE renders custom UI per tool result.
• Inline citations + grounding — display sources next to claims.
• Cost / token budgeting — UI for premium users, fallback for free.
• Failure modes — what UX shows when the model is slow, wrong, or unavailable.

36.2 LLM-Native UX Patterns

• Streaming tokens — render progressively; never spinner-then-dump.
• Stop generation — user-cancellable; AbortController.
• Regenerate / try again — easy to retry.
• Edit and resubmit — revise prior message rather than starting over.
• Markdown / code rendering — react-markdown with safe whitelist; Prism/Shiki for syntax highlighting.
• Generative UI — RSC + tool calls producing typed React components rather than text.
• Tool result UI — chart for chart-tool, table for query-tool, map for places-tool.
• Source citations — clickable, with provenance.
• Conversation persistence — server-side history; resume across devices.
• Multi-turn context windows — manage context length, summarize older turns.

36.3 AI in Developer Workflow

36.4 Hard Questions

36.5 References

• Vercel AI SDK
• Model Context Protocol
• Anthropic engineering posts
• OpenAI — Streaming Responses

37Edge & Server Components Deep-Dive

RSC + edge is the most significant architectural shift since the SPA. A Lead can argue for and against it.

37.1 The Mental Reset

• Components run on the server, ship serialized tree.
• Client receives "instructions" not HTML — a React-internal binary format.
• Server components can await anything.
• Client components are explicit ('use client') — and become the islands of interactivity.
• Server Actions are functions on the server callable from client; they replace many API routes.

37.2 Trade-offs

37.3 Anti-patterns

• Passing huge server-fetched objects to client components — they get serialized in the RSC payload.
• Using 'use client' on a leaf rather than the boundary — it cascades.
• Calling Server Actions from useEffect — defeats the point; use them on form submit.
• Mixing server-only env vars with client components — leaks at build.

37.4 References

• React Server Components docs
• Next.js RSC
• Smashing — Forensics of RSC
• React Server Components RFC discussions

38Cross-Platform Considerations

38.1 The Choices

38.2 Code Sharing Strategies

• Share types, models, business logic (TypeScript packages in monorepo).
• Share UI primitives where possible (Tamagui, Solito for RN+Web shared components).
• Platform-specific UI for high-touch surfaces (navigation, gestures).
• Share networking, validation, state libraries.

38.3 Hard Questions

38.4 References

• React Native
• Expo
• Tamagui
• Solito
• Tauri

39Tech Debt & Migration

A Lead is judged on their ability to make hard migrations land without melting the team or the product.

39.1 The Migration Playbook

1. Define done — what state is target? Be specific.
2. Strangler fig — incremental, not big-bang.
3. Codemod first — automate every mechanical change.
4. Branch by abstraction — toggle between old and new behind an interface.
5. Owner per migration unit — accountability prevents drift.
6. Dashboards — % migrated, ETA, blockers visible.
7. Deprecation policy — old API works until date X; warn in logs.
8. Removal phase — only after 100% migration metrics + 1 quarter buffer.

39.2 Common FE Migrations

• Webpack → Vite/Rspack/Turbopack
• Jest → Vitest
• ESLint legacy config → flat config (or → Biome)
• styled-components → vanilla-extract / Tailwind
• Class components → functional
• React Router v5 → v6 → v7
• Pages Router → App Router (Next.js)
• Moment.js → date-fns / Day.js / Temporal
• Redux → Zustand / RTK Query / TanStack Query
• npm/yarn → pnpm

39.3 Hard Questions

39.4 References

• Strangler Fig
• Branch by Abstraction
• codemod.com

40Hiring, Mentoring & Team Building

40.1 What Leads Are Judged On

• Velocity of the team (DORA metrics).
• Quality of output (defect rate, customer-impacting incidents).
• People you brought up (promotions, growth conversations).
• Hiring bar maintained (or raised).
• Cross-team influence (RFCs you drove, standards you proposed).
• Sustainability (no heroics, no burnout, on-call humane).

40.2 Hiring Loop You Should Design

• Recruiter screen (45 min) — alignment, scope.
• Hiring manager (45 min) — motivation, growth, fit.
• Coding round (60-90 min) — practical problem, no leetcode trick.
• FE system design (60 min) — RADIO problem.
• Behavioral / leadership (60 min) — STAR stories.
• Bar raiser / cross-team (45 min) — Amazon-style independent assessment.
• Optional: take-home (timed, capped) for senior candidates uncomfortable with whiteboard.

40.3 Mentoring Engineers

• Weekly 1:1s — agenda owned by the report, not you.
• Growth plan — concrete, time-boxed, measurable.
• Stretch projects — assigned with safety net (pairing, rollback plan).
• Public feedback loop — code review is a teaching opportunity, not just a quality gate.
• Sponsorship over mentorship — talk about them when they're not in the room.

40.4 Hard Questions

40.5 References

• StaffEng book
• Will Larson — Elegant Puzzle
• Camille Fournier — Manager's Path

41Incident & Postmortems

41.1 The Incident Cycle

1. Detect — alerting; ideally before users notice.
2. Triage — severity, ownership, comms channel.
3. Mitigate — feature flag off, rollback, scale up.
4. Communicate — internal + external updates on cadence.
5. Resolve — full recovery.
6. Postmortem — blameless, action items, follow-through.

41.2 The Blameless Postmortem

Inspired by Etsy and SRE: focus on systems and process, not individuals. Output: timeline, contributing factors, blast radius, what worked, what didn't, action items with owners and dates.

41.3 Hard Questions

41.4 References

• Google SRE — Postmortem Culture
• Etsy — Blameless Postmortems
• Incident Labs

42Behavioral & Storytelling

42.1 The STAR Structure

• Situation — concise context.
• Task — what you owned.
• Action — specific things you did (not "we").
• Result — quantified outcome + lesson.

42.2 Story Bank — Prepare 6-8 Stories Covering

• A time you led a difficult technical decision (push back on senior leadership).
• A time you disagreed with a peer and worked through it.
• A failure — what you learned.
• A migration or refactor you led.
• A time you mentored someone significantly.
• A production incident you owned.
• A scope cut you pushed for.
• A time you said no to a stakeholder.

42.3 Amazon Leadership Principles (relevant beyond Amazon)

• Customer Obsession · Ownership · Invent and Simplify · Are Right, A Lot · Learn and Be Curious · Hire and Develop the Best · Insist on the Highest Standards · Think Big · Bias for Action · Frugality · Earn Trust · Dive Deep · Have Backbone; Disagree and Commit · Deliver Results.

42.4 Hard Questions

43Hard Questions Bank — Rapid-Fire

A scrollable pool of 60+ hard questions across all areas. Sprinkle through the interview; never ask all of them.

43.1 Core Web

1. Explain the rendering pipeline. Where is the bottleneck in a typical SPA?
2. Walk through what happens when you type a URL and hit Enter.
3. What's the difference between the DOM and the render tree?
4. Why is animating transform cheaper than top?
5. How does the browser decide what's a compositing layer?
6. What's a forced synchronous layout? How do you detect it?
7. What does requestAnimationFrame do that setTimeout doesn't?
8. Why are passive event listeners important for scroll performance?

43.2 JavaScript & TypeScript

1. Implement Promise.all from scratch. Now Promise.allSettled.
2. Implement a debounce. Now a leading-edge throttle.
3. Write a curry function. Now a pipe function.
4. Explain prototype chain vs class inheritance.
5. What's the iteration protocol? Build a custom iterable.
6. Implement deep clone without structuredClone.
7. Write an LRU cache.
8. Explain generators and how they enable async iteration.
9. Type a generic pick function with key inference.
10. Build a discriminated union for an API response.

43.3 React

1. Why are hook calls order-sensitive?
2. Implement useDebouncedValue.
3. Implement useEventCallback (stable identity, latest closure).
4. What does useTransition do? Give a concrete example.
5. How does React decide a component should re-render?
6. What's the difference between useMemo and useRef?
7. When is useEffect the wrong tool? What's right?
8. Explain selective hydration.
9. What can a Server Component not do?
10. Why is React Compiler important for INP?

43.4 Performance

1. LCP regressed from 2.0s to 3.5s overnight. No deploys. Investigate.
2. Bundle is 600 KB. Cut to 200 KB. How?
3. INP is 600 ms on mobile. Plan.
4. Explain Long Animation Frames vs Long Tasks.
5. How do you set up a performance budget that actually blocks PRs?
6. Why is preconnect different from preload?
7. What does HTTP/2 give you that HTTP/1.1 didn't?
8. Walk me through optimizing TTFB for a Next.js app.

43.5 Security

1. Walk through OAuth 2.1 with PKCE end-to-end.
2. Difference between XSS and CSRF — defenses for each?
3. What's the danger of localStorage for tokens?
4. How would you implement a strict CSP for a React app?
5. Explain Trusted Types.
6. What's Subresource Integrity, when does it fail?
7. Walk through threat-modeling a "share via link" feature.

43.6 Architecture & System Design

1. Design a news feed for 50M MAU.
2. Design Google Docs-style collaborative editor.
3. Design an autocomplete for a search engine.
4. Design a video player with adaptive bitrate.
5. Design Slack's chat client.
6. Design a company-wide design system used by 50 teams.
7. Design infinite scroll with 100k items.
8. Walk through micro-frontends — when, why, and the gotchas.
9. Module Federation in production: name three problems and the fixes.
10. How do you cache-invalidate across CDN + SW + client cache?

43.7 Leadership

1. Tell me about a technical decision you reversed.
2. How do you raise the bar without breaking team velocity?
3. Walk me through a migration you led.
4. An engineer keeps shipping 1500-line PRs. What do you do?
5. Your team is burned out. How do you address it?
6. Two senior engineers disagree on architecture. How do you resolve?
7. Tell me about a failed project. What did you learn?
8. How do you decide what tech debt to pay down first?
9. How do you mentor someone into senior?
10. What's your hiring bar? Defend it.

44Reference Library

Curated authoritative sources. Bookmark these.

44.1 Specs & Standards

• MDN Web Docs — the canonical Web reference
• HTML Living Standard (WHATWG)
• W3C Technical Reports
• TC39 — JavaScript Process
• WCAG 2.2
• ARIA Authoring Practices
• IETF Datatracker (RFCs)
• W3C Design Tokens Spec

44.2 Engineering Blogs

• Meta Engineering
• Airbnb Engineering
• Uber Engineering
• Netflix Tech Blog
• Shopify Engineering
• Stripe Engineering
• Discord Engineering
• GitHub Engineering
• Slack Engineering
• Figma Engineering
• Linear blog
• Vercel Engineering
• Cloudflare blog
• Anthropic news & engineering
• ThoughtWorks Insights

44.3 People to Follow

• Dan Abramov — Overreacted
• Addy Osmani
• Josh Comeau
• Jake Archibald
• Kent C. Dodds
• Will Larson — Irrational Exuberance
• Martin Fowler
• Matt Pocock — Total TypeScript
• Harry Roberts — CSS Wizardry
• Smashing Magazine
• TkDodo — React Query internals
• Ben McCormick

44.4 Performance & Web Vitals

• web.dev (Google's web team)
• 3perf — Ivan Akulov
• Calibre — perf monitoring posts
• cssperf — Stoyan Stefanov

44.5 Architecture & System Design

• GreatFrontEnd
• SystemsExpert
• System Design Primer
• System Design Newsletter
• StaffEng Stories

44.6 Tools (canonical docs)

• React
• Next.js
• React Router
• TanStack (Query, Router, Table, Virtual, Form, Start)
• Vite
• Vitest
• Playwright
• Storybook
• Radix UI
• React Aria
• shadcn/ui
• Tailwind
• Zod
• react-hook-form
• Zustand
• Jotai
• Redux Toolkit
• XState (Stately)
• Module Federation
• Turborepo
• Nx
• Biome
• OpenTelemetry
• Cloudflare Workers

44.7 Books

• "High Performance Browser Networking" — Ilya Grigorik (free online)
• "Designing Data-Intensive Applications" — Martin Kleppmann
• "Refactoring" — Martin Fowler
• "You Don't Know JS" — Kyle Simpson (free on GitHub)
• "Inclusive Components" — Heydon Pickering
• "Atomic Design" — Brad Frost (free online)
• "Staff Engineer" — Will Larson
• "The Manager's Path" — Camille Fournier
• "Accelerate" — Forsgren, Humble, Kim (DORA)
• "An Elegant Puzzle" — Will Larson

44.8 Newsletters Worth Subscribing

• Bytes (Ui.dev)
• The Pragmatic Engineer
• This Week in React
• Frontend Focus
• Smashing Newsletter
• CSS Weekly
• JavaScript Weekly
• LeadDev

44.9 Closing Note

45Market Reality — What Top Companies Actually Hire For

Distilled from 2026 Senior/Lead Frontend Engineer job descriptions at Airbnb, Anthropic, Vercel, Netflix, Uber, Stripe, Meta. Use this to calibrate what really matters.

45.1 The Universal Bar (in every JD)

• 5+ years of professional experience; 2+ years on consumer-facing or production-scale apps.
• Deep React + TypeScript — table stakes, not differentiator. Advanced TS (generics, conditional types, discriminated unions) explicitly mentioned.
• Core web fundamentals — HTML semantics, CSS layout, browser internals, network protocols. Not assumed; tested.
• Performance ownership — Core Web Vitals literacy, real-user monitoring, perf budgets.
• Accessibility — WCAG 2.2 AA mentioned in every senior+ JD post-EAA (June 2025).
• Testing strategy — not just "writes tests" — owns testing philosophy across unit/integration/E2E.
• System design ability — verbal walkthrough of large frontend architectures.
• Collaboration evidence — cross-functional with design, product, backend, infra.

45.2 Company-Specific Emphasis Patterns

45.3 The Hidden Bar — What Senior Means in 2026

From Noor Mohamad — Six FE Capabilities (May 2026) and MockExperts — FE Engineering 2026:

1. Rendering pipeline literacy — explain LCP and CLS from the browser's perspective, not from Lighthouse output.
2. Network & performance optimization — at the same depth a backend engineer understands DB indexing.
3. Server vs client boundary for RSC — knowing what runs where, why, and the perf consequence.
4. Architectural opinion — Module Federation vs single-spa vs iframe; defend a position.
5. Testing as a system — pyramid shape, flake management, what to skip.
6. Product judgment — pushing back on requirements that hurt users.

45.4 What "Lead" Adds on Top of Senior

• RFC / ADR authorship — written communication is the leverage point.
• Cross-team influence without authority.
• Mentoring 2–4 engineers with measurable growth.
• Migration leadership — bringing a team off a deprecated stack without melting velocity.
• Incident command experience — has run a production incident as IC.
• Hiring contributions — interview loop owner, candidate calibration sessions.

45.5 Decoded — How to Read Between the JD Lines

45.6 References

• Airbnb — Senior FE Engineer, Reliability Experience
• Airbnb — Senior FE, GraphQL & Networking Platform
• Anthropic Careers
• Anthropic comp data — Levels.fyi
• Prepfully — Uber FE interview process
• Exponent — Netflix SWE interview 2026
• Glassdoor — Vercel Senior SWE
• FrontendLead — Netflix FE questions
• FrontendLead — Uber FE questions
• interviewing.io — Netflix interview guide

46Staying Current — A Sustainable Learning System

The field shipped more in the last 3 years than the prior decade. The signal you can keep up — not that you already know it — is what gets you hired and keeps you employable.

46.1 The Layered Learning Routine

46.2 Daily — Newsletters & RSS

Curate ruthlessly. Subscribing to 30 newsletters is the same as zero — you'll mark them read without reading.

• Bytes — short, funny, weekly. Best entry-point newsletter.
• The Pragmatic Engineer (paid) — Gergely Orosz; engineering culture at scale.
• This Week in React — Sébastien Lorber; comprehensive React + RN.
• Frontend Focus — Cooperpress; weekly link roundup.
• JavaScript Weekly — Cooperpress; language news.
• CSS Weekly — Zoran Jambor; CSS-only.
• TypeScript Weekly — language updates.
• LeadDev — engineering leadership; staff+ focus.
• System Design Newsletter — Neo Kim; weekly architecture explainer.
• Engineering Leadership — Gregor Ojstersek.

46.3 Weekly — Deep-Dive Sources

• Web platform releases — web.dev blog, Chrome for Developers, WebKit blog, Mozilla Hacks.
• React — react.dev/blog, React Working Groups discussions, overreacted.io.
• Frameworks — Next.js blog, Remix/RR blog, Vercel blog, Svelte blog.
• Engineering blogs — see Section 44.2.
• RFCs / proposals — TC39, WHATWG HTML, CSS WG drafts.

46.4 Communities Worth Joining

• Twitter/X — still where new releases break first. Curate aggressively; mute liberally.
• Bluesky — increasingly where web standards / React people are migrating.
• Reactiflux Discord — React-focused community.
• r/reactjs, r/javascript, r/typescript, r/webdev, r/ExperiencedDevs.
• Hacker News — discover; don't doom-scroll.
• Local meetups — Meetup.com, LeadDev events, framework-specific.

46.5 Conferences to Watch (recordings are free)

• React Conf (Meta)
• Reactathon / React Miami / React India regional
• Next.js Conf
• JSNation (Amsterdam)
• React Summit
• CSSConf EU
• SmashingConf
• LeadDev (leadership)
• Staff+ Summit
• Google I/O Web track
• Apple WWDC Web sessions

46.6 Podcasts (commute material)

• Syntax — broad, beginner-friendly.
• ShopTalk Show — CSS-heavy.
• JS Party — language, ecosystem.
• Full Stack Radio — Adam Wathan (Tailwind).
• PodRocket — LogRocket, modern stack.
• React Podcast.
• Stack Overflow Podcast.

46.7 Long-Form & Books (quarterly)

See Section 44.7 — Books. Build a 2-books-per-quarter habit; mix one technical (e.g., DDIA) with one leadership (e.g., Staff Engineer).

46.8 The "Read on Schedule" Stack

Set up an RSS reader (Feedly, Inoreader, Reeder). Subscribe to engineering blogs (Section 44.2), newsletters, GitHub release feeds for libraries you use. Read for 15 min daily; never let the queue build past 100.

46.9 Track What You Learn

Keep a personal "learning journal" — a markdown file, an Obsidian vault, a Notion page. One entry per learning, ~3 sentences: what, why it matters, link to source. After a year you'll have 200+ entries — interview gold, promotion packet evidence, blog-post seed material.

47Practice Platforms & Exercise Bank

Reading about interviews ≠ being ready. Practice with the same intensity and structure you'd practice a musical instrument.

47.1 The Top Practice Platforms (2026)

47.2 Curated Practice Problems by Level

Warm-up (30 min each)

• Implement debounce, throttle, memoize, curry.
• Implement Promise.all, Promise.allSettled, Promise.race, Promise.any.
• Deep clone an object (without structuredClone); flatten a nested array; group by.
• Implement EventEmitter / pub-sub.
• LRU cache.
• String compare with version semantics (1.2.10 vs 1.2.2).

Component-level (45–60 min)

• Build an autocomplete with debounce, cancellation, keyboard nav, ARIA.
• Build a virtualized list (no library).
• Build a modal with focus trap, ESC, click-outside, restore focus.
• Build a multi-step form wizard with URL state per step.
• Build infinite scroll using IntersectionObserver.
• Build a star-rating component (controlled + uncontrolled).
• Build a sortable / draggable list (mouse + keyboard).
• Build a tabs component with the Compound pattern + ARIA.
• Build a tooltip that auto-positions (collision detection).
• Build a video player with custom controls + captions toggle.

Mini-app (90–120 min)

• Pokemon / Starwars API explorer (from your existing probe exercises).
• Tic-tac-toe → Connect 4 → Chess board (UI only).
• Real-time stock ticker (WebSocket / SSE).
• Kanban board with drag-drop and persistence.
• Markdown previewer with syntax highlighting.
• Pomodoro timer with persistence + notifications.
• Reddit-style nested comment thread.

System design (45–60 min verbal)

• Twitter / X feed.
• Slack / chat client.
• Google Docs / collaborative editor.
• Autocomplete (Google search bar).
• Photo sharing (Instagram-like).
• Video streaming UI (Netflix-like).
• E-commerce checkout flow.
• Email client.
• Stock trading dashboard.
• Multi-tenant admin dashboard.

47.3 The 6-Week Interview Sprint Plan

47.4 Build a Visible Portfolio Project

One real project under your GitHub beats five toy exercises. Pick a real problem; ship to production; write a 2-page README that includes:

• Problem statement (one paragraph).
• Architecture diagram.
• Trade-offs you considered and the one you picked, with rationale.
• Performance budget + measured results (Lighthouse / RUM).
• Accessibility audit (axe / Lighthouse).
• What you'd do differently.

This becomes the "tell me about a project" anchor in every interview.

47.5 References

• GreatFrontEnd questions catalog
• BFE.dev problem list
• FE Interview Handbook (GitHub)
• FE Interview Preparation Kit (GitHub)
• JS Questions (Lydia Hallie)
• React JS Interview Questions
• JS Interview Questions (Sudheer)

48Technical Communication Snippets — Sound Like a Lead

Memorize these. They are the verbal scaffolding that makes ordinary technical content sound like senior-engineer reasoning. Use the exact phrases; over time they become natural.

48.1 Opening a Coding Problem

The first 60 seconds set the tone. Never start typing. Always restate + clarify + plan.

48.2 Talking While Coding

Silent coding feels long to the interviewer. Narrate your thought process — but only the non-obvious parts.

48.3 When You Don't Know Something

"I don't know" delivered confidently is one of the strongest signals. Faking knowledge is the fastest way to fail.

48.4 Explaining Trade-offs (the Lead Signal)

The single most under-used phrase in interviews. Use "trade-off" 5+ times per interview.

48.5 Handling Pushback or Disagreement

Lead candidates are tested on whether they can be challenged without crumbling — and without dying on the hill.

48.6 Wrapping Up an Answer

Bad answers trail off. Good answers land.

48.7 System Design Interview Phrases

48.8 Behavioral (STAR) Phrases

48.9 Questions to Ask the Interviewer (End of Loop)

Asking good questions is half the interview signal. Have 5–6 prepared; pick based on what you've heard.

48.10 Confidence-Building Verbal Hygiene

48.11 Quick Rehearsal Drills

• Mirror drill — answer 3 behavioral questions out loud to your mirror, twice a week. You'll instantly hear filler words.
• Recording drill — record yourself answering a system design question. Play back at 1.5× speed; the awkward moments compress into obvious patterns.
• 2-sentence drill — every technical concept you know, write a 2-sentence explanation. Forces compression. (Try: hydration, CSP, useMemo, RSC, INP.)
• Trade-off drill — every time you read about a tech, write down its trade-offs vs the alternative. After a month, this is reflexive in conversation.
• "Why" drill — when someone explains a decision to you, ask "why" 3 times. Then practice answering 3 levels deep on your own decisions.

48.12 References

• Gayle Laakmann McDowell — Cracking the Coding Interview (verbal patterns chapter)
• Carmine Gallo — Talk Like TED
• Patrick Winston — How to Speak (MIT, free)
• HBR — How to Speak Like a Leader

49Mock Interview Drills — Self-Practice Routines

Solo practice beats no practice. Structured solo practice beats unstructured group practice.

49.1 The Daily 45-Minute Routine

49.2 The Weekly Mock

Once a week, do a full 45–60 minute mock with someone else. Options:

• Pramp — free peer matches; reciprocal practice.
• interviewing.io — paid mocks with ex-FAANG engineers.
• A friend in the industry — trade mocks; honest feedback > polite feedback.
• An AI mock — use Claude / ChatGPT to role-play the interviewer; surprisingly effective for behavioral practice.

49.3 The Recording Loop (the highest-ROI drill)

1. Pick a problem. Set a 45-minute timer.
2. Talk it out loud as if interviewer is in the room. Record screen + audio.
3. Stop at 45 min regardless of completion.
4. Watch it back at 1.5× speed.
5. Note 3 specific things — one verbal habit, one missed concept, one structural issue.
6. Pick one to fix; redo the next day.

If you do this 3× a week for a month, your interview self is unrecognizable from your start point. Recording is uncomfortable; do it anyway.

49.4 The Behavioral Story Workshop

1. Make a list of 8 stories from your career (use Section 42.2 categories).
2. For each, write a STAR outline (4 bullets, max 200 words).
3. Practice each out loud — target 90 seconds for "tell me about a time" answers.
4. Time yourself; if you exceed 2 minutes, you're rambling. Trim.
5. Get a friend to ask follow-ups — "what specifically did you do?", "what was the metric?" — to stress-test your answer's specifics.

49.5 The AI Rubber-Duck Loop

Use Claude or ChatGPT as a relentless follow-up generator. Prompt template:

You are a senior frontend engineer interviewing me for a Lead role.
Ask me [X — e.g., a system design question for "design Twitter feed"].
After my answer, ask 3-5 follow-up questions that probe weak spots.
Be tough but constructive. Do not give answers — only ask.

The AI will probe corners you didn't anticipate. Better than a friend who doesn't know the domain; cheaper than a paid mock.

49.6 The "Explain to a Junior" Drill

For every concept you intend to discuss in an interview, prepare two versions:

• 30 seconds — what it is, why it matters, one example.
• 3 minutes — the same plus trade-offs and one war story.

If you can't compress to 30 seconds, you don't understand it yet. Compression is mastery.

49.7 The Failure-Mode Calendar

Track your interview attempts in a simple table:

This becomes your personalized weakness map.

49.8 Mock Interview Templates to Run Yourself

Template A — JS / TS warm-up (15 min)

• Implement a debounce with cancel.
• Type a generic pick function with full key inference.
• Explain a stale closure and how you'd fix it.

Template B — Component build (45 min)

• Build an accessible modal with focus trap.
• Discuss state management choice mid-build.
• Add keyboard handling under interviewer probe.

Template C — System design (45 min)

• Run RADIO end-to-end on a feed/chat/editor problem.
• Force yourself to draw (paper or whiteboard).
• Stop at 45 min — even mid-thought.

Template D — Behavioral (30 min)

• 5 rotating prompts: failure, conflict, leadership, mistake, scope-cut.
• Limit each answer to 90 seconds.
• Self-grade: did you say "I" or "we"? Specific or vague? Quantified outcome?

50Communication Anti-Patterns — What Kills Interviews

Even strong engineers tank interviews on these. Most are habits you can break in 2 weeks of deliberate practice.

50.1 The Top 10 Killers

1. Silent coding. The interviewer can't read your mind. 5 minutes of silent typing reads as "doesn't know what they're doing."
2. Diving in without clarifying. Skipping requirements is the #1 reason senior candidates get downleveled. Spend 3–5 minutes asking.
3. Saying "we" instead of "I". Behavioral round killer. Interviewers explicitly listen for "I" — they want to know your contribution.
4. Rambling. Hard cap your answers at 2 minutes; pause and ask "want me to keep going?"
5. Pretending to know. Always fails. Interviewers ask exactly the question they know you don't know to test honesty.
6. Defending a wrong answer to the death. Showing you can update is more important than being right.
7. Not asking any questions back. Reads as low curiosity. Always have 5 prepared.
8. Filler-word storms. "Um", "like", "kind of", "sort of", "basically" — each one chips at your authority.
9. Pre-undermining. "This is probably wrong but…" — never. State your answer; let them judge.
10. Tangents. Answering a different question than the one asked. Listen to the actual question; answer the actual question.

50.2 Body Language & Presence (Video Interview)

• Camera at eye level — not below, not above. Stack books under your laptop.
• Look at the camera when delivering a key point, not at the screen.
• Lighting in front of you, not behind — face a window, not back to one.
• Quiet background — no notifications, phone on silent in another room.
• Sit up, hands visible — slouching reads through camera.
• Smile in the first 10 seconds — it sets the room temperature.
• Don't read from notes mid-answer — eye drift is obvious. Notes for question prompts only.

50.3 The "Sound Senior" Vocabulary Substitutions

50.4 Specific Failure Modes to Train Away

50.5 What to Do If You Freeze

1. Acknowledge it. "Give me 30 seconds — I want to think through this one." Then actually take 30 seconds. Don't talk through the silence.
2. State the problem out loud. Restating often unsticks you. "So we need to [X], the constraint is [Y]…"
3. Reach for first principles. "Let me reason from basics — what does the user need?"
4. Reach for an analogous problem. "This reminds me of [other problem]. Is the same shape applicable here?"
5. If still stuck, ask for a hint. "I'm not seeing the obvious path forward. Could you give me a nudge?" — interviewers expect this; using it once is fine.

50.6 Energy & Pacing

• Match interviewer energy. If they're warm, be warm. If they're terse, be precise.
• Slow down on important points. Rushing through a key trade-off signals you don't realize it's important.
• Take water breaks. Sipping water is a legitimate way to buy 3 seconds. Keep a glass in frame.
• Don't fill silence. 5 seconds feels long to you; sounds confident to them.
• End on a high note. The last 2 minutes are remembered most. If you stumbled mid-interview, finish strong with a thoughtful question and a clear closing.

50.7 The "Last 10 Minutes" Playbook

1. If anything went unfinished, address it: "Earlier I said [X] — I want to come back and clarify."
2. Ask your prepared questions (Section 48.9). Pick 2–3 based on what the conversation revealed.
3. Show genuine interest in their answers — follow up on at least one.
4. Express your specific interest: "What you said about [X] is exactly the kind of problem I'd want to work on. I'd love to hear more about that team."
5. Thank them warmly and concretely — "Thanks for the conversation — I particularly enjoyed the [X] discussion."

50.8 After the Interview

• Write a thank-you note within 24 hours. 3–4 sentences. Reference something specific from the conversation.
• Journal what went well and what didn't — while it's fresh. This is your most valuable learning data.
• Don't replay endlessly. Two passes: one for lessons, one for closure. Then move on.
• Treat rejection as data, not verdict. A rejection from one company calibrates one signal — not your worth.

50.9 The 30-Day Communication Improvement Plan

50.10 Final Word

50.11 References

• Patrick Winston — How to Speak (MIT lecture, 1 hour, transformative)
• HBR — Speaking Like a Leader
• Matthew Dicks — Storyworthy
• Carmine Gallo — Talk Like TED
• Will Larson — Communication Personalities
• StaffEng — Communication Skills

51JavaScript Core — Everything an Engineer Should Know

Past the syntax. The model. What the engine actually does. Every snippet below is editable and runnable — experiment, break things, change values, hit Run again. This is the section to come back to before any senior interview.

51.1 The Execution Model — Stack, Heap, Queues, Loop

JavaScript is single-threaded with a concurrency model built on the event loop. The runtime has:

• Call stack — synchronous function frames; LIFO.
• Heap — where objects live; managed by the GC.
• Macrotask queue — setTimeout, I/O, UI events, message events.
• Microtask queue — Promise reactions, queueMicrotask, MutationObserver. Drained completely between every macrotask.
• Render steps — requestAnimationFrame callbacks → style/layout/paint → requestIdleCallback.

References: HTML spec — event loops · Jake Archibald — In The Loop (JSConf.Asia) · Philip Roberts — What the heck is the event loop anyway?

51.2 Closures, Scope & Hoisting

A closure is a function that retains access to its lexical scope after that scope has finished executing. Lexical scope is fixed at write time, not call time. Closures power: data hiding, module patterns, currying, memoization, React hooks themselves.

51.3 The this Binding

Four precedence rules + one exception for arrows:

1. new binding — this is the newly constructed object.
2. Explicit binding — .call(obj) / .apply(obj, args) / .bind(obj).
3. Implicit binding — method call obj.fn(); this is obj.
4. Default — undefined in strict mode; global in sloppy.

Arrows have no this of their own — they capture the enclosing lexical this.

51.4 Prototypes & Inheritance

Every object has an internal [[Prototype]] pointer (accessible via Object.getPrototypeOf) forming a prototype chain. Property lookups traverse this chain. class is sugar over function prototypes.

51.5 Type System & Coercion Rules

JS has 8 types: string, number, boolean, null, undefined, symbol, bigint, object. Coercion happens with ==, +, -, <, etc. Understanding the rules is the difference between writing code and debugging it.

51.6 Promises & Async Internals

A Promise is a state machine: pending → fulfilled | rejected. Once settled, it never changes. Promise reactions are microtasks. Understanding microtask scheduling explains most async surprises.

51.7 Iterators & Generators

The iteration protocol underpins for…of, spread, destructuring, Array.from. Generators give you lazy, pausable functions. Async generators stream data.

51.8 Proxy & Reflect — Meta-Programming

A Proxy intercepts fundamental operations on an object (get, set, has, deleteProperty, etc.). This is how reactivity systems (Vue 3, MobX 6, Valtio) work — and how some bundlers do automatic dependency tracking.

51.9 Memory — GC, Weak References, Leak Patterns

V8 uses generational GC: young generation (fast Scavenger) and old generation (Mark-Sweep + Mark-Compact). You don't free memory — you stop referencing it.

• WeakMap, WeakSet — keys held weakly; GC can collect them.
• WeakRef — hold a reference that doesn't prevent collection.
• FinalizationRegistry — cleanup hook after GC.

51.10 Symbols & Well-Known Symbols

A Symbol is a unique primitive — used as a hidden / collision-proof property key. Well-known symbols let you customize built-in behavior.

51.11 Property Descriptors — Below the Dot

Every property has hidden flags: writable, enumerable, configurable, plus either a value (data descriptor) or get/set (accessor descriptor). This is how Object.freeze, const-like read-only behaviour, and computed properties work under the hood.

Three levels of immutability:

• Object.preventExtensions — can't add new properties.
• Object.seal — above + can't delete or reconfigure.
• Object.freeze — above + can't modify values. Shallow — nested objects still mutable.

51.12 Modules — ESM, CJS, Dynamic, Top-Level Await

// ESM
import { fn } from './mod.js';     // static; tree-shakable
const mod = await import('./mod.js'); // dynamic; code-splitting
export const x = 1;
export default function () {}

// Import maps (browser, Deno, modern bundlers)
<script type="importmap">
{ "imports": { "lodash": "https://esm.sh/lodash-es" } }
</script>
<script type="module">import _ from 'lodash';</script>

// CJS — Node legacy
const { fn } = require('./mod');
module.exports = { fn };

51.13 Numbers, BigInt & Intl

51.14 Strings, Unicode & Code Points

Strings are sequences of UTF-16 code units. Most "characters" you care about are code points, some of which take two code units (surrogate pairs). This bites when emoji or non-BMP scripts appear.

51.15 Modern Regex

Named groups, lookbehind, the unicode /v flag with set notation, sticky /y for tokenizers.

51.16 Functional Patterns You'll Actually Use

51.17 Error Handling — Beyond try/catch

51.18 Modern Array Methods — Mutating vs Immutable

51.19 Modern Scheduling APIs

Beyond setTimeout: the Scheduler API gives priority-aware task scheduling. scheduler.yield() is the modern way to break up long tasks for better INP.

51.20 Lower-Level Topics — Performance, Memory Layout, Engine Quirks

V8 Hidden Classes & Inline Caching

V8 assigns each object a hidden class based on its property layout. Adding properties in the same order to many objects keeps them on the same hidden class → fast. Adding in different orders creates separate hidden classes → slow polymorphic access.

Typed Arrays — Contiguous Memory

Regular arrays are sparse object-like. Int32Array, Float64Array, etc. are contiguous fixed-type buffers — 10–100× faster for numeric work.

Tail Calls, Recursion Limits, Stack Depth

JS engines (except Safari briefly) don't implement proper tail call optimization. Deep recursion blows the stack. Solution: iterative form, or trampoline pattern.

Object Identity vs Equality

JS has four equality semantics: === (Strict Equality), == (Loose Equality), Object.is (SameValue), and SameValueZero (used by Map/Set/Array.includes).

51.21 Interview Classics — Implement From Scratch

These are the most-asked "implement X" questions at FAANG/Anthropic/Vercel. Practice each in the editor; aim to type them from memory.

51.22 Low-Level Building Blocks for Product Work

Structured Cloning & Transferable Objects

const cloned = structuredClone(complexObject);   // deep clone with cycles, Maps, Dates

// Transferable (zero-copy ownership transfer to a Worker)
const ab = new ArrayBuffer(1024 * 1024);
worker.postMessage(ab, [ab]);     // `ab` is now neutered on this side

SharedArrayBuffer + Atomics (multi-thread shared memory)

Requires Cross-Origin-Opener-Policy: same-origin + Cross-Origin-Embedder-Policy: require-corp. Used by: video editing in browser, WASM threads, audio processing.

BroadcastChannel — cross-tab pub/sub

Performance APIs

// High-resolution timing
const start = performance.now();
doWork();
console.log(performance.now() - start, 'ms');

// User Timing API — show up in DevTools Performance panel
performance.mark('checkout-start');
performance.mark('checkout-end');
performance.measure('checkout', 'checkout-start', 'checkout-end');

// PerformanceObserver — listen for long tasks, layout shifts, LCP
new PerformanceObserver(list => {
  list.getEntries().forEach(e => console.log(e.entryType, e.duration));
}).observe({ entryTypes: ['longtask', 'layout-shift', 'largest-contentful-paint'] });

Long Animation Frames (LoAF) — replaces Long Tasks

The successor API for INP debugging. Reports per-frame work + script + render time. web.dev — Long Animation Frames

51.23 Hard JS Questions Asked at Top Companies

51.24 References for Deep Mastery

• You Don't Know JS (Kyle Simpson)
• Exploring JS (Dr. Axel Rauschmayer)
• V8 Engineering Blog
• Mathias Bynens — JS Unicode
• 2ality — Axel's posts on TC39 proposals
• ECMAScript 262 spec (the standard)
• TC39 active proposals
• Sudheer Jonna — JS Interview Questions
• Lydia Hallie — JavaScript Questions
• BFE.dev — practice implementing primitives