What is a closure in JavaScript, and where does it cause problems in production code?

A closure is a function that retains access to its outer lexical scope even after the outer function has returned. Every function in JavaScript is a closure. Common production problems: 1) stale closures in React hooks — an event handler that captured an old version of state, fixed with the functional update form of setState or useRef; 2) memory leaks — closures in long-running event listeners keeping large objects in scope; 3) the classic loop-with-var problem (var i captured by reference, not by value) and why let fixes it by creating a new binding per iteration.

A page has poor Largest Contentful Paint (LCP). Walk me through how you diagnose and fix it.

Start with Chrome DevTools → Performance tab or PageSpeed Insights to identify what the LCP element actually is (usually a hero image, a large text block, or a video poster). Common causes and fixes: (1) server response time — check TTFB, consider CDN or server-side caching; (2) render-blocking resources — CSS in is fine, but synchronous JS in blocks HTML parsing; (3) image not prioritized — add fetchpriority="high" to the LCP image and ensure it is not lazy-loaded; (4) large image file size — serve next-gen formats (WebP/AVIF), correct dimensions, and a srcset. Measure with both lab tools (Lighthouse) and field data (CrUX via PageSpeed Insights) — they often differ.

Explain React's reconciliation algorithm. How does it decide what to re-render?

React performs a diff of the virtual DOM (fiber tree) against the previous render. The key assumptions that make it O(n): components of the same type at the same position are updated in place; components of different types at the same position are unmounted and remounted; elements in a list are matched by key. When state or props change in a component, React re-renders that component and all its descendants by default. Memoization (React.memo, useMemo, useCallback) prevents re-renders only when the reference equality check passes — which means object and array props created inline always trigger re-renders even with memo.

Build a debounced search input component. Explain your implementation choices.

Implement with useEffect and a cleanup function: create a setTimeout inside useEffect keyed to the input value, return a cleanup that calls clearTimeout. This means the timeout resets on every keystroke and fires only after the user pauses. Important details: (1) the delay should be an argument, not hardcoded to 300ms; (2) show a loading indicator while the fetch is in-flight; (3) cancel in-flight fetch requests if a new one starts (AbortController) to prevent race conditions where a slower earlier request resolves after a faster later one; (4) debounce vs throttle distinction — debounce waits for a pause, throttle fires at a regular interval regardless of pauses.

What is the CSS box model, and what does box-sizing: border-box actually do?

The CSS box model: every element is a box with content, padding, border, and margin layers. In the default box-sizing: content-box, width and height apply only to the content area — padding and border are added on top, so a div with width: 200px, padding: 20px, and border: 1px is actually 242px wide. In border-box, width and height include padding and border — that same div is 200px wide total, with the content shrinking to 158px. border-box makes layout arithmetic predictable, which is why every modern CSS reset includes *, *::before, *::after { box-sizing: border-box; }.

Describe how you would make a complex multi-step form accessible for keyboard-only and screen-reader users.

Keyboard: ensure all interactive elements are reachable via Tab in a logical order, use visible focus indicators (do not suppress outline without a custom replacement), implement Escape to close modals, Arrow keys for custom widgets (date pickers, select menus). Screen reader: use semantic HTML first (fieldset + legend for groups, label for every input, type="submit" for submit buttons); add aria-describedby to connect inputs with validation messages; use aria-live or role="alert" to announce dynamic errors; set focus to the error summary or the first invalid field after a failed submission. For multi-step forms specifically, use aria-current="step" on the current step indicator and announce step changes.

What is the difference between localStorage, sessionStorage, and cookies, and how do you decide which to use?

