Stop building screens. Start engineering the frontend.

The map before the journey. By the end: you can name the five interview formats companies actually run, place your own answers on the junior/mid/senior ladder, and you know which module your diagnostic score sends you to first.

• - Cold open — two minutes decide it
• - The hiring map — who hires frontend, and for what
• - The five formats
• - The ladder — one question, three levels
• - Diagnostic, part 1 — the browser and the language
• - Diagnostic, part 2 — types, React, architecture
• - Your score, and the map of the program
• - How to study this program · Build
• - The contract

Everything a framework hides from you. By the end: you can explain what happens between an HTML tag and a lit pixel, and name which of your own CSS changes costs a layout. This is the module that makes every React module afterwards make sense.

• - From HTML to pixels: the five stages of a frame
• - The DOM API is a shovel — querying without thrashing layout
• - Semantic HTML is an API, and the accessibility tree is its output
• - The box model decides your maths — content-box vs border-box
• - Formatting contexts: why flex and grid are not magic
• - Stacking and containing blocks — why z-index: 9999 did nothing
• - Reflow costs the CPU; compositing does not
• - Composition layers: what the GPU holds, and what it costs in VRAM
• - The event loop: tasks, microtasks, and the frame you just missed
• - Instrument a slow page and prove the fix · Build

You rebuild the interview utility library from zero. By the end: you can implement the utilities an interviewer asks for from an empty file, and explain why each one is written the way it is — fluency under a shared editor, not recall.

• - Execution contexts and the scope chain, drawn
• - Closures are not a trick question — they are how callbacks remember
• - this is decided at the call site, not the definition
• - Prototypes, and what class is hiding
• - Modules, bundling, and what import actually does at runtime
• - Callbacks → promises → async/await, and the states in between
• - Error handling across async boundaries
• - Memory, references and the leak your SPA has right now
• - Building the interview toolbelt, part 1: debounce and throttle
• - Building the interview toolbelt, part 2: deepClone, EventEmitter, promiseAll · Build

Types that make the wrong state impossible. By the end: you model a domain with types that make the wrong state unrepresentable, and you know the point where more types stop paying for themselves.

• - Structural typing: TypeScript does not care what you named it
• - Generics are parameters for types, nothing more
• - Narrowing, and the difference between unknown and any
• - Discriminated unions kill the five-boolean component
• - Utility and mapped types you will actually reach for
• - Typing async data, and where the lies get in
• - Schema validation at the boundary, types on the inside
• - tsconfig strictness, flag by flag, and what each one catches
• - Model the job board's domain end to end · Build

The mental model, not the API tour. By the end: you can explain a re-render you did not expect, and fix it without reaching for memo first. The render model is the spine of this module.

• - The render model: what React does between your state and the DOM
• - Fiber, lanes, and why rendering can be interrupted
• - Anatomy of a re-render — the four reasons a component runs again
• - Keys, reconciliation, and state landing on the wrong row
• - Hooks: state, effects, refs, and the closure trap
• - You might not need an effect — deriving instead of synchronising
• - Context, and why it re-rendered everything
• - Composition patterns that beat prop drilling
• - Error boundaries and portals
• - Suspense and concurrent rendering, plainly
• - Build the listings feed, then profile it · Build

The module a team lead will judge you on. By the end: you write components a reviewer can read — typed props, typed events, and state machines instead of boolean soup.

• - Typing props, children and refs without fighting the compiler
• - Typing events, forms and the handlers between them
• - Generic components: one Select, every option type
• - Polymorphic components and the as prop
• - Typed hooks and typed reducers
• - Discriminated state machines instead of five booleans
• - A typed API layer the UI can trust
• - Build the typed primitives the whole app will use · Build

The highest-ROI module for the live-coding round. By the end: you build the components an interviewer asks for live — keyboard-driven, ARIA-correct, no library underneath.

