Frontend Developer Interview Questions & Answers

1. What is a closure, and where have you actually used one?

Why they ask it: closures are the foundation of half of practical JavaScript — module patterns, event handlers, hooks, debounce. They want to confirm you understand why a function "remembers" its scope, and the "where have you used one" half is what separates memorizers from people who write real code.

"A closure is a function bundled together with the variables from the scope where it was defined — so even after that outer scope has returned, the inner function still has live access to those variables. The classic gotcha is a loop that creates handlers: with var, every handler closes over the same shared variable and they all log the final value; with let, each iteration gets its own binding, so they capture distinct values. Where I use closures constantly is anything stateful-but-private — a debounce function that keeps a timer ID across calls, or a counter factory. In React, every hook is leaning on closures, which is exactly why a stale closure over old state inside a useEffect is such a common bug."

2. Walk me through what the event loop does, and the difference between a microtask and a macrotask.

Why they ask it: the event loop is the single concept that explains async behavior, why the UI freezes during heavy work, and surprising ordering bugs. Distinguishing microtasks from macrotasks is the senior-level signal — it predicts whether your promise ordering will be correct.

"JavaScript runs on a single thread with one call stack, so the event loop is the mechanism that lets it do non-blocking work. When the stack is empty, the loop pulls the next queued callback and runs it. The key nuance is two queues: the macrotask queue holds things like setTimeout callbacks and DOM events, while the microtask queue holds promise .then callbacks and queueMicrotask. After every single task, the engine drains the entire microtask queue before rendering or taking the next macrotask. That's why a resolved promise's callback runs before a setTimeout(fn, 0) queued earlier. It also explains a real performance trap: a runaway chain of microtasks can starve rendering and freeze the page, because the browser never gets a chance to paint between them."

3. Implement a debounce function.

Why they ask it: it's the perfect small frontend problem — it combines closures, timers, the event loop, and this/argument forwarding in one task you'd genuinely write at work (search-as-you-type, resize handlers). It reveals far more than its size suggests.

"Debounce delays running a function until it's stopped being called for a given wait — so a search input only fires the request after the user pauses typing. I keep a timer ID in a closure; each call clears the pending timer and schedules a new one. I forward arguments and preserve this so it works as a method too. I'd mention you sometimes want a leading-edge variant that fires immediately, and that throttle is the cousin that fires at most once per interval — I'd ask which behavior they want."

function debounce(fn, wait) {
  let timer;                       // kept alive by the closure
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, args);        // preserve this + arguments
    }, wait);
  };
}

4. What's the difference between == and ===, and when is loose equality ever acceptable?

Why they ask it: it's a fast probe of whether you understand type coercion, one of JavaScript's most bug-prone corners. The mature answer isn't "never use ==" — it's knowing the one or two cases where it's deliberate.

"=== compares value and type with no coercion; == coerces the operands to a common type first, which produces surprises like '' == 0 or [] == false being true. My default is always === because it's predictable and lint rules enforce it. The one place I'll deliberately use loose equality is the idiom x == null, which is a concise way to check for both null and undefined in a single comparison. Outside that, coercion bugs cost more than the keystrokes saved, so I keep it explicit."

5. When would you reach for Flexbox versus Grid, and how do you center an element?

Why they ask it: layout is the daily work of frontend, and a confident, correct answer signals you build interfaces without fighting the browser. The "center an element" follow-up is a classic — it instantly reveals whether modern CSS is muscle memory or guesswork.

"I think of it by dimensionality. Flexbox is for laying out items along one axis — a nav bar, a toolbar, a row of cards that wraps — where I care about distribution and alignment in a single direction. Grid is for two-dimensional layout where I'm placing things into rows and columns at once, like a page shell or a card gallery with aligned tracks. They compose well: a Grid page with Flex inside each cell. For centering, the modern answer is one rule — display:grid; place-items:center on the parent, or display:flex; align-items:center; justify-content:center. I'd avoid the old absolute-position-and-transform hack unless I specifically need it, since it's harder to maintain."

6. Explain specificity and the box model — and how you'd debug an element that's "the wrong size."

Why they ask it: specificity and the box model are the two things that cause the most "why won't this style apply / why is this too wide" frustration. They want to see you debug methodically with dev tools rather than pile on !important.

