Frontend interviews have diverged from general software interviews. Instead of one algorithm round repeated four times, a modern frontend loop tests five distinct things: whether you understand JavaScript at the runtime level, whether you know your framework's model rather than just its API, whether you can build a working component under time pressure, whether you can reason about client architecture, and whether you handle accessibility and performance without being prompted. This guide covers each round, the questions that recur, and what the interviewer is actually scoring.
The Five Rounds of a Frontend Loop
JavaScript fundamentals — 45 to 60 minutes
Closures, the event loop, promises, this binding, prototypes. Often delivered as small "what does this log, and why" exercises rather than definitions. The why carries most of the score — naming the behaviour correctly but explaining it wrongly reads as memorisation.
Framework round — 45 to 60 minutes
React for most companies. Reconciliation, hook semantics, render behaviour, state placement, and a debugging exercise on a component that re-renders too often or has a stale closure in an effect.
Live UI build — 60 to 90 minutes
Implement a real component from scratch, usually without a component library and often without internet access. Autocomplete, modal, infinite scroll, and multi-step form are the perennials. Working and accessible beats feature-complete and broken.
Frontend system design — 45 minutes, mid-level and above
Design the client side of a feature: component boundaries, where state lives, data fetching and caching, rendering strategy, and how it degrades on a slow network. Some loops replace this with a code review exercise instead.
Behavioral round — 45 minutes
Standard STAR-format questions, often weighted toward cross-functional work with designers and product, since that is the defining collaboration pattern of the role.
JavaScript Fundamentals: The Topics That Actually Recur
| Topic | How it gets asked | What is being scored |
|---|---|---|
| Closures | A loop that creates functions capturing the wrong variable | Whether you understand scope capture, not just the var/let fix |
| Event loop | Ordering of setTimeout, a resolved promise, and sync code | Macrotask versus microtask queues, and that microtasks drain first |
| Promises | Implement a small promise utility, or explain chaining vs nesting | Error propagation and that a then callback returns a new promise |
| this binding | A method extracted from an object and called bare | Call-site determines this; arrow functions capture lexically |
| Prototypes | Explain lookup, or extend a built-in safely | The prototype chain as delegation, not classical inheritance |
| Event delegation | One listener on a parent for many dynamic children | Bubbling, event.target versus currentTarget, and why it scales |
| Debounce vs throttle | Implement both from scratch | That you know which one a resize, scroll, or search box needs |
The pattern behind all of these
Every item above is asked as behaviour first and definition second. Interviewers show you code and ask what happens. Reciting a textbook definition of a closure scores poorly if you then predict the wrong output. Practise by predicting output before running it — that is the exact skill being tested.
React Round: Model Knowledge, Not API Knowledge
Anyone can look up a hook signature. Interviewers are probing whether you understand React's rendering model well enough to debug something unfamiliar. Six questions cover most of the round:
Why do keys matter, and why not the array index?
Keys let reconciliation match elements across renders. Index keys break the moment the list reorders or an item is removed, because component state and DOM nodes stay attached to positions rather than items — producing the classic bug where a deleted row leaves the wrong input value behind.
State or ref?
State when the value should drive rendering; a ref when it should not. A scroll position you display needs state; a timer id, a previous value, or a DOM node needs a ref. Storing render-irrelevant data in state is one of the most common causes of unnecessary re-renders.
When does an effect run, and what breaks?
After commit, and again whenever a dependency changes by reference. The two bugs interviewers plant are a stale closure reading an old value, and an object or function dependency recreated every render causing an infinite loop. Say out loud that you would check the dependency array first.
Why is derived state an anti-pattern?
Copying a prop into state creates two sources of truth that drift. Derive during render instead. The legitimate exception is a deliberately uncontrolled input seeded once from a prop — knowing that exception is itself a seniority signal.
When does memoisation actually help?
When the memoised work is genuinely expensive, or when a stable reference is required by a memoised child or an effect dependency. Wrapping every callback adds allocation and cache overhead for no gain. Expect at least one question where the correct answer is that memoising would not help and the real fix is moving state down.
Why does context cause wide re-renders?
Every consumer re-renders when the provider value changes identity, regardless of which part of the value it reads. Fixes: split contexts by update frequency, memoise the provider value, or move to a store with selector-based subscriptions.
The Live UI Build: What Separates Passes From Fails
This round has the widest spread in outcomes, and the differentiator is rarely raw coding speed. It is order of operations. Candidates who build the happy path, then loading, then error, then keyboard support, then polish, consistently outperform those who chase features and leave a broken component at the buzzer.
Five components cover most of what gets asked. Build each one from scratch, no library, before your loop:
Autocomplete
- Debounced fetch, cancel stale requests
- Arrow key navigation and Enter to select
- Loading, empty, and error states
- Combobox roles and active-option announcement
Modal / dialog
- Focus moves in, focus trapped, focus restored
- Escape closes, backdrop click closes
- Body scroll locked while open
- Rendered via portal, correct dialog role
Infinite scroll list
- IntersectionObserver sentinel, not a scroll handler
- No duplicate fetch while one is in flight
- Page-level error retained, retry available
- Announce new items to assistive tech
The other two worth rehearsing are a multi-step form with per-step validation and a back button that preserves entered data, and a star rating that is keyboard operable and works as a real radio group rather than clickable spans.
Narrate, and state your trade-offs
Silence is unscoreable in this round as much as in system design. Say what you are doing and why you are deferring things: "I'm using local state here rather than a store because nothing outside this component needs it — if it grew, I'd lift it." That sentence is worth more than the ten lines you could have typed in the same time.
Frontend System Design
This round confuses candidates who prepare with backend material. Nobody is asking you to shard a database. The subject is the client: where state lives, how data arrives, what renders when, and how it behaves when things go wrong. Work through six areas in order:
Requirements and constraints
Which devices and networks, whether SEO matters, whether the data is real-time or polled, and roughly how large the datasets are. As in backend design, do not draw before you scope — a feed for 50 items and a feed for 50,000 are different designs.
Component boundaries and state ownership
Draw the tree and mark where each piece of state lives. Server data, URL state, and ephemeral UI state are three different categories with three different homes — conflating them is the most common structural mistake in this round.
Data fetching and caching
Request lifecycle, deduplication, cache invalidation, optimistic updates and their rollback path, and pagination strategy — cursor rather than offset for anything that mutates while being read.
Rendering strategy
Client, server, or static rendering, and why. Tie it to a requirement: SEO and first-paint pressure push toward server rendering; a highly interactive authenticated dashboard usually does not need it.
Performance budget
Name concrete targets and the techniques that hit them: route-level code splitting, virtualisation for long lists, image sizing and lazy loading, avoiding layout thrash. Mention the Core Web Vitals you are optimising and which technique moves which metric.
Failure, accessibility, and instrumentation
Error boundaries and what the user sees, offline and slow-network behaviour, focus and announcement handling, and what you would log to know the feature is healthy in production.
The five-phase discipline from our general system design framework transfers directly here — scope, estimate, structure, design, then stress your own design. Only the subject matter changes.
Accessibility and Performance: The Unprompted Signals
Most frontend interviewers do not have an accessibility question on their list. They watch for it instead, throughout the loop. The behaviours that register:
- Reaching for semantic elements first. A real button rather than a clickable div — because the button gives you keyboard activation, focus, and the correct role for free.
- Managing focus in overlays. Focus into the dialog on open, trapped while open, restored to the trigger on close. This is the most commonly missed detail in the modal exercise.
- Labelling inputs properly rather than relying on placeholder text, which disappears the moment someone types.
- Naming a performance metric rather than a vibe. "This list needs virtualisation above a few hundred rows or scroll frame time suffers" lands; "this could get slow" does not.
- Measuring before optimising. Saying you would profile first, and being able to name what you would look at, is a stronger signal than reciting optimisation techniques.
A Two-Week Preparation Plan
Days 1–3: JavaScript behaviour drills
Work through output-prediction exercises on closures, the event loop, this, and promises. Predict first, run second, and write down every time you were wrong — those are your real gaps.
Days 4–6: implement the utilities from scratch
Debounce, throttle, a small event emitter, a promise-limiting helper, and deep clone. These appear directly in screens and they force the fundamentals into your hands rather than your notes.
Days 7–10: build the five components, timed
Autocomplete, modal, infinite scroll, multi-step form, star rating. Sixty minutes each, no component library, accessibility included. Build each one twice — the second pass is where the pace comes from.
Days 11–12: frontend system design out loud
Design a feed, an autocomplete-backed search page, and a collaborative editor. Forty-five minutes each, spoken, using the six-area structure above.
Days 13–14: behavioral stories and light review
Write out eight STAR stories weighted toward design and product collaboration, then stop. Our behavioral guide covers the format.
The hard part of this plan is not the material — it is doing it out loud, timed, and getting interrupted mid-answer the way a real interviewer interrupts. That is where AI practice earns its place: unlimited repetitions on the same exercise, at any hour, without booking anyone's time. We have written honestly about where AI helps and where a human still wins, and the behavioral question guide covers the final round.
Practise the frontend loop out loud, as many times as you need
Amigo runs unlimited timed practice from your resume and target role, then supports you live during the real interview with structured answers in real time.
Try Amigo free →Frequently Asked Questions
What rounds are in a frontend developer interview?
A typical loop has five rounds: a JavaScript fundamentals screen, a framework round on React or your primary library, a UI build exercise where you implement a component live, a frontend system design round at mid-level and above, and a behavioral round. Some companies fold the build exercise and framework round together.
What JavaScript topics come up most in frontend interviews?
Closures, the event loop and microtask ordering, promises and async/await, this binding, prototypal inheritance, event delegation and bubbling, and debounce versus throttle. Closures and the event loop appear in the majority of loops because they explain so much downstream behaviour.
What React questions do interviewers ask?
Reconciliation and why keys matter, the difference between state and refs, when useEffect runs and how to avoid dependency-array bugs, why derived state is usually an anti-pattern, memoisation with useMemo and useCallback and when it actually helps, and how context re-rendering works. Expect at least one question where the honest answer is that memoisation would not help.
What is a frontend system design interview?
A 45-minute round where you design the client architecture of a feature — for example an infinite-scroll feed, an autocomplete, or a collaborative editor. You cover component boundaries, state ownership, data fetching and caching, rendering strategy, error and loading states, accessibility, and performance budgets. Backend depth is not the focus.
How do you prepare for a live UI coding exercise?
Practise building four or five components from scratch without a component library: an autocomplete with debounced fetch and keyboard navigation, a modal with focus trapping, an infinite-scroll list, a multi-step form with validation, and a star rating. Narrate as you type, and handle loading, empty, and error states before adding polish.
Do frontend interviews still ask about CSS?
Yes, though less as trivia and more as applied layout. Expect flexbox versus grid choices, stacking contexts and z-index behaviour, containing blocks for position fixed and absolute, specificity, and responsive strategy. A common live task is reproducing a layout under a constraint such as no fixed pixel heights.
How important is accessibility in a frontend interview?
Increasingly decisive at mid-level and above. Interviewers watch whether you reach for a semantic button rather than a clickable div, manage focus in overlays, and label inputs — usually without asking. Unprompted accessibility awareness is one of the clearest seniority signals in the whole loop.
Found this useful?
Share it with someone preparing for an interview.