localStorage: persists across sessions, 5-10MB, not sent with HTTP requests, accessible by any same-origin JS (XSS risk). sessionStorage: same API as localStorage but cleared when the tab closes, useful for tab-scoped state. Cookies: sent with every matching HTTP request, can be HttpOnly (not accessible to JS — XSS protection), can be Secure (HTTPS only), can be SameSite (CSRF protection), limited to ~4KB. For auth tokens: use HttpOnly Secure cookies — they are not accessible to JS (preventing XSS token theft) and you control expiry via Max-Age. Avoid storing JWTs in localStorage for authenticated sessions — a single XSS vulnerability exposes every user's token.

Tell me about a frontend project where you had to make significant performance decisions. What did you trade off?

Pick a project where performance was actually a constraint, not a side note. Name the specific metric that was poor (LCP, TTI, bundle size, render time). Describe the investigation — what tool showed you the bottleneck. Then name the tradeoff: code splitting improves initial load but adds waterfall requests for lazy chunks; memoization reduces re-renders but increases memory usage and cognitive complexity; SSR improves first paint but adds server cost and complexity. Close with a measurable outcome.

What happens in the browser when you type a URL and press Enter? Focus on the rendering pipeline.

DNS resolution → TCP connection → TLS handshake → HTTP request → server returns HTML → browser parses HTML into DOM (parser-blocking on synchronous scripts encountered mid-HTML) → parses CSS into CSSOM → combines DOM + CSSOM into render tree → layout (calculates element geometry) → paint (converts to pixels in layers) → composite (GPU assembles layers into final frame). Key performance touchpoints: render-blocking CSS must fully download before layout; render-blocking synchronous JS in pauses HTML parsing; defer and async attributes move JS execution out of the critical path; CSS animations that trigger only compositing (transform, opacity) are faster than those that trigger layout (width, height, top, left).

Tell me about a time you disagreed with a designer about a UI decision. How did you resolve it?

Name the specific disagreement — implementation complexity, performance impact, accessibility concern, or cross-browser compatibility. Describe how you brought data or a prototype to the conversation rather than just asserting your opinion. Good outcomes: the designer understood the constraint and adjusted the design; you found a middle solution that met both the design intent and your constraint; or you implemented their design after understanding why the intent outweighed your concern. Be honest if you were overruled — explain what you accepted and why.

How does CSS specificity work, and what is the fastest way to debug a specificity conflict?

Specificity is a 4-part score (inline : ID : class/attribute/pseudo-class : element/pseudo-element). Inline styles win over IDs, IDs over classes, classes over elements. Equal-specificity rules are resolved by source order (later wins). To debug a specificity conflict: open DevTools → Computed tab → click the property → see all declarations in specificity order with strikethroughs on overridden ones. Fixes: refactor to match specificity of the overriding rule, use :is() or :where() (:where() always has 0 specificity), or in modern CSS, use @layer to control cascade priority without increasing specificity.

What does "hydration" mean in the context of server-side rendering, and what is hydration mismatch?

Hydration is the process by which the client-side JavaScript framework "takes over" a server-rendered HTML page by attaching event handlers, reconciling the virtual DOM against the existing HTML, and making the page interactive. It does not re-render the HTML if the virtual DOM matches. A hydration mismatch occurs when the server-rendered HTML does not match what the client's framework would have rendered — React throws a warning and re-renders from scratch (destroying the SSR performance benefit). Common causes: rendering Date.now() on server and client (different timestamps), accessing window or localStorage during render (only available client-side), and dynamic data that changes between server render and client hydration.

Where do you want to be in your career in three years, and how does frontend fit into that?

Be honest about your direction — specialist (deep in performance, accessibility, design systems, or web platform), fullstack (using frontend as a foundation to expand into backend and infrastructure), or technical lead / staff (primarily a frontend IC who influences architecture decisions). Tie your answer to what this specific role offers. If you genuinely do not know, say so and describe how you will learn — "I want to experience shipping a design system at scale before deciding whether to stay specialized or broaden out."

Do frontend developer interviews still include LeetCode-style algorithm questions?