"Specificity is how the browser breaks ties between conflicting rules — inline styles beat IDs, which beat classes and attributes, which beat element selectors; !important overrides the lot and is a smell I avoid because it starts an arms race. The box model is how an element's total size is computed from content, padding, border, and margin. The single most common 'too wide' bug is forgetting box-sizing:border-box, so padding and border add onto the declared width instead of being included. To debug a wrong-size element I open dev tools, inspect the computed box diagram to see exactly which layer is adding pixels, and check the Styles pane to see which rule won and why — that beats guessing every time."

7. How would you make a custom dropdown or modal accessible?

Why they ask it: custom widgets are where accessibility usually breaks, and building one correctly is a strong senior signal. It tests semantic HTML, keyboard support, focus management, and whether you reach for ARIA appropriately rather than sprinkling it everywhere.

"My first instinct is to use the platform — a native <select> or <dialog> gives you accessibility for free, so I only build a custom widget when design genuinely requires it. When I do, I follow the established pattern. For a modal: it needs role=\"dialog\" and aria-modal, focus must move into it on open and return to the trigger on close, focus must be trapped inside while it's open, Escape must close it, and the background content should be inert so a screen reader doesn't wander into it. For a dropdown, the trigger needs aria-expanded, options are navigable with arrow keys, Enter selects, and Escape closes. The principle is: semantics first, manage focus deliberately, support the keyboard, and only add ARIA to fill the gaps the native element would have covered."

8. What does WCAG actually ask of you day to day, and how do you test for it?

Why they ask it: they want to know accessibility is a habit, not a checkbox you tick before launch. Naming concrete, testable criteria — and a real testing workflow — separates developers who ship accessible UI from those who say the word.

"Day to day, WCAG comes down to a handful of habits: meaningful text alternatives for images, color contrast that meets the AA ratio, every interactive element reachable and operable by keyboard with a visible focus indicator, form inputs with associated labels, and not relying on color alone to convey meaning. I test in layers — an automated pass with an in-browser auditor to catch the obvious misses, then the test that finds the real problems: I unplug the mouse and tab through the whole flow, and I run a screen reader over the key paths. Automated tools only catch maybe a third of issues, so the keyboard-and-screen-reader pass is the one that actually matters."

9. Explain the virtual DOM and reconciliation — and why keys matter in a list.

Why they ask it: it's the core mental model of React. Getting keys right is a daily correctness issue, and candidates who use the array index as a key (then hit subtle bugs) reveal they don't understand what reconciliation is doing.

"When state changes, React builds a new tree of elements in memory and diffs it against the previous one, then applies the minimal set of real DOM mutations — that diff is reconciliation, and it exists because touching the real DOM is expensive. Keys are how React matches elements across renders within a list: a stable, unique key tells React 'this is the same item, just moved or updated,' so it preserves state and DOM instead of tearing down and rebuilding. Using the array index as a key breaks this the moment the list reorders or you insert in the middle — React mismatches items, and you get bugs like a checkbox's checked state sticking to the wrong row. So I key by a stable id from the data, never the index unless the list is static and append-only."

10. What problem do the rules of hooks solve, and when do you actually need useMemo or useCallback?

Why they ask it: hooks are everywhere, and misuse is rampant — people either break the rules or wrap everything in useMemo as a reflex. They want to see you understand the mechanism and optimize deliberately, not cargo-cult.

"Hooks must be called in the same order on every render, which is why you can't call them conditionally or in loops — React tracks hook state positionally, so a changing call order would scramble which state belongs to which hook. As for memoization: I don't reach for useMemo or useCallback by default, because they aren't free — they cost memory and a dependency comparison. I use useMemo when a computation is genuinely expensive, and useCallback when I'm passing a function down to a memoized child that would otherwise re-render because the function identity changes each time, or when a function is a dependency of an effect. The honest rule is: measure first, memoize the specific hot spot, and don't pre-optimize cheap renders — the indirection often costs more than it saves."

11. How do you decide where state should live — local, lifted, context, or a store?

Why they ask it: state management is where frontend apps get messy, and this question separates developers who can architect from those who reach for a global store reflexively. It's especially weighted in senior loops.

