Frontend Engineer Interview Guide 2026: JS, React, Design

A frontend engineer interview in 2026 tests four things: deep JavaScript fundamentals, the ability to implement utilities and UI components from scratch, frontend system design, and usually one algorithm round. To pass, you need to explain closures, the event loop, and promises precisely, write debounce or Promise.all without looking anything up, build a working accessible component in about 45 minutes, and design the client side of a product like a news feed or autocomplete.

This guide walks through each round, the questions that keep showing up, and how the loops at Meta, Google, Airbnb, and Stripe differ.

Key Takeaways

• Frontend loops are broader than general SWE loops: JavaScript trivia, utility implementation, UI builds, system design, and often LeetCode all appear.
• The highest-frequency coding prompts are debounce, throttle, Promise.all, deep clone, event emitter, and array flatten. Memorize the shapes, then practice the edge cases.
• React 19 knowledge (Actions, useActionState, useOptimistic, use, ref as a prop) now signals currency, especially at product companies.
• Frontend system design is judged on API contracts, state shape, rendering strategy, pagination, and performance, not on backend scaling.
• Core Web Vitals (LCP, INP, CLS) and accessibility are no longer bonus topics. Senior candidates are expected to raise them unprompted.

What Does a Frontend Engineer Interview Loop Look Like in 2026?

Most frontend loops follow the same skeleton, with company-specific weighting:

1. Recruiter screen (30 minutes): Level, team interest, and which stack you work in.
2. Technical phone screen (45-60 minutes): JavaScript questions plus one implementation task, or one algorithm problem.
3. Onsite or virtual onsite (4-5 rounds):
   • JavaScript and coding: implement a utility or solve a problem in JS.
   • UI build: construct a working component in the browser or in a shared editor.
   • Frontend system design: design the architecture of a client application.
   • Algorithms: a standard data structures round at some companies.
   • Behavioral: past projects, conflict, ownership. See our behavioral interview guide for structure.

The key difference from a backend loop is that you can be asked about the platform itself: how the browser parses HTML, what triggers layout, how the microtask queue drains. Breadth matters.

Which JavaScript Fundamentals Do Interviewers Test?

Closures

A closure is a function bundled with references to the variables in the scope where it was created. That function keeps access to those variables even after the outer function returns. Interviewers test closures through counters, memoization, private state, and the classic loop bug:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// logs 3, 3, 3 because var is function-scoped

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// logs 0, 1, 2 because let creates a new binding per iteration

The event loop

The event loop is the mechanism that lets single-threaded JavaScript handle asynchronous work. After the current call stack empties, the engine drains the entire microtask queue (promise callbacks, queueMicrotask, MutationObserver) before taking the next macrotask (setTimeout, I/O, UI events). Rendering opportunities typically occur between macrotasks. Expect an ordering question:

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
queueMicrotask(() => console.log("D"));
console.log("E");
// A, E, C, D, B

Be ready to explain why a long synchronous loop freezes the page and how breaking work into chunks (or yielding with scheduler APIs) improves responsiveness. This links directly to INP, covered below.

Promises and async/await

A promise is an object representing the eventual result of an asynchronous operation, in one of three states: pending, fulfilled, or rejected. Know the differences between Promise.all (rejects on the first rejection), Promise.allSettled (never rejects, returns every outcome), Promise.race (settles with the first settlement), and Promise.any (fulfills with the first fulfillment, rejects with an AggregateError only if all reject).

The rest of the checklist

• this binding rules: default, implicit, explicit (call, apply, bind), new, and arrow functions inheriting lexical this.
• Prototypal inheritance and what class compiles down to.
• Hoisting and the temporal dead zone for let and const.
• == versus ===, and type coercion edge cases.
• Event delegation, bubbling versus capturing, stopPropagation versus preventDefault.
• DOM and browser APIs: IntersectionObserver, requestAnimationFrame, AbortController, fetch, Web Storage, and the difference between localStorage, sessionStorage, and cookies.

How Do You Answer "Implement Debounce, Throttle, or Promise.all"?

These are the most common frontend coding prompts in 2026. Interviewers want correct this and argument forwarding, cleanup, and edge-case handling.

Debounce delays invoking a function until a set time has passed since the last call. Use it for search input and resize handlers.

function debounce(fn, wait) {
  let timerId = null;
  function debounced(...args) {
    clearTimeout(timerId);
    timerId = setTimeout(() => {
      timerId = null;
      fn.apply(this, args);
    }, wait);
  }
  debounced.cancel = () => {
    clearTimeout(timerId);
    timerId = null;
  };
  return debounced;
}