Less than they used to, but not zero. FAANG and adjacent companies (Netflix, Shopify, Stripe) still include one algorithm round, though typically at easier difficulty than a general SWE loop. Most product companies and startups have replaced algorithms with UI builds, JavaScript runtime questions, and systems/architecture discussions. Assume you need basic arrays, hashmaps, and recursion — but not graph algorithms or dynamic programming at senior frontend level.

Should I specialize in React, or learn Vue and Angular too?

Specialize in React if you are targeting US tech companies — it is still the dominant framework in 2026 at over 60% market share among job postings. Learn the underlying JavaScript deeply enough that framework migration is a tooling exercise, not a relearning exercise. Vue knowledge is valuable at agencies and some European companies. Angular knowledge is valuable at enterprise and financial services companies. If the job posting lists a specific framework, match it.

How important is TypeScript for frontend roles in 2026?

It is effectively required at mid-level and above. Nearly every production React codebase uses TypeScript. Knowing TypeScript means being able to type complex component props, use generics for hooks, and understand why "as any" is a code smell. If your current role uses JavaScript, start writing TypeScript in your personal projects immediately — it will come up in the take-home.

Will I be expected to know Node.js and backend concepts as a frontend developer?

Basic familiarity is expected — HTTP methods, REST vs GraphQL, how authentication flows work, and what happens on the server during SSR. You do not need to be able to build a backend from scratch, but you do need to be able to read an API contract and understand a Next.js API route. "I only do the frontend" is a flag at companies with collaborative full-stack teams.

Is it worth doing a frontend take-home that will take more than 4 hours?

Only if the company is a strong preference. The standard take-home should take 2-4 hours; anything more signals either poor interview design or unrealistic expectations. If the take-home has no defined scope, set your own: do 3 hours of work, submit what you have, and write a brief README describing what you would add with more time. How you scope and communicate matters as much as the code output.

Technology$70,000 - $150,000

Frontend Developer Interview Questions

What 2026 frontend interviews actually test

Frontend interviews moved away from pure algorithm questions toward browser internals, performance, and accessibility — especially post-2024 when Core Web Vitals became a revenue-visible metric. These questions map to patterns at SaaS companies, consumer apps, and design-led startups, with answer frameworks that match how senior engineers and engineering managers actually score candidates.

Typical rounds

End-to-end time

3-5 weeks

Questions covered

What the Frontend Developer interview loop actually looks like

Recruiter Screen

• Phone call• 30 min

Framework experience (React / Vue / Angular), years of experience, compensation. They will usually ask about one specific technology on your resume to confirm basic familiarity.

Hiring Manager Screen

• Video call• 45 min

Project depth — one UI or component you are proud of, technical decisions you made, how you think about performance and user experience. Not a code screen.

Technical Screen / Take-Home

• Live coding in CodeSandbox or take-home UI build (48 hrs)• 90 min

Build a small interactive component from scratch — a form with validation, a virtualized list, or a data-fetching component with loading/error states. Tests whether you write production-quality component code, not just toy examples.

Onsite / Virtual Loop

• 3-4 back-to-back sessions• 210 min

1 JavaScript deep dive (closures, event loop, async/await), 1 systems or architecture question (how would you design a component library), 1 CSS/layout problem, 1 behavioral with a cross-functional partner (designer or PM).

Bar Raiser or Peer Review

• Video call with senior engineer• 45 min

Code review of your take-home or a discussion of a past project. They want to see how you respond to feedback and whether you have opinions about code quality.

14 Frontend Developer interview questions

Tap any question to see what the interviewer is really asking, how to structure your answer, and the red flags to avoid.

What they're really asking

Do you understand how JavaScript actually executes asynchronous code, or do you just know that async/await "works"? This is the single most common deep JavaScript question in frontend interviews and the one most candidates get partially wrong.

Answer framework

