Mythic Intel
Engineering Roles

Frontend Engineer Interviews: Past The Framework Trivia

The Mythic Intel Team · Aug 20, 2025 · 7 min read

Frontend engineer interviews stopped being framework trivia a while ago. A panel that asks you to recite React lifecycle methods is testing memorization; a panel that asks why an interaction felt janky is testing whether you understand the platform underneath the framework. The frontend interview questions that decide offers in 2026 are about the browser itself: how JavaScript actually runs, how a page renders, and how to keep both fast and accessible.

This guide covers the technical ground a strong front end developer interview probes, with current terminology. It assumes you know a framework already and focuses on the fundamentals that separate people who use React from people who understand the web.

JavaScript and the event loop

The event loop is the most reliably tested concept, because it explains everything from why a UI freezes to how async/await behaves. Be able to explain it precisely, not by analogy.

JavaScript runs on a single thread with one call stack. When the stack is empty, the event loop pulls work from queues. The detail that matters: there are two priority levels.

  • The microtask queue holds Promise callbacks (.then, await continuations) and queueMicrotask. It is drained completely after each task, before any rendering or the next macrotask.
  • The macrotask queue holds things like setTimeout, setInterval, and I/O callbacks. One macrotask runs per loop iteration.

A classic question gives you a snippet mixing console.log, setTimeout(fn, 0), and Promise.resolve().then(...) and asks for the output order. The answer hinges on microtasks running before the timeout, even at zero delay.

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

The deeper point interviewers want: rendering competes with your code. If your JavaScript holds the thread, the browser cannot paint, so long synchronous work makes the page unresponsive. That connects directly to performance below. Also expect closures, the this binding rules, prototypal inheritance, and the difference between var, let, and const scoping.

Rendering and the critical render path

Senior rounds ask how a browser turns HTML into pixels, because optimizing load performance requires knowing the steps. Walk the critical render path in order:

  • Parse HTML into the DOM tree.
  • Parse CSS into the CSSOM.
  • Combine them into the render tree.
  • Layout (also called reflow): compute the geometry of every node.
  • Paint: fill in pixels.
  • Composite: assemble layers on the GPU.

The interview value is knowing what blocks what. CSS is render-blocking; the browser will not paint until the CSSOM is ready. A synchronous script in the <head> blocks parsing. This is why the standard advice is to inline critical CSS, defer or async non-critical scripts, and put scripts at the end. You should also know why changing a layout property (width, top) triggers reflow while changing transform or opacity can be handled by the compositor alone, which is the basis of smooth animation.

Performance and Core Web Vitals

Performance questions are now expected at most levels because Core Web Vitals affect search ranking and real user experience. Know the current three and what each measures:

  • Largest Contentful Paint (LCP): how long until the largest visible element renders. Loading metric. Good is under 2.5 seconds.
  • Interaction to Next Paint (INP): responsiveness across all interactions on the page. INP replaced First Input Delay as a Core Web Vital in March 2024, so naming FID as current is a tell that your knowledge is stale. Good is under 200 milliseconds.
  • Cumulative Layout Shift (CLS): visual stability, how much content jumps around as the page loads.

Be ready with the fixes, not just the names. Improve LCP by prioritizing the hero image and trimming render-blocking resources. Improve INP by breaking up long tasks, yielding to the main thread, moving heavy computation to a Web Worker, and deferring non-critical JavaScript. Improve CLS by reserving space for images and ads with explicit dimensions and avoiding inserting content above existing content.

State management

The question is rarely "Redux or Context." It is "what kind of state is this, and where should it live." Strong candidates distinguish:

  • Local UI state (a toggle, an input) that belongs in a component.
  • Shared client state that several components read, where Context or a store fits.
  • Server state (data fetched from an API), which has its own concerns: caching, revalidation, and staleness, handled well by data-fetching libraries rather than hand-rolled global state.

Know why putting everything in one global store causes unnecessary re-renders, and why Context is a dependency-injection mechanism that can cause re-renders if you put frequently changing values in it. Being able to reason about re-render behavior is the senior signal.

Accessibility

Accessibility (a11y) is a standard round now, not a bonus. The foundation is semantic HTML: use nav, main, button, and header instead of styled divs, because they carry meaning and behavior that assistive technology relies on for free. Cover:

  • Every interactive element must be reachable and operable by keyboard, with a visible focus state and a logical tab order.
  • ARIA supplements semantic HTML; it does not replace it. The first rule of ARIA is to use a native element if one exists. A <button> beats a <div role="button"> every time.
  • aria-label and aria-labelledby for elements without visible text, and aria-live regions for announcing dynamic updates.
  • Color contrast meeting WCAG ratios, and not conveying information by color alone.

A frequent practical prompt is to take an inaccessible custom dropdown built from divs and make it accessible. Knowing the keyboard interactions and roles a real combobox needs separates people who have shipped accessible UI from people who have read about it.

CSS and layout

CSS questions test layout reasoning. Know when to reach for Flexbox (one-dimensional, distributing items along a single axis) versus Grid (two-dimensional, rows and columns together). Be solid on the box model, how position values differ, stacking context and z-index, and specificity. A common debugging prompt shows an element that will not center or a z-index that will not take effect, and the answer is usually about a missing positioning context or a misunderstood stacking context.

Most of this is conceptual, which makes it ideal to rehearse out loud. Explaining the event loop or the render path to an empty room exposes the steps you only half-remember, and saying the INP-replaced-FID detail aloud cements it. That spoken practice is exactly what Mythic Intel grades, scoring a verbal answer for accuracy and structure rather than whether you can recognize the right multiple-choice option.

your turn

Stop reading about interviews. Start training for yours.

Build My Room →