"I keep state as local as possible and only lift it when more than one component genuinely needs it. The progression I follow: local useState first; lift to the nearest common parent when siblings must share it; reach for context only for things that are truly app-wide and change rarely — theme, current user, locale — because context re-renders every consumer when it changes, so it's a poor fit for high-frequency state. For complex client state I'd use a dedicated store with selectors so components subscribe only to the slice they use. And critically, I separate server state from client state — data fetched from an API has its own caching, loading, and invalidation needs, so I use a data-fetching library for it rather than hand-rolling it into a global store. Most 'state management is hard' pain comes from conflating those two."

12. A page feels slow to load and janky to interact with. How do you diagnose and fix it?

Why they ask it: it's the realistic version of a performance question — open-ended, no single answer. They want a measure-first method and familiarity with Core Web Vitals, not a guess.

"I measure before I touch anything — I'd profile with the browser's performance panel and a Lighthouse run, and look at the Core Web Vitals to localize the problem. Slow loading usually means too much JavaScript or render-blocking resources, so I'd code-split and lazy-load below-the-fold routes, defer non-critical scripts, and right-size images with modern formats and responsive sizing. A poor LCP often points at the hero image or a slow server response. Janky interaction — a poor INP — usually means long tasks blocking the main thread, so I'd break up heavy work, debounce expensive handlers, and virtualize long lists so I'm not rendering thousands of DOM nodes. Layout shift (CLS) is almost always missing dimensions on images or late-injected content, fixed by reserving space. The discipline is the same as debugging: localize with evidence, fix the biggest contributor first, re-measure."

13. What's the difference between a reflow and a repaint, and why does it matter?

Why they ask it: it's a precise test of whether you understand the browser's render pipeline, which underlies most rendering-performance work. The strong signal is connecting it to a concrete optimization, like batching DOM reads and writes.

"A repaint is the browser redrawing pixels when something purely visual changes — a color or a shadow — without affecting geometry. A reflow (layout) is more expensive: it's the browser recalculating the geometry of elements when something changes size or position, and it can cascade to the rest of the page. The trap is layout thrashing — interleaving DOM reads (like offsetHeight) and writes in a loop, which forces a synchronous reflow on every iteration because each read needs up-to-date layout. The fix is to batch all reads, then all writes. For animation, I prefer transform and opacity because they can be handled by the compositor and skip layout and paint entirely, which is why they stay smooth at 60fps while animating something like top or width stutters."

14. Tell me about a time you disagreed with a designer or PM about how something should be built.

Why they ask it: frontend developers live at the intersection of design intent and technical reality, and how you navigate that tension predicts whether you'll be a partner or a roadblock. They're watching for someone who pushes back with evidence and a better option, then commits.

Situation: "A designer specced an autoplaying carousel as the hero of our landing page. Task: I owned the build, and I was concerned it would hurt both accessibility and performance — autoplay is a known accessibility issue, and the image set was heavy enough to wreck our LCP. Action: Instead of just refusing, I built a quick prototype both ways and measured: the carousel pushed LCP from 1.9s to over 4s and failed a keyboard pass. I showed the designer the numbers and the recording, and proposed a single strong hero image with the other content below — keeping the visual impact she wanted without the cost. Result: We shipped the static hero, LCP stayed under 2 seconds, and the page passed our accessibility checklist. The conversion rate actually came in higher than the carousel mockup tested. The lesson: bring a measured alternative, not just an objection — design and engineering align fast around evidence."

15. Tell me about a frontend performance or quality problem you owned end to end.

Why they ask it: it reveals whether you take responsibility for the user's actual experience or stop at "it works on my machine." Strong frontend developers treat performance and quality as theirs to own, not the next team's problem.

Situation: "Our dashboard had grown to where the main bundle was over 2MB and first load took eight-plus seconds on a mid-range phone; support tickets about 'the app is slow' were climbing. Task: No one owned performance, so I picked it up and set a budget. Action: I profiled the bundle, found two heavy dependencies pulling in everything when we used a sliver of each, and replaced them with lighter alternatives. I route-split so each view loaded only its own code, lazy-loaded the charting library that only one page needed, and virtualized a table that was rendering 5,000 rows at once. Then I added a CI check that fails the build if the bundle crosses the budget, so it couldn't quietly regress. Result: First load dropped from over eight seconds to about two and a half, the bundle shrank by roughly 60%, and the 'slow' tickets stopped. The guardrail mattered as much as the fix — it kept the win from eroding."