The call stack executes synchronous JavaScript one frame at a time. When it empties, the event loop checks the microtask queue first (Promises, queueMicrotask, MutationObserver callbacks) and drains it completely before picking up a single task from the task queue (setTimeout, setInterval, I/O callbacks). This means a microtask that schedules another microtask can starve the task queue indefinitely. Concrete example: console.log("sync"), then Promise.resolve().then(() => console.log("microtask")), then setTimeout(() => console.log("task"), 0). Order: sync → microtask → task.

What a strong answer signals

You name both queues and explain that microtasks drain completely before any task runs. You give a correct execution-order example without needing to run the code. You can explain why long microtask chains block rendering (rendering is scheduled as a task).

Red flags to avoid

•"setTimeout with 0 runs immediately" — it does not, it goes to the task queue after microtasks drain
•Conflating the task queue and microtask queue into "the async queue"
•Cannot predict the output of a simple async/Promise example without running it

How Frontend Developer hires actually get decided

Approximate weight hiring committees place on each dimension. Use this to focus your prep on what actually moves the decision.

JavaScript depth and framework fluency

35%

Event loop, closures, async patterns, and React internals (reconciliation, hooks contract). Candidates who know React APIs but not the underlying model fail senior screens regularly.

UI problem-solving (take-home or live build)

25%

Code quality, state management decisions, edge case handling, and accessibility in the component they build. This is the clearest signal of how a candidate will actually produce code on the team.

Performance and browser internals

20%

Core Web Vitals, rendering pipeline, bundle optimization. Weighted heavily at companies where frontend performance is a business metric (e-commerce, media, consumer apps).

Accessibility and standards compliance

10%

ARIA, keyboard navigation, semantic HTML, screen reader compatibility. This dimension has increased in weight at enterprise and government-adjacent companies since 2025 EU regulations.

Behavioral / collaboration signal

10%

Designer collaboration, handling of technical debt, cross-functional communication. Weighted more at product-led companies where frontend engineers work directly with PMs and designers.

How to prepare for a Frontend Developer interview

Build something real with your target framework before your screen

Frontend take-homes expose candidates who have used React but never built from scratch. Before your loop, build a small but complete feature — a paginated data table, a form with server-validated fields, or a virtualized list — without copying from Stack Overflow. The act of building under constraint builds the muscle memory the take-home evaluates.

Run Lighthouse on a real site you own and fix what you find

Core Web Vitals questions are now standard at senior level, but candidates who have only read about LCP and CLS perform worse than those who have actually fixed a score. Deploy a personal project, run it through PageSpeed Insights, and address whatever Lighthouse flags. You will learn the optimization vocabulary from experience, not memorization.

Know the JavaScript event loop well enough to predict output order

Every frontend loop at a mature company includes at least one async/Promise execution-order question. Practice predicting console.log order for code mixing setTimeout, Promise.resolve, async/await, and queueMicrotask. Being able to reason through these without running the code is a senior-level signal.

Study WCAG 2.2 at the practice level, not just the definition level

Accessibility interview questions have increased significantly post-EU Accessibility Act (enforcement started 2025). Do not just memorize WCAG levels — go through a checklist with a real screen reader (NVDA on Windows, VoiceOver on Mac) on one page you have built. The experience of hearing your own UI read aloud teaches you more than any documentation.

Prepare a "technical debt decision" story

Almost every senior frontend behavioral loop includes a question about technical debt — when to pay it down vs. ship features. Before your interviews, identify a real example where you made this tradeoff, explain the criteria you used, and be able to defend it under follow-up. Candidates who have only shipped clean code look inexperienced; those who have navigated messy codebases thoughtfully look senior.

Frontend Developer interview FAQs

More for Frontend Developers

Frontend Developer resume example Frontend Developer cover letter Frontend Developer salary guide Skills for Frontend Developers How to become a Frontend Developer

Interview prep for related roles

Full Stack Developer interview questions

Technology • $80,000 - $170,000

Software Engineer interview questions

Technology • $80,000 - $180,000

Data Analyst interview questions

Technology • $60,000 - $120,000