Throttle guarantees a function runs at most once per interval. Use it for scroll and pointer-move handlers.

function throttle(fn, wait) {
  let lastCall = 0;
  let timerId = null;
  let pendingArgs = null;
  let pendingThis = null;
  return function throttled(...args) {
    const now = Date.now();
    const remaining = wait - (now - lastCall);
    if (remaining <= 0) {
      clearTimeout(timerId);
      timerId = null;
      lastCall = now;
      fn.apply(this, args);
    } else {
      pendingArgs = args;
      pendingThis = this;
      if (!timerId) {
        timerId = setTimeout(() => {
          lastCall = Date.now();
          timerId = null;
          fn.apply(pendingThis, pendingArgs);
        }, remaining);
      }
    }
  };
}

Promise.all resolves with an array of results in input order, or rejects with the first rejection.

function promiseAll(iterable) {
  return new Promise((resolve, reject) => {
    const items = Array.from(iterable);
    const results = new Array(items.length);
    let remaining = items.length;
    if (remaining === 0) {
      resolve(results);
      return;
    }
    items.forEach((item, index) => {
      Promise.resolve(item).then((value) => {
        results[index] = value;
        remaining -= 1;
        if (remaining === 0) resolve(results);
      }, reject);
    });
  });
}

The details interviewers probe: wrapping non-promise values with Promise.resolve, preserving order by index rather than push, and handling the empty input. Follow-ups include Promise.allSettled, a concurrency-limited task runner (run at most N promises at once), retry with exponential backoff, and cancellation with AbortController.

Other high-frequency utilities: deep clone (with circular references via a WeakMap), deep equal, Array.prototype.flat, curry, memoize, an event emitter with on, off, and once, getElementsByClassName, and a tiny template or classnames function.

What React Questions Come Up, Including React 19?

React remains the dominant framework in frontend interviews. Expect conceptual questions before any build.

Fundamentals interviewers always ask:

• Reconciliation and why keys matter in lists. Using array indexes as keys breaks state when items reorder.
• When a component re-renders: state change, parent re-render, or context change. React.memo only skips re-renders caused by a parent when props are shallowly equal.
• useEffect dependencies, cleanup functions, and why effects run twice in Strict Mode during development.
• Stale closures in effects and event handlers, and how functional state updates (setCount(c => c + 1)) avoid them.
• Controlled versus uncontrolled inputs.
• Lifting state up versus context versus an external store, and when context causes too many re-renders.

React 19 features worth knowing. React 19 shipped as stable in December 2024, and 19.2 followed in October 2025. The features most likely to come up:

React Compiler reached 1.0 in 2025 and automatically memoizes components and values. A good interview answer acknowledges that useMemo and useCallback still exist and still matter in codebases that do not use the compiler, and that the compiler relies on code following the Rules of React.

How Do You Pass the UI Component Build Round?

The UI build round asks you to build a working component in 45 to 60 minutes, sometimes in vanilla JavaScript and sometimes in React. Common prompts:

• Autocomplete or typeahead with debounced fetching
• Modal or dialog with focus trapping
• Tabs, accordion, or star rating
• Infinite scroll list or paginated table with sorting
• Image carousel
• Nested comments or a file tree
• Tic-tac-toe, a progress bar queue, or a countdown timer
• A data table with filtering

A reliable approach:

1. Clarify for two to three minutes. Ask about required features, browser support, whether a library is allowed, and what "done" means.
2. Define state first. Write down the state shape before markup. For autocomplete: query, results, status, highlightedIndex, isOpen.
3. Get the happy path working. A rendered, interactive component beats a perfect half-component.
4. Handle edge cases explicitly. Race conditions (ignore stale responses with a request id or AbortController), empty states, errors, and loading.
5. Add accessibility and keyboard support. Arrow keys, Enter, Escape, and the correct ARIA roles.
6. Narrate trade-offs. Caching results, virtualization for long lists, and how you would test it.

The race condition in autocomplete is the single most common place candidates lose points. If a slow response for "re" arrives after the fast response for "react," the UI shows stale results unless you guard against it.

How Do You Approach Frontend System Design?

Frontend system design asks you to architect the client side of a product. Unlike a backend system design interview, you are not sharding databases. You are designing components, data flow, and the client-server contract. A useful framework is RADIO: Requirements, Architecture, Data model, Interface (API), and Optimizations.

