Top Frontend Developer Interview Questions & Answers

Definition: A closure is a function that retains access to variables from its outer (enclosing) scope even after the outer function has returned. Why it works: JavaScript functions carry a reference to their lexical environment. Practical example — counter factory: function createCounter() { let count = 0; return { increment: () => ++count, getCount: () => count }; } Each call to createCounter() creates an independent closure with its own count variable. Real-world uses of closures: • Module pattern and data privacy • Partial application and currying • Event handlers that reference loop variables • Memoization Common gotcha: Closures in loops with `var` capture the same variable — use `let` or an IIFE to fix.

The event loop model: 1. Execute code on the call stack 2. When stack is empty → drain the entire microtask queue 3. Take the next macrotask from the queue 4. Repeat Microtasks (higher priority): • Promise callbacks (.then, .catch, .finally) • queueMicrotask() • MutationObserver Macrotasks (lower priority): • setTimeout / setInterval • I/O operations • UI rendering Key insight: All microtasks run before the next macrotask. So Promise.resolve().then() executes before setTimeout(..., 0). Why this matters: A long chain of microtasks blocks rendering just as badly as synchronous code. The browser renders between macrotasks, not between microtasks.

Timing difference: • useEffect — fires asynchronously after the browser paints • useLayoutEffect — fires synchronously after DOM mutations, before paint When to use each: ✅ useEffect (default choice): • Data fetching • Subscriptions and event listeners • Analytics tracking • Any non-visual side effect ✅ useLayoutEffect (only when needed): • Measuring DOM elements (getBoundingClientRect) • Preventing visual flicker (tooltip positioning) • Synchronous DOM mutations Rule of thumb: Default to useEffect. Switch to useLayoutEffect only if you see a visual glitch. useLayoutEffect blocks painting, so overusing it hurts perceived performance.

Decision framework: Local state (useState/useReducer): • State used by a single component or 1-2 levels down • Form inputs, toggles, UI state Context (React.createContext): • State many components at different depths need • Changes infrequently (theme, auth, locale) • ⚠️ Context triggers re-renders in ALL consumers on change State management library (Redux, Zustand): • Complex client state with frequent updates • Shared across many unrelated components • Need middleware (async, devtools, persistence) Server state (React Query, SWR): • Data from APIs — don't put this in Redux! • Handles caching, revalidation, optimistic updates Key insight: Context is a poor choice for frequently-changing values (form inputs, real-time data) because it re-renders every consumer.

The three Core Web Vitals: 1. LCP (Largest Contentful Paint) — Loading • Target: < 2.5s • Optimize: Preload hero images, use SSR/SSG, eliminate render-blocking resources, use CDNs 2. INP (Interaction to Next Paint) — Interactivity • Target: < 200ms • Optimize: Break long tasks, use web workers, defer non-critical JS, avoid layout thrashing 3. CLS (Cumulative Layout Shift) — Visual stability • Target: < 0.1 • Optimize: Set explicit dimensions on images/videos, reserve space for ads/embeds, avoid dynamic content injection above the fold Why it matters: These metrics directly affect Google's search ranking. Improving them boosts both UX and SEO.