Frontend Engineer Interview Questions (2026)

Describe a filter: you adopt when a tool solves a problem you actually have, has survived past its hype cycle, and has a credible migration path — and you spike it on something small first. Name one thing you adopted recently and why, and one popular thing you deliberately skipped and why. The skip answer is more revealing than the adopt answer.

Anchor in what the discipline uniquely offers: the work is where software meets actual humans, the constraint set is unusual (untrusted runtime, every device, every network condition), and the feedback loop is immediate. Be honest about the tradeoff — you give up some backend depth — and frame where you still go full stack when needed. Avoid "I like visual things"; it undersells the engineering.

Frontend-specific questions land best: how do designs get handed off and what happens when implementation surfaces a problem; who owns performance and accessibility — a team, a budget, or nobody; what does the deploy and rollback story look like; how much of the frontend is design-system covered versus bespoke. The answers tell you whether frontend is a first-class discipline there or an afterthought.

Cover the synthetic event system dispatching the handler, the state update being scheduled (and batched with other updates in the same tick), the re-render producing a new element tree, reconciliation diffing it against the previous tree, commit applying the minimal DOM mutations, and then the browser style/layout/paint pipeline. Mentioning useEffect timing relative to paint, and how concurrent features change scheduling, signals real depth.

Measure first: field data (CrUX, RUM) over lab data, then a Lighthouse trace to identify the LCP element. Common fixes in order of impact: make sure the LCP resource is discoverable early (preload the hero image or font, no lazy-loading above the fold), eliminate render-blocking CSS/JS, check server response time, and code-split JavaScript that delays rendering. State that you would fix the biggest contributor first and re-measure rather than applying everything blindly.

Static generation for content that is the same for every visitor and changes infrequently (marketing, docs, SEO pages) — cheapest and fastest. SSR for personalized or frequently changing content where first-paint speed and SEO both matter. Client-side rendering for authenticated app surfaces behind a login where SEO is irrelevant and interactivity dominates. Mention hybrid reality: most real apps mix all three per route, and streaming/RSC blur the lines further.

Default to the narrowest scope that works: component state for local UI, lifted state for shared siblings, URL state for anything the user should be able to bookmark or share, server-cache libraries (React Query or similar) for remote data, and a global store only for genuinely app-wide client state like auth or theme. Most "state management problems" are actually server-cache problems being solved with client stores. Name a real case where you moved state down or into the URL and what it simplified.

Core concerns: debounce input to avoid a request per keystroke; handle out-of-order responses (abort stale requests or ignore responses for superseded queries); full keyboard support (arrow navigation, Enter to select, Escape to close) with the ARIA combobox pattern; and explicit loading, empty, and error states. Mention caching recent queries and highlighting the matched substring as polish. Saying "race conditions" unprompted is the strongest signal in this question.

For a modal: focus moves into the dialog on open, is trapped while open, and returns to the trigger on close; Escape closes; background content is inert and hidden from assistive tech. For a combobox: the ARIA combobox pattern with managed aria-activedescendant or roving focus, list options announced as you navigate, selection state communicated. Mention testing with an actual screen reader, because the ARIA spec and real screen-reader behavior diverge.

Cover the API contract: composable primitives over configuration-heavy mega-components, controlled and uncontrolled modes, design tokens as the theming layer. Versioning: semver with codemods shipped for breaking changes and deprecation telemetry so you know what is safe to remove. Distribution: tree-shakeable packages, documented in Storybook with interaction tests. The social half: an RFC process for new components and a contribution path so teams extend the system instead of forking it.

One thread shared between JavaScript and rendering: tasks run to completion from the task queue, microtasks (promises) drain completely after each task, and rendering can only happen between tasks. A long synchronous task blocks paint and input handling — which is what INP measures. Mitigations: chunk long work with scheduler APIs or setTimeout, move computation to web workers, and avoid layout thrashing by batching DOM reads and writes.

A pragmatic pyramid: unit tests for pure logic (formatting, validation, reducers), component tests with Testing Library asserting behavior through the accessibility tree rather than implementation details, and a small set of end-to-end tests (Playwright) on the flows that make money — signup, checkout, the core loop. Visual regression on the design system if one exists. Name the failure mode of each layer: unit tests miss integration bugs, E2E suites get slow and flaky if used for everything.

Pick a problem where the cause was not obvious: a third-party script blocking main thread, layout thrash from a resize observer loop, a memory leak in a long-lived SPA session. Walk through how you measured (performance profile, RUM data), the hypotheses you ruled out, the fix, and the before/after numbers. End with what guardrail you added so it could not regress silently.

Pick a case with a real constraint: an interaction that could not be made keyboard-accessible as designed, an animation that would jank on low-end devices, a layout that broke at intermediate viewports. Describe how you raised it (early, with a prototype or evidence, not at implementation time), the alternative you proposed, and what shipped. The best stories end with the designer trusting you more, not less.

Cover why the migration was worth its cost, the incremental path (route by route, strangler pattern, codemods for the mechanical parts), how both systems coexisted mid-migration, and how you verified each step (visual regression, metrics parity). Name the thing that went wrong — something always does — and how you handled it. A migration story with no setbacks reads as either luck or distance from the work.

First, scope it: which browsers, devices, regions, logged-in state? Check error tracking (Sentry) for the actual exception and the release tag. Usual suspects: a CDN or cache serving stale assets against a new HTML shell (chunk-load errors), a feature flag mismatch, an ad blocker or extension interfering, or a browser-specific API. If user impact is real and the cause is not obvious within minutes, roll back first and diagnose after. Mention reproducing with the user's exact browser/device profile rather than insisting it works locally.

Quantify the cost in user terms: what the script does to LCP/INP on the throttled profile, and what that historically does to conversion on this page. Then offer options: lazy-load the script on interaction, use a lighter alternative or facade pattern, or scope it to the pages that need it. If the business value still wins, ship it with the impact measured and documented so the decision is revisitable. The wrong answers are silent compliance and flat refusal.

Stabilize before optimizing: add error tracking if missing, then E2E tests on the one or two flows that make money so changes are safe to make. Then measure the bundle (analyzer) and take the cheap wins first — duplicate dependencies, an unused library, images shipped as JavaScript. Set a CI budget so it cannot regress while you work. Resist the rewrite instinct; describe how you would make the case for incremental improvement to the team.