• - Component API design: data, event, config, style and slot props
• - Controlled, uncontrolled, and the one you actually want
• - Design tokens and a design system small enough to finish
• - The accessibility tree, focus, and the keyboard path
• - Build the search autocomplete — debounce and race conditions · Build
• - The ARIA combobox contract, attribute by attribute
• - Build the overlays — modal, dropdown, tabs, toast · Build
• - Focus traps, portals and live regions
• - Forms and validation without a form library
• - Virtualization from scratch: windowing, pooling, recycling · Build
• - Responsive behaviour that is not just breakpoints

Whose state is it — the server's or yours? By the end: you can say which state is the server's and which is yours — the distinction that decides mid versus senior — and defend where each piece lives.

• - Server state vs client state: the question most candidates fail
• - TanStack Query: the cache, and what invalidation really means
• - Optimistic updates, and the rollback everybody forgets
• - Race conditions in data fetching, and the two fixes
• - Type-safe routing and loaders
• - Search params are state — make the URL shareable
• - Normalization, and when a flat store earns its keep
• - Zustand, Redux Toolkit, and when each is the wrong choice
• - Real-time: polling, SSE and websockets compared
• - Rebuild the data layer on Query and Router · Build

A strategy per route — and where Next.js is the wrong answer. By the end: you pick a rendering strategy per route and defend it out loud, including the routes where reaching for Next.js is the wrong call.

• - The App Router mental model
• - Server Components vs Client Components — where the boundary goes
• - CSR, SSR, SSG, ISR and streaming, chosen per route
• - Data fetching and the caching layers, in order
• - Server actions and mutations
• - Route handlers, middleware and the edge
• - Auth and session patterns that survive a refresh
• - SEO, metadata, and the dashboard that must not be indexed
• - When NOT to reach for Next.js
• - Port the job board: public pages vs authed dashboard · Build

Prove the before and after with numbers. By the end: you set a performance budget, prove a before and after with real measurements, and ship it with tests green in CI.

• - Core Web Vitals: LCP, INP, CLS, and which one users feel
• - Measuring properly: the Performance panel, lab vs field
• - Lighthouse, CrUX, RUM — what each one can and cannot tell you
• - Bundles: analysis, code splitting, and the import that cost 300 KB
• - Images, fonts and the layout shift they cause
• - Memoization that actually helps, and the profiler that proves it
• - The testing pyramid: what to unit test, what to E2E
• - Testing behaviour with Testing Library, not implementation
• - Playwright and MSW: the tests that catch real regressions
• - XSS, CSRF, CSP and where to put a token
• - Baseline → budget → fix, with CI green · Build

A 45-minute design round, with a script. By the end: you run a 45-minute design round to a repeatable script — RADIO — and can defend the trade-offs of a codebase that has to scale past one team.

• - What a design round is actually scoring
• - RADIO: Requirements, Architecture, Data, Interface, Optimizations
• - Requirements: the questions that buy you the next twenty minutes
• - Component and data-flow architecture on a whiteboard
• - API and contract design from the client's side
• - Scaling the codebase 1 — the modular monolith
• - Scaling the codebase 2 — monorepos and what they actually fix
• - Scaling the codebase 3 — micro-frontends and their real cost
• - Six questions, walked: feed, autocomplete, chat, e-commerce, dashboard, editor

Assembly week, not build week. By the end: you ship one deployed job board you can defend line by line — and discover that most of it already exists on branches you wrote yourself.

• - Assembly week, not build week — what you already have
• - Wiring auth and protected routes end to end
• - The architecture story: writing down why, not what
• - Deploy, and the CI gate that keeps it green
• - The accessibility and performance pass you can defend
• - Capstone review against the senior checklist · Build

Every format, drilled under time. By the end: you have drilled every format against the clock, and you can think out loud without going quiet.

• - Thinking out loud: the skill nobody practises
• - The quiz round: 200 "why" questions, and how to answer in thirty seconds
• - The utilities round under time pressure
• - The UI round: clarify, scaffold, build, then polish
• - The design round, timed, with the RADIO script
• - Behavioural answers with STAR and a real trade-off
• - Take-home strategy: scope, README, and knowing when to stop
• - Building your own drill schedule from your module 1 score