Example: design a news feed

• Requirements: Infinite scroll, posts with text and media, likes and comments, new posts appearing at the top.
• Architecture: A feed container, a post component, a composer, and a client-side store that normalizes posts by id.
• Data model: Normalized entities (posts, users, comments) keyed by id, plus an ordered list of post ids for the feed.
• API: Cursor-based pagination (GET /feed?cursor=abc&limit=20) rather than offset pagination, because offsets break when new posts are inserted at the top.
• Optimizations: List virtualization for long feeds, lazy-loading images with explicit dimensions to prevent layout shift, optimistic likes, prefetching the next page when the user nears the bottom with IntersectionObserver, and code splitting the composer.

Example: design autocomplete

Cover debouncing input, caching results per query (an in-memory map with an LRU eviction policy), cancelling or ignoring stale requests, minimum query length, keyboard navigation, highlighting matched substrings, and the WAI-ARIA combobox pattern. A strong candidate also discusses whether to filter client-side for small datasets versus querying the server, and how to handle offline or slow networks.

Other popular prompts: chat application (WebSockets, message ordering, optimistic send, reconnect), photo gallery or Pinterest-style masonry grid, collaborative editor, video player, and e-commerce product page with server-side rendering for SEO.

What Performance and Core Web Vitals Questions Should You Expect?

Core Web Vitals are Google's three user-centric performance metrics, and they are now standard interview vocabulary.

INP replaced First Input Delay as a Core Web Vital in March 2024, and interviewers sometimes use that as a check on whether your knowledge is current. Beyond the vitals, be ready to discuss the critical rendering path, what triggers layout versus paint versus composite, bundle splitting and tree shaking, image formats (AVIF, WebP), HTTP caching headers, and when server-side rendering or streaming beats client rendering.

Which Accessibility Topics Matter?

Accessibility is evaluated in nearly every UI build and system design round at large companies. The checklist:

• Use semantic elements (button, nav, main, label) before reaching for ARIA. A div with an onClick is not a button.
• Every interactive element must be reachable and operable by keyboard, with a visible focus indicator.
• Modals must trap focus, close on Escape, and return focus to the trigger on close.
• Form inputs need associated labels, and errors need to be announced.
• Dynamic updates such as toast notifications or search result counts use aria-live regions.
• Color contrast meets WCAG AA, which requires 4.5:1 for normal text.

Mentioning these without being asked is one of the clearest seniority signals in a frontend loop.

How Do Meta, Google, Airbnb, and Stripe Frontend Loops Differ?

Meta. Frontend engineers at Meta typically go through a loop that looks close to the general SWE loop, with coding rounds that may be done in JavaScript, a frontend-flavored design round, and behavioral. Practice medium LeetCode problems in JavaScript and expect DOM or JS questions mixed in. Full details are in our Meta technical interview breakdown.

Google. Google's frontend roles still lean on algorithms, and the bar for algorithm rounds is not lowered for frontend candidates. Domain rounds test JavaScript and web platform knowledge. See the Google interview process guide.

Airbnb. Airbnb emphasizes practical JavaScript, component builds, and code quality, with a dedicated core values round. Our Airbnb interview guide covers the cross-functional format.

Stripe. Stripe avoids puzzle-style questions and favors realistic tasks, such as building against an API or debugging an existing codebase. The Stripe interview guide explains the Integration and Bug Squash rounds, which frontend candidates also encounter.

How Should You Structure Your Preparation?

A practical eight-week plan for a working frontend engineer:

1. Weeks 1-2: JavaScript fundamentals. Write debounce, throttle, Promise.all, deep clone, event emitter, and curry from memory. Drill event loop ordering questions.
2. Weeks 3-4: UI builds. Build one component every other day under a 45-minute timer: autocomplete, modal, tabs, infinite scroll, data table.
3. Weeks 5-6: Frontend system design. Do one full design per session using RADIO and record yourself explaining it.
4. Weeks 7-8: Mock loops, React 19 review, performance and accessibility checklists.
5. Throughout: Two or three algorithm problems per week organized by pattern. The coding interview patterns cheat sheet covers the sliding window, two pointers, BFS, and DFS templates that frontend algorithm rounds lean on most.

Do every exercise in the language you will interview in. For frontend candidates that should almost always be JavaScript or TypeScript, since interviewers will expect you to be fluent in the platform you are applying to build for.