The frontend interview: React, CSS, and the browser

01A frontend interview is several small interviews

People prep for "the frontend interview" like it's one thing. It isn't. It's a *bundle* of small evaluations, and each one is looking for a different signal. If you walk in expecting a single coding test, the UI-build round blindsides you. If you only practise building components, the "how does the browser work" round catches you flat. Knowing the shape of the day is half the battle.

The rounds vary by company, but they're drawn from the same small deck. Most loops pick four or five of these. Almost none skip the live UI build, that one is the heart of a frontend interview.

• UI build / component challenge — build a working thing in the browser, live, while they watch.
• JavaScript fundamentals — closures, the event loop, promises, this, sometimes implementing debounce or a tiny event emitter from scratch.
• CSS and layout — center this, make this responsive, why is this element overflowing, explain the box model.
• "How the browser works" — what happens between typing a URL and seeing pixels, the DOM, reflow vs repaint, the render path.
• DSA-lite — a lighter algorithms round than backend roles get. Arrays, strings, maybe a tree because the DOM is a tree. Rarely dynamic programming.
• Frontend system design — "design an autocomplete", "design an image carousel", "design a data table that handles 10k rows." Components, state, data flow, performance, not load balancers.

Backend interviews ask "can you reason about systems?" Frontend interviews ask "can you build something a human will actually use, and explain why it behaves the way it does?"

02The rounds, what each one assesses, and how to prep

Each round is fishing for a specific signal. Once you know the signal, prep gets focused. You stop grinding 300 algorithm problems for an interview that has one easy array question and four rounds about the browser.

03The fundamentals they quietly probe

These come up everywhere, woven into other rounds. An interviewer building autocomplete with you will casually ask "why wrap the handler in a closure here?" or "this fires on every keystroke, what's the cost?" They're checking the foundation under the framework. React sits on JavaScript, JavaScript sits on the browser. They want to see you understand the layers below the one you usually work in.

• Closures — a function remembering the scope it was defined in. The basis of useState, event handlers that capture values, and most "why is this variable stale?" bugs.
• The event loop — why JavaScript is single-threaded but non-blocking. Call stack, task queue, microtasks. Why a Promise.then runs before a setTimeout(0).
• Promises and async/await — what a promise actually is, how await pauses, error handling with try/catch, why Promise.all beats awaiting in a loop.
• `this` — how it's set by call site, the difference between regular and arrow functions, why arrow functions fixed a whole class of this bugs.
• The DOM — it's a tree, not the HTML you wrote. How the framework builds and updates it for you, and what a "DOM node" actually is.
• Reflow vs repaint — reflow recalculates layout (expensive), repaint redraws pixels (cheaper). Why reading offsetHeight in a loop tanks performance.
• Accessibility and semantic HTML — a <button> is not a <div onClick>. Keyboard focus, labels, roles, why semantics give you behavior and a11y for free.

04React-specific signals

If the role is React, the interview probes whether you understand the model, not just the syntax. Plenty of people can wire up useState. Fewer can explain *why* a component re-rendered, or when reaching for a library is the wrong move.

• State vs props — props come from the parent and are read-only; state is owned by the component and triggers a re-render when it changes. Knowing where a piece of data should *live* is half of React design.
• Reconciliation — when state changes, React re-renders and diffs the new tree against the old one, updating only what changed. This is why key matters in lists: it tells React which item is which.
• Rules of hooks — call them at the top level, in the same order, every render. Not in conditions or loops. Understand *why*: React tracks hooks by call order, not by name.
• When NOT to reach for a library — a toggle doesn't need a state manager. A two-field form doesn't need React Hook Form. Knowing when the platform or a few lines of useState is enough is a senior signal.

05The live UI build: how to talk while you build

This is the round people dread, and the one that matters most. You'll get a prompt like "build a star rating component" or "build a search box that filters this list," a blank editor, and someone watching. The trap is going silent and coding head-down. They aren't grading the final pixels as much as *how you work*. Narrate, and a stumble becomes a thinking-out-loud moment instead of a frozen screen.

1. 1

   Clarify before you type

   Restate the task and ask two or three sharp questions. "Single or multi-select? Should it be keyboard accessible? Is the data already here or do I fetch it?" This buys thinking time and shows you scope before you build.

2. 2

   Say the plan out loud

   "I'll start with the markup, then local state for the selection, then wire the click handler, then handle the keyboard and empty states." Now they know your path and can nudge you if you're heading somewhere they don't want.

3. 3

   Ship the dumbest working version first

   Get something on screen that does the core thing, even if it's ugly and hardcoded. A working skeleton beats a half-built perfect plan. It also de-risks the round: if time runs out, you have a working thing.

4. 4

   Narrate as you go

   "I'm lifting this into state so the parent can read it... I'll use a button here, not a div, so I get focus and Enter for free." Every sentence is a signal. Silence is the enemy.

5. 5

   Refine in passes

   Now layer in the things that separate strong from average: loading, error, and empty states; accessibility; an edge case or two. Call each one out: "Let me handle the empty case, what should this show with zero results?"

6. 6

   Sweep the edges out loud

   Before you say you're done, narrate the edges: "What if the list is empty? What if the fetch fails? Is this reachable by keyboard? Let me check the a11y quickly." Naming the gaps, even unfixed, scores higher than pretending they aren't there.

06Common failures, and how to talk through a component

Most live-build rounds are lost the same handful of ways. None are about not knowing enough. They're about *how* you spend the time and what you forget under mild pressure.

• Over-engineering — reaching for context, a reducer, and a custom hook to render a toggle. Solve the problem in front of you; mention scaling as a follow-up, don't build for it.
• Ignoring accessibility — <div onClick> instead of <button>, no labels, no keyboard support. A frontend role that ignores a11y is a tell, and it's easy to fix by reaching for semantic HTML first.
• No loading / error / empty states — wiring the happy path and stopping. Real UI spends most of its life in one of the other three states.
• Going silent — coding head-down so the interviewer can't follow your reasoning. Even a wrong turn, narrated, scores better than a correct one in silence.