Question 1

Explain how the JavaScript event loop works, and describe a real scenario where misunderstanding it caused or could cause a bug in a React application.

Accepted Answer

Walk through call stack → Web APIs → task queue → microtask queue (Promises, queueMicrotask) → render steps. Then give a concrete example: e.g., a setState inside a Promise.then that fires after a component unmounts, or batched updates behaving differently inside setTimeout vs. native events in React 17 vs. 18. Show you know the difference between macro and microtasks. What interviewers look for: Interviewers want to see that you can connect runtime mechanics to real product bugs, not just recite the event loop diagram. The React context shows you apply this to your actual stack, not in the abstract.

Question 2

Implement a function that takes an async function and a concurrency limit, and returns a wrapped version that never runs more than N invocations simultaneously.

Accepted Answer

Use a counter and a queue of pending resolvers. When the limit is reached, push a resolver onto the queue; when a slot frees up (in the .finally), dequeue and execute the next one. Walk through edge cases: rejection propagation, queue ordering, and whether the wrapper should be re-entrant. Write clean, typed code. What interviewers look for: This tests whether you can implement real async coordination primitives — the kind of thing you'd build for an upload manager or a rate-limited API client. Strong candidates write this without reaching for a library and handle the error path correctly.

Question 3

Design a large-scale component library that will be consumed by 15 product teams. Walk through your decisions around API design, versioning, theming, testing, and documentation.

Accepted Answer

Cover: monorepo vs. separate packages, semantic versioning with a clear deprecation policy, a design token system for theming (CSS custom properties vs. JS tokens), compound component and render-prop patterns for flexibility, snapshot + interaction + accessibility tests (Storybook + Playwright or similar), and automated changelog/migration tooling. Discuss the governance model — who merges to the library and how. What interviewers look for: This reveals whether you think about library design as a product, not just a code problem. Interviewers look for awareness of downstream consumer pain (breaking changes, bundle size, tree-shaking) and organizational dynamics (adoption, buy-in, contribution model).

Question 4

A product page renders a feed of 10,000 items. Describe how you would architect the solution end-to-end — from data fetching to rendering — to keep it fast and accessible.

Accepted Answer

Cover: windowing/virtualization (react-window or a custom IntersectionObserver approach), cursor-based pagination or infinite scroll with a stable anchor, memoization strategy (useMemo, React.memo with correct key strategy), skeleton screens for perceived performance, keyboard navigation through a virtualized list (roving tabindex or aria-activedescendant pattern), and measuring success (INP, CLS). Discuss tradeoffs of SSR vs. CSR for initial load. What interviewers look for: Interviewers want a holistic answer that connects rendering architecture to UX, performance metrics, and accessibility — not just 'use react-window'. Senior candidates proactively define what 'fast' means with metrics.

Question 5

Your app's Interaction to Next Paint (INP) score is poor on low-end Android devices. Walk through how you would diagnose and fix it.

Accepted Answer

Start with measurement: Chrome DevTools Performance panel + WebPageTest on a throttled profile, or field data from CrUX/RUM. Identify long tasks (>50ms) blocking the main thread. Common culprits: large JS bundles parsed on interaction, synchronous state updates causing layout thrashing, third-party scripts. Fixes: code-split interaction handlers, move heavy work to Web Workers, use scheduler.postTask or isInputPending for cooperative scheduling, debounce non-critical updates. What interviewers look for: INP replaced FID as a Core Web Vital in 2024 — knowing this signals you're current. Interviewers want a systematic diagnostic process, not a list of generic tips. Can you instrument the problem, form a hypothesis, and measure the fix?

Question 6

Explain how a browser's rendering pipeline works (from JS execution to pixels) and describe two specific patterns you've used to avoid layout thrashing.

Accepted Answer

Pipeline: JS → Style recalc → Layout → Paint → Composite. Layout thrashing: reading layout properties (offsetWidth, getBoundingClientRect) after writes forces a synchronous reflow. Fixes: (1) batch reads before writes in the same frame using requestAnimationFrame, (2) use CSS transform/opacity for animations (compositor-only, no layout/paint), (3) will-change hint to promote to its own layer. Show you know the difference between layout, paint, and composite properties. What interviewers look for: This separates engineers who have internalized the browser model from those who just use React and hope. The interviewer is checking whether you can reason about what happens below the framework.

Question 7

A complex checkout flow has deeply nested state shared across 8 components. Compare three different state management approaches for this scenario and recommend one with justification.

Accepted Answer

Evaluate: (1) Context + useReducer — simple, no library, but causes unnecessary re-renders if not split carefully, fine for moderate complexity; (2) Zustand or Jotai — minimal boilerplate, atomic subscriptions avoid re-render issues, good for medium scale; (3) XState — models the checkout as a state machine, great for complex business logic with many conditional transitions, but adds conceptual overhead. Recommend based on team familiarity and whether the logic is primarily UI state or business logic. What interviewers look for: Interviewers want to see that you can evaluate tools against concrete constraints rather than defaulting to what you know. Bonus signal: you recognize that checkout has finite states (cart, shipping, payment, confirmation) which makes a state machine argument compelling.

Question 8

What is the critical rendering path and how would you optimize it for a content-heavy marketing page where LCP is the primary metric?

Accepted Answer

CRP: HTML parse → DOM → CSSOM → Render tree → Layout → Paint. Blockers: render-blocking CSS and parser-blocking scripts. Optimizations: inline critical CSS, defer/async non-critical scripts, preload LCP image with fetchpriority='high', use font-display: swap, eliminate redirect chains, serve from CDN edge. Show you know how to measure: Lighthouse, WebPageTest waterfall, CrUX field data for P75 LCP. What interviewers look for: A precise understanding of what actually blocks rendering vs. what's a misconception. Senior candidates know the difference between preload, prefetch, and preconnect and use them correctly.

Question 9

You discover that your company's modal dialog implementation has several accessibility bugs. Walk through what's wrong and how you'd fix it.

Accepted Answer

Common bugs: focus not trapped inside modal, background content still reachable by screen reader (missing aria-modal or inert attribute on background), modal not announced on open (missing role='dialog' + aria-labelledby), Escape key not handled, focus not restored to trigger element on close. Fix using a focus trap utility, the native <dialog> element (which handles many of these natively), and aria attributes. Reference WCAG 2.1 SC 1.3.1, 2.1.2, 4.1.2. What interviewers look for: Accessibility at the senior level means knowing the spec, not just screen-reader empathy. Interviewers look for systematic coverage of the keyboard, screen-reader, and focus-management cases, and awareness of native HTML solutions.

Question 10

How would you design a frontend testing strategy for a product with a design system, business-logic-heavy React components, and end-to-end user flows?

Accepted Answer

Three-layer strategy: (1) Unit tests for pure logic (validation, formatters, state reducers) with Vitest/Jest; (2) Component tests with Testing Library — test behavior and accessibility, not implementation; use MSW to mock API at the network layer; (3) E2E with Playwright for critical paths (auth, checkout, key flows). For the design system specifically: visual regression tests (Chromatic/Percy) to catch unintended CSS changes. Discuss the cost/value tradeoff: E2E is expensive, prioritize ruthlessly. CI integration and test parallelism matter at scale. What interviewers look for: Interviewers want a strategy, not a tool list. Can you articulate what each layer catches, what it doesn't, and how to prioritize? Senior candidates know that over-investing in E2E creates a slow, flaky suite and under-investing in component tests leaves behavior gaps.

Question 11

Tell me about a time you introduced a significant technical change (e.g., a new framework, architecture pattern, or tooling) that required buy-in from engineers who were skeptical.

Accepted Answer

Use STAR. Key elements: describe the specific technical problem that motivated the change (not just 'we wanted to modernize'), how you built the case (proof of concept, metrics, risk analysis), how you addressed skeptics' specific concerns rather than steamrolling them, how you rolled it out incrementally, and what you learned if it didn't go perfectly. Avoid: vague stories, claiming full credit, or glossing over the friction. What interviewers look for: Technical influence is a core senior competency. Interviewers are checking whether you can drive change without authority, whether you listen to pushback as signal rather than noise, and whether you have the patience to de-risk transitions properly.

Question 12

Describe a situation where you identified a systemic quality problem in a codebase (not a single bug) and drove the effort to fix it across a team.

Accepted Answer

Choose a story with real scale: e.g., inconsistent error handling causing silent failures, no accessibility baseline across components, or a missing abstraction causing duplicated business logic. Describe: how you identified the pattern (code review, incidents, metrics), how you quantified the impact to get prioritization, how you designed the fix to be adoptable (codemods, lint rules, templates), and how you worked with the team rather than doing it all yourself. What interviewers look for: This tests engineering ownership and leverage. A senior engineer who only fixes their own code doesn't multiply the team. Interviewers want to see that you identify and address root causes systematically and that you scale solutions through tooling or education, not just heroics.

Senior Frontend Engineer Interview Questions

What to expect

12 questions, with how to answer them

1. Explain how the JavaScript event loop works, and describe a real scenario where misunderstanding it caused or could cause a bug in a React application.

2. Implement a function that takes an async function and a concurrency limit, and returns a wrapped version that never runs more than N invocations simultaneously.

3. Design a large-scale component library that will be consumed by 15 product teams. Walk through your decisions around API design, versioning, theming, testing, and documentation.

4. A product page renders a feed of 10,000 items. Describe how you would architect the solution end-to-end — from data fetching to rendering — to keep it fast and accessible.

5. Your app's Interaction to Next Paint (INP) score is poor on low-end Android devices. Walk through how you would diagnose and fix it.

6. Explain how a browser's rendering pipeline works (from JS execution to pixels) and describe two specific patterns you've used to avoid layout thrashing.

7. A complex checkout flow has deeply nested state shared across 8 components. Compare three different state management approaches for this scenario and recommend one with justification.

8. What is the critical rendering path and how would you optimize it for a content-heavy marketing page where LCP is the primary metric?

9. You discover that your company's modal dialog implementation has several accessibility bugs. Walk through what's wrong and how you'd fix it.

10. How would you design a frontend testing strategy for a product with a design system, business-logic-heavy React components, and end-to-end user flows?

11. Tell me about a time you introduced a significant technical change (e.g., a new framework, architecture pattern, or tooling) that required buy-in from engineers who were skeptical.

12. Describe a situation where you identified a systemic quality problem in a codebase (not a single bug) and drove the effort to fix it across a team.

Study tips