Frontend interviews have quietly turned into some of the hardest loops in the industry. Ten years ago you could get away with knowing jQuery, a bit of CSS, and how to debounce a search input. Today a senior frontend candidate is expected to reason about the event loop, argue about hydration strategies, defend a Core Web Vitals budget, and design an autocomplete widget that works for seven million daily active users on a flaky mobile connection. The bar has moved, but most preparation material has not.
This guide is the version of the interview playbook I wish I had when I was preparing for frontend loops at product companies. It walks through each round you are likely to face, the traps inside each round, the frameworks that will keep you from drifting, and the mistakes that keep competent engineers from passing the bar. It is written for candidates who already write React every day and want to get sharper, not for people looking for a tutorial.
- What the Frontend Loop Actually Looks Like
- Round 1: JavaScript Fundamentals
- Round 2: React Internals and Rendering
- Round 3: CSS and Layout Deep Dive
- Round 4: Performance, Hydration, and Core Web Vitals
- Round 5: Accessibility as a First-Class Concern
- Round 6: UI System Design
- The Infinite Scroll Question, Fully Worked
- The Autocomplete Question, Fully Worked
- Common Mistakes Frontend Candidates Make
- Frequently Asked Questions
- Conclusion
A modern frontend loop for a senior individual contributor at a product company usually has five to six rounds. You will see a JavaScript fundamentals round that almost always involves writing helper functions from scratch. You will see a React or framework-specific round that tests whether you understand the runtime, not just the API. You will see a CSS round where you are expected to build a layout live, often responsive, often with tricky overflow behavior. You will see a performance or Web Vitals round where the interviewer will drop a slow page on you and ask you to diagnose it. And you will see a UI system design round, which is the frontend equivalent of the classic backend system design interview.
Many companies also slot in an accessibility deep dive, a behavioral round, and a culture or product sense conversation. The weighting of these rounds shifts with the seniority of the role. For a mid-level role, the technical execution rounds dominate. For a senior or staff role, the system design and trade-off rounds carry more weight, because at that level the company is buying your judgment, not your throughput.
The fundamentals round is where pattern matching breaks down. Interviewers know that candidates have seen every clever closures question on the internet, so they are increasingly asking you to build small runtime primitives from scratch. The goal is not to trick you. The goal is to see whether you can reason about execution in a precise way.
A typical prompt sounds harmless. Build a function called once that wraps another function and only allows it to execute once. The first time it runs, it caches the result. Every subsequent call returns the cached value. Seniors are expected to handle this, arguments of arbitrary arity, and the case where the wrapped function throws. The throwing case is the interesting one. Do you cache the thrown error and re-throw it on the next call, or do you allow the user to retry until it finally succeeds? There is no single right answer, but you are expected to notice the choice exists and have an opinion.
Another common prompt is to build a promise-based concurrency limiter. Given an array of async tasks and a concurrency number N, run them such that at most N are in flight at any time. This question tests whether you understand the microtask queue, how promise resolution schedules follow-on work, and whether you can keep track of state without memory leaks. Candidates who try to solve this with recursion and an index counter often produce something that works on the happy path but silently corrupts when a task rejects. Candidates who solve it with a small worker pool that pulls from a shared queue tend to write code that is both correct and fast to explain.
Expect at least one question that probes closures, one that probes this binding across arrow functions and regular functions, and one that probes the difference between microtasks and macrotasks. The event loop question is almost a ritual at this point. You are shown a block of code with a mix of setTimeout, Promise.resolve().then, a queueMicrotask call, and a requestAnimationFrame, and you are asked to predict the order of console output. Memorizing the answer is not enough. You should be able to draw the task queue and microtask queue on the whiteboard and walk through each tick.
Prototypes still appear, but they have shifted. Nobody asks you to reimplement Object.create anymore. They ask you to explain why Array.from({ length: 3 }) returns an array of holes rather than undefineds, or why Object.keys and for...in behave differently on a class instance. The questions have matured, but the underlying model of how JavaScript looks up properties on a chain is still what you are being tested on.
The React round at most serious companies no longer lets you skate by on surface-level knowledge of hooks. You are expected to know why the rules of hooks exist, not just what they are. You are expected to explain what happens when you call setState inside an event handler versus inside an effect, and why those two paths produce different batching behavior in modern React.
A useful mental model to bring into the room is to separate React into three layers. The first layer is the public API you write every day. The second layer is the reconciler, which figures out what changed between two render outputs and produces a list of fiber operations. The third layer is the renderer, which takes those operations and applies them to the DOM or the native host. When an interviewer asks a question like why a ref does not trigger a re-render, you should be able to answer in terms of the reconciler rather than in terms of memorized rules.
Expect questions about concurrent rendering. You should be able to explain what startTransition does, why it exists, and what kinds of work it is appropriate for. You should also be able to articulate the difference between useMemo and useCallback without falling into the trap of saying one is for values and the other is for functions. Both are memoization primitives. The real question is what dependencies you are stabilizing and why that stability matters to a downstream consumer.
Hydration is a favorite topic in 2026 because Server Components and streaming SSR have changed the shape of React applications. You will likely be asked to explain what a hydration mismatch is, why it is expensive, and how to avoid one when a component depends on something like the current time or the user's locale. The honest answer is that you either defer that piece of UI until after hydration, or you serialize the value from the server and pass it down as a prop. Candidates who suggest suppressing the warning without understanding the consequence are showing the interviewer exactly the kind of judgment that will cause production incidents later.
The CSS round is often underestimated and often the round that silently sinks candidates. You will be given a Figma or a screenshot and asked to build it in the browser, live, with the interviewer watching. The layout will have a detail designed to trip you up: a sticky header that needs to coexist with a scrolling panel, a card grid with a last-row alignment quirk, a modal that must trap focus without shifting layout when the scrollbar disappears.
Modern CSS gives you tools that older candidates forget to reach for. grid-template-areas makes responsive layouts dramatically more readable than stacks of flexbox. The :has() selector lets you style a parent based on the presence of a child, which used to require JavaScript. Container queries solve the real-world problem that a card's layout should depend on the width of its container, not the width of the viewport. If you are preparing for a senior frontend loop and you still default to media queries and margin hacks, you are leaving points on the table.
You should also be fluent in stacking contexts. A surprising number of bugs in shipped products come from an engineer who did not realize that adding transform or opacity to an ancestor created a new stacking context that traps z-index values. When an interviewer sketches a page with a dropdown that keeps getting clipped by a parent, the correct first move is not to bump the z-index to nine thousand. The correct first move is to ask which ancestor is creating the stacking context and whether the dropdown should be portaled out of that subtree.
Performance rounds have become mandatory at any company that cares about mobile users, which is all of them. The interviewer will typically share a slow page and a profiler recording, or walk you through a hypothetical. You are expected to drive the diagnosis.
Start by asking which metric is regressing. A large contentful paint problem is a very different story from a cumulative layout shift problem. LCP is about how long until the main content renders. CLS is about whether the layout jumps after it renders. INP, which has replaced first input delay as the responsiveness metric, is about how long the browser takes to paint a visual response after an interaction. Each metric maps to different parts of the page lifecycle, and the fix for one will not help the others.
For LCP, the common culprits are render-blocking resources, slow server response times, and images that are not preloaded or not sized correctly. A senior candidate should mention the fetchpriority attribute, the preload link, and the fact that a hero image should almost never be lazy loaded. For CLS, the culprits are images and iframes without explicit dimensions, fonts that swap and reflow content, and ads or embeds that inject themselves into the middle of the page. The fix is almost always to reserve space with aspect-ratio or with an explicit width and height. For INP, the culprit is long tasks on the main thread, and the fix is to break them up, move them off the main thread with a worker, or defer them with requestIdleCallback or scheduler.postTask.
Hydration deserves its own subsection because it is a topic where candidates either sound well informed or sound lost. Hydration is the process of attaching event listeners and reviving state on HTML that the server already rendered. It is expensive because React has to walk the entire tree and match it against the component tree. Selective hydration, which React introduced along with Suspense-based streaming, lets the framework hydrate the parts of the page that the user is interacting with first. Islands architectures, popularized by Astro and adopted in various forms elsewhere, take this further by only hydrating components that explicitly opt in. If you are interviewing at a company that ships a content-heavy site, expect this topic.
Accessibility is no longer a bonus topic in a frontend interview. It is a filter. Companies that have been sued or that have enterprise customers with procurement requirements will check whether you know the basics, and a candidate who cannot discuss ARIA without confusion will lose the round even if every other round went well.
The core things you are expected to know are the difference between a semantic element and a div with an ARIA role, the proper use of aria-live for announcements, focus management inside modals and drawers, keyboard traps and how to avoid them, and the relationship between visible labels and accessible names. The last one trips up more senior candidates than you would expect. If your input has a visible label that says Email, the accessible name of the input should be Email. Using aria-label with a different string creates a confusing experience for screen reader users and violates WCAG's label in name rule.
You should also be ready to defend color contrast choices, because design systems often ship with colors that look fine to a designer with perfect vision but fail at the 4.5 to 1 ratio required for body text. If you are asked to review a component for accessibility issues, do not just look at the ARIA attributes. Walk through a keyboard-only interaction, imagine a screen reader reading the page, and check whether the component works at 200 percent zoom.
The UI system design round is where senior candidates separate themselves. The prompt is usually something like design an image gallery with infinite scroll, design a collaborative document editor, design a real-time dashboard with ten thousand rows of streaming data, or design an autocomplete for a global search bar.
The key shift from a backend system design interview is the axis of the trade-offs. Instead of talking about sharding strategies and consensus, you are talking about rendering strategies, network transport, client state management, and perceived performance. You are also working in a much more constrained environment. The main thread is single-threaded, memory is limited on mobile devices, the network is unreliable, and the user will notice a fifty millisecond delay.
A good answer starts with requirements. You ask about the scale of the data, the expected latency of interactions, whether offline support matters, which devices you are targeting, and what the consistency requirements are. Only after you have the constraints do you sketch an architecture. A common mistake is to jump straight into implementation details, which signals that you do not yet know how to scope an ambiguous problem.
Let us walk through the infinite scroll prompt end to end, because this is the question that most commonly appears and most commonly goes poorly.
The naive implementation appends new items to a long list as the user scrolls. This works for the first few hundred items. By the time the list hits a few thousand items, the DOM has so many nodes that scrolling becomes janky, memory usage balloons, and interactions on unrelated parts of the page slow down. A senior candidate should recognize this before writing any code.
The correct architecture is windowing, sometimes called virtualization. You only render the rows that are currently in the viewport, plus a small buffer above and below to handle fast scrolls. The data structure you need is an index that maps a scroll offset to a row, which is straightforward when rows are fixed height and subtle when they are variable height. For variable heights, you can either measure rows as they render and cache the measurements, or you can estimate and correct.
You also need to think about how data arrives. Cursor-based pagination is almost always the right choice over offset-based pagination because it handles inserts and deletes without producing duplicates or gaps. The cursor is typically an opaque string that encodes the server's notion of position. The client requests the next page when the user scrolls within a threshold of the end.
Do not forget accessibility. Infinite scroll is notoriously hostile to keyboard and screen reader users. Add a manual load more button as an alternative path, announce new content with an aria-live region, and make sure focus does not jump unexpectedly when new rows load.
Finally, talk about failure. What happens when a page fails to load? You need to retry with backoff and show an error state that lets the user recover. What happens when the user scrolls back up? You need to decide whether to keep earlier pages in memory or to unmount them and re-fetch. At scale, unmounting and re-fetching is usually the right call, but you need a way to preserve scroll position when the user returns.
Autocomplete looks simple and is actually a miniature distributed systems problem in a single input field.
You start by debouncing keystrokes, typically around one hundred fifty milliseconds. This alone cuts the number of requests dramatically. You then need to handle race conditions. If the user types three characters quickly and the server responds to the second query after the third, you must not show stale results. The classic fix is to tag each request with a sequence number and discard responses that do not match the latest sequence.
Caching matters. If the user types a character, then backspaces, you should serve the previous result from memory rather than going back to the server. A simple in-memory cache keyed by the query string is usually enough. You can go further and implement prefix-based cache lookups so that the cache entry for apple can serve the query app if you also stored the prefix mapping.
For UI, you need to pick a component that is accessible. The combobox pattern from the WAI-ARIA authoring practices guide is the correct reference. You have an input with role combobox, a listbox with role listbox, and options with role option. Keyboard navigation must handle the up and down arrows, Enter to select, Escape to close, and Home and End to jump. The input's aria-activedescendant should point to the currently highlighted option so screen readers announce it as the user navigates.
At scale, the server-side story matters too. The autocomplete endpoint must return in under one hundred milliseconds at the 99th percentile, which usually means a dedicated search index like Elasticsearch or an in-memory trie, not a general-purpose database query. You should be able to discuss this at a high level even in a frontend interview, because the interviewer wants to know whether you think about the full stack when the product demands it.
The most common mistake is treating React as a black box. When a question gets hard, the candidate retreats into framework-specific terminology without being able to explain what is happening underneath. Interviewers notice this immediately and it caps you at a mid-level outcome.
Another common mistake is over-engineering the first implementation. If the interviewer asks for a toggle component, build a toggle component. Do not reach for a headless library abstraction, a context provider, and a generic state machine. Start simple, then let the interviewer push you toward complexity. Showing judgment about when to abstract is a senior signal. Abstracting prematurely is not.
A third mistake is ignoring the tail of the distribution. You will build the happy path quickly, and then spend the rest of the interview on the error state, the loading state, the empty state, and the edge cases. Candidates who ship the happy path and declare victory lose rounds they should have won. Candidates who proactively surface edge cases signal that they will ship robust code in production.
Finally, candidates underinvest in articulating trade-offs. When the interviewer asks why you chose CSS Grid over Flexbox, the answer is not because Grid is newer. The answer is that Grid lets you align in two axes simultaneously, which matches the structure of this layout, whereas Flexbox would require nested containers. Every choice has a reason. Say the reason out loud.
How much Next.js or Remix specific knowledge do I need?
Enough to discuss the tradeoffs between static generation, server rendering, and client rendering, and enough to talk about how server components change the shape of your data loading. You do not need to memorize configuration flags. You do need to be able to say why you would reach for a particular rendering mode for a given page.
Are TypeScript questions separate or blended in?
Almost always blended. You are expected to type the code you write, and if you have to define a slightly tricky generic helper, you should be comfortable doing it. Interviewers rarely ask pure TypeScript puzzles, but they will notice if you write sloppy types in an otherwise clean solution.
Do I need to know Web Components or framework-less rendering?
Only if the role calls for it. Most product companies standardize on a single framework. If you are interviewing at a platform team that builds shared UI components across teams with different frameworks, then yes, you should be comfortable with Web Components and the shadow DOM.
How should I prepare for the live coding round?
Practice in the environment the company uses. If they use a shared CodeSandbox, practice in CodeSandbox. If they use their own internal editor, practice writing React without the safety net of your local tooling. Muscle memory matters more than knowledge at that point.
How deep should I go on browser internals?
Deep enough to answer questions about the rendering pipeline, layout thrashing, and the difference between paint, composite, and layout. You do not need to know the exact Chromium source code. You do need to know why reading offsetHeight after a style change is expensive.
Is whiteboard algorithm coding still part of frontend loops?
Less than it used to be. Most companies replaced the classic algorithm round with a UI-focused coding round. A handful of large companies still include a traditional data structures round. Check with your recruiter and calibrate your preparation accordingly.
The modern frontend interview rewards engineers who have opinions, who can reason about the runtime, and who can move from a blank screen to a working UI under pressure without losing their judgment. Memorizing framework APIs will not get you through, and neither will a deep but narrow specialization in one corner of the stack. The candidates who win these loops are the ones who understand how the browser actually works, who have built enough production UI to have scars, and who can articulate why they made each choice.
Prepare with intent. Build small projects that stress the parts of the stack you are weakest on. Practice explaining your reasoning out loud, because the interview is as much about narration as it is about correctness. And remember that the goal is not to know everything. The goal is to show the interviewer that you will keep learning once you are on the team.