Frontend Interview Questions

• SEO depends on it. Google’s crawler reads your HTML structure to understand page content. A poorly structured page with <div> soup ranks worse than one using proper heading hierarchy (<h1> through <h6>), even with identical visible content.
• Accessibility starts here. Screen readers (JAWS, NVDA, VoiceOver) navigate via HTML landmarks. If your page is all <div> and <span>, a blind user literally cannot navigate it. Proper HTML = legal compliance (ADA, WCAG 2.1 AA).
• Performance impact. The browser’s parsing pipeline (HTML tokenization -> DOM construction -> CSSOM -> Render Tree) is directly affected by HTML structure. Deeply nested DOM trees (1500+ nodes) measurably slow rendering — Google Lighthouse flags this.
• SSR and hydration. In frameworks like Next.js, the server sends raw HTML first. If that HTML is malformed or semantically meaningless, you get layout shifts (CLS issues) and hydration mismatches.

• How does the browser parse HTML differently from XML, and why does that matter for error recovery?
• What happens when you put a <div> inside a <p> tag — and why?
• How does HTML structure affect Core Web Vitals scores?

• <header> / <footer> — page or section-level header/footer (not just “the top/bottom of the page”)
• <nav> — primary navigation blocks (screen readers let users jump directly to <nav>)
• <main> — the primary content area (only ONE per page)
• <article> — self-contained content that makes sense independently (a blog post, a product card)
• <section> — thematic grouping with a heading (use <section> when you’d give it a heading, <div> when it’s purely for styling)
• <aside> — tangentially related content (sidebars, callouts)
• <figure> / <figcaption> — images, charts, code snippets with captions
• <time> — dates and times (machines can parse <time datetime="2025-03-15">)

• Accessibility: VoiceOver on macOS lets users jump between landmarks. A site with proper <nav>, <main>, <aside> gives blind users the same quick-scan ability that sighted users get visually. Without it, they hear every single element linearly.
• SEO: Google explicitly uses semantic structure for featured snippets. An <article> with proper <h1> -> <h2> hierarchy is more likely to appear in search features than a <div> soup page.
• Maintainability: 6 months later, <nav> is instantly understandable. <div class="sc-bwzfXH"> (styled-components auto-generated) means nothing.

• When would you use <section> vs <div> — what is the actual rule?
• How do ARIA roles relate to semantic HTML, and when do you need ARIA even with semantic elements?
• A designer gives you a card layout — walk me through which semantic elements you would choose and why.

• <meta charset="UTF-8"> — Character encoding. Must be in the first 1024 bytes of the document. Without it, international characters can break (mojibake).
• <meta name="viewport" content="width=device-width, initial-scale=1.0"> — Controls responsive behavior on mobile. Without this, mobile browsers render at ~980px width and scale down, breaking your responsive design completely.
• <meta name="description" content="..."> — The 150-160 character snippet Google shows in search results. Directly affects click-through rate. This is not a ranking factor, but it drives CTR which indirectly affects ranking.
• <meta name="robots" content="noindex, nofollow"> — Controls crawler behavior. Critical for staging environments (you do NOT want Google indexing your staging site).
• Open Graph tags (<meta property="og:title">, og:description, og:image) — Controls how the page appears when shared on social media. A missing og:image means your link looks bland on Slack, Twitter, LinkedIn.
• <meta http-equiv="Content-Security-Policy"> — Can define CSP inline (though HTTP headers are preferred for production).
• <link rel="canonical" href="..."> — Not technically a meta tag but often grouped with them. Tells search engines the “real” URL to avoid duplicate content penalties.

• What happens if you forget the viewport meta tag on a mobile-first site?
• How do Open Graph tags differ from Twitter Card tags, and when do you need both?
• How would you handle dynamic meta tags for a page with user-generated content (e.g., a product page)?

• Start on a new line (create a line break before and after)
• Take up the full available width of their parent by default
• Respect width, height, margin, and padding on all sides
• Stack vertically

• Do not start on a new line — they flow within text
• Only take up as much width as their content needs
• Vertical margin and padding do not push other elements away (this is the gotcha most people miss). Horizontal margin/padding works fine, but vertical margin is ignored and vertical padding “bleeds” without affecting layout.
• Cannot contain block elements (putting a <div> inside a <span> is invalid HTML)

• Flows inline (sits within text) BUT respects width, height, and vertical margin/padding like a block element
• Useful for buttons, badges, or any element that needs dimensions but should sit inline

• Why can you not set a fixed height on an inline element, and what happens if you try?
• What is display: inline-flex and when would you use it?
• If I set margin-top: 20px on a <span>, what happens and why?

• Standards mode (triggered by <!DOCTYPE html>): The browser follows the W3C/WHATWG spec precisely. Box model works as expected. Modern CSS behaves correctly.
• Quirks mode (triggered by a missing or malformed DOCTYPE): The browser emulates old IE5/Navigator 4 behavior. The box model changes (width includes padding and border, like box-sizing: border-box but inconsistently applied). Inline elements can have height. Various CSS calculations break in subtle ways.
• Almost-standards mode: Triggered by some older DOCTYPEs. Mostly standards-compliant but with one key difference in how table cell vertical sizing works.

• What visual differences would you notice if a page accidentally renders in quirks mode?
• How does DOCTYPE affect the CSS box model behavior?
• Why is the HTML5 DOCTYPE so much shorter than the XHTML 1.0 DOCTYPE?

• Persists indefinitely (until explicitly cleared by code or user)
• Scoped to the origin (protocol + domain + port)
• ~5-10 MB limit (varies by browser)
• Never sent to the server automatically
• Synchronous API (blocks the main thread — avoid storing large data)
• Use case: user preferences, theme settings, cached non-sensitive data

• Persists only for the browser tab session — gone when the tab closes
• Scoped to the origin AND the specific tab (two tabs on the same site have separate sessionStorage)
• ~5-10 MB limit
• Never sent to the server automatically
• Use case: form data preservation during a multi-step wizard, temporary UI state

• Configurable expiration (Expires / Max-Age header) — can be session or persistent
• Sent to the server with every HTTP request to the matching domain (this is the critical difference)
• ~4 KB limit per cookie
• Scoped by domain and path
• Can be set as HttpOnly (inaccessible to JavaScript — critical for auth tokens), Secure (HTTPS only), SameSite (CSRF protection)
• Use case: authentication tokens, session IDs, server-needed preferences

• Never store JWTs or auth tokens in localStorage — XSS attacks can read it trivially. Use HttpOnly + Secure + SameSite=Strict cookies instead.
• localStorage is vulnerable to XSS but NOT to CSRF. Cookies are vulnerable to CSRF but can be protected with SameSite and CSRF tokens.
• IndexedDB exists for structured/larger data (hundreds of MB) but has an async API.

• A teammate stores the user’s JWT in localStorage. What is your response and what do you suggest instead?
• How does the SameSite cookie attribute prevent CSRF attacks?
• When would you choose IndexedDB over localStorage?

• Element stays in normal document flow (still occupies its original space)
• top, right, bottom, left offset it relative to where it would normally be
• Creates a new containing block for absolutely positioned children
• Common use: nudging an element slightly, or creating a positioning context for a child

• Element is removed from normal flow (other elements act as if it does not exist)
• Positioned relative to the nearest positioned ancestor (any ancestor with position other than static). If none exists, it is relative to the initial containing block (effectively the viewport)
• Common gotcha: forgetting to set position: relative on the parent, causing the absolute element to fly to the top-left of the page
• Use case: tooltips, dropdown menus, overlays positioned relative to a trigger

• Removed from normal flow
• Positioned relative to the viewport — does not move on scroll
• Gotcha: If any ancestor has transform, filter, or will-change set, it breaks fixed positioning (the element becomes fixed relative to that ancestor instead of the viewport). This is a well-known CSS bug that catches even senior developers.
• Use case: sticky headers, floating action buttons, modals

• A hybrid: acts like relative until the element reaches a scroll threshold, then acts like fixed
• Requires a top, bottom, left, or right value to define when it “sticks”
• Only sticks within its parent container — once the parent scrolls out of view, the sticky element goes with it
• Gotcha: overflow: hidden or overflow: auto on ANY ancestor breaks sticky positioning silently
• Use case: table headers that stick while scrolling, section headers in long lists

• What is a “containing block” and how does it affect absolute positioning?
• Why would position: fixed not work as expected even when set correctly? What CSS properties on ancestors could break it?
• How would you implement a sticky table header that works across browsers?

• display: flex — activates flexbox
• flex-direction: row | column | row-reverse | column-reverse — sets the main axis
• justify-content — alignment along the main axis (e.g., space-between, center, flex-end)
• align-items — alignment along the cross axis (e.g., center, stretch, baseline)
• flex-wrap: wrap — allows items to wrap to the next line (critical for responsive layouts)
• gap — spacing between items (modern replacement for margin hacks)

• flex-grow — how much extra space the item should absorb (0 = do not grow)
• flex-shrink — how much the item should shrink if space is tight (0 = do not shrink)
• flex-basis — the initial size before grow/shrink kicks in (like a “suggested width”)
• The shorthand flex: 1 means flex-grow: 1; flex-shrink: 1; flex-basis: 0% — “take equal space”
• align-self — override the container’s align-items for this specific child

• Centering anything: display: flex; justify-content: center; align-items: center — this alone solved a decade of CSS centering pain
• Sticky footer: flex container on body, flex-grow: 1 on main content
• Navigation bar: justify-content: space-between with logo on one end and nav links on the other
• Equal-height cards: flex items in a row naturally stretch to equal height via align-items: stretch (the default)

• flex-basis vs width: flex-basis wins over width when both are set (in the flex-direction axis). Use flex-basis for flex-direction sizing.
• min-width: auto is the default for flex items, meaning a flex item will NOT shrink below its content size. This causes overflow bugs. Fix: min-width: 0 on the item.
• Text overflow in flex children: long text will push a flex item beyond its allotted space unless you add overflow: hidden; text-overflow: ellipsis; min-width: 0.

• What does flex: 1 actually expand to, and how does it differ from flex: auto?
• When would you choose Flexbox over Grid, and vice versa?
• A flex item with long text is overflowing its container. How do you fix it and why does this happen?

• display: grid activates it on the container
• grid-template-columns / grid-template-rows — define the track sizes. Example: grid-template-columns: 1fr 2fr 1fr creates three columns where the middle is twice as wide.
• fr unit — a fraction of available space (like flex-grow but for grid tracks)
• gap (or row-gap / column-gap) — spacing between tracks
• grid-column / grid-row — explicitly place items spanning tracks. Example: grid-column: 1 / 3 spans columns 1 and 2.
• grid-template-areas — name areas for readable layout definitions

/* Named grid areas — incredibly readable */
.layout {
  display: grid;
  grid-template-areas:
    "header header header"
    "sidebar main aside"
    "footer footer footer";
  grid-template-columns: 200px 1fr 200px;
  grid-template-rows: auto 1fr auto;
}

• repeat() and minmax(): grid-template-columns: repeat(auto-fill, minmax(250px, 1fr)) creates a responsive grid that automatically adjusts column count without media queries. This single line replaces dozens of lines of media query + flexbox code.
• auto-fill vs auto-fit: auto-fill creates empty tracks if there is extra space; auto-fit collapses empty tracks so items stretch. The difference is subtle but matters for responsive behavior.

• Use Grid when you need to control both rows and columns (page layouts, dashboards, card grids)
• Use Flexbox when you need to distribute items in a single direction (navbars, toolbars, centering)
• In practice, they work together: Grid for the page layout, Flexbox for component-level alignment inside grid cells

• How would you create a responsive card grid that adjusts from 4 columns on desktop to 1 on mobile, without media queries?
• What is the difference between auto-fill and auto-fit in repeat()?
• How does Grid handle implicit vs explicit tracks, and when does that matter?

1. !important — overrides everything (specificity: infinite, effectively). Use sparingly — it is a maintenance nightmare.
2. Inline styles (style="...") — specificity: (1,0,0,0)
3. ID selectors (#header) — specificity: (0,1,0,0)
4. Class selectors, attribute selectors, pseudo-classes (.btn, [type="text"], :hover) — specificity: (0,0,1,0)
5. Element selectors, pseudo-elements (div, p, ::before) — specificity: (0,0,0,1)
6. Universal selector (*) — specificity: (0,0,0,0) (adds nothing)

• Specificity is compared column by column, left to right. One ID selector beats ANY number of class selectors. #header (0,1,0,0) beats .a.b.c.d.e.f.g.h.i.j (0,0,10,0).
• When specificity is equal, the last rule in source order wins (cascade order).
• !important creates a parallel specificity universe. Among !important rules, normal specificity comparison applies. This is why !important wars happen in legacy codebases.

• BEM methodology (.block__element--modifier) keeps all selectors at one class level, avoiding specificity wars entirely
• CSS Modules / CSS-in-JS scope styles automatically, making specificity less of an issue
• Tailwind CSS uses single utility classes, so specificity is uniformly low
• The :where() pseudo-class has zero specificity — great for resets/defaults that should be easily overridden
• The :is() pseudo-class takes the specificity of its most specific argument

• You write a class selector but it is not being applied. How do you debug the specificity conflict?
• What is the specificity of :is(.foo, #bar) and why could that be surprising?
• How do CSS Modules or BEM help manage specificity in large codebases?

• Minify CSS — tools like cssnano, PostCSS, or built-in bundler minification can reduce CSS by 20-40%
• Remove unused CSS — PurgeCSS (used by Tailwind) or the coverage tab in Chrome DevTools can identify dead CSS. Large apps often ship 70-90% unused CSS
• Tree-shake component-level CSS — CSS Modules, styled-components, or Tailwind JIT ensure only used styles ship

• Critical CSS — extract above-the-fold CSS and inline it in <head>. Tools: Critical, Critters (used by Angular CLI). Everything else loads async via <link rel="preload">
• Avoid render-blocking CSS — the browser will not render until all CSS in <head> is downloaded and parsed. Use media attributes to make non-critical stylesheets non-blocking: <link rel="stylesheet" href="print.css" media="print">

• Browsers match selectors right to left. .container .item span first finds ALL <span> elements, then filters up. Overly broad rightmost selectors are slow on pages with thousands of elements.
• Avoid universal selectors as the key selector: * { } or .parent * { } matches everything
• Keep selectors shallow (1-3 levels deep). BEM’s flat class structure (.card__title) is faster than nested selectors (.page .section .card .title)

• Avoid triggering layout thrashing. Properties like width, height, top, left, margin trigger expensive layout recalculations. Prefer transform: translate() for animations.
• Use will-change judiciously. It promotes elements to their own compositor layer, enabling GPU-accelerated animations. But overuse (applying it to dozens of elements) consumes memory.
• contain: layout paint — tells the browser that an element’s internals do not affect outside layout, enabling rendering optimizations
• Prefer transform and opacity for animations — these properties can be animated on the compositor thread without triggering layout or paint

• What is the difference between a layout, paint, and composite operation, and why does it matter for animations?
• How would you identify and fix a CSS performance bottleneck using Chrome DevTools?
• What is contain in CSS and when would you use it?

• box-sizing: content-box (default): width and height apply to the content only. Padding and border are ADDED on top. So width: 200px; padding: 20px; border: 1px solid = actual rendered width of 242px. This is the source of countless layout bugs.
• box-sizing: border-box: width and height include padding and border. width: 200px means 200px total, padding and border included. This is what developers expect.

*, *::before, *::after {
  box-sizing: border-box;
}

• Vertical margins between adjacent block elements collapse — the larger margin wins, they do not add up. Two elements with margin-bottom: 20px and margin-top: 30px have 30px between them, not 50px.
• Margin collapse does NOT happen with: flex/grid children, floated elements, absolutely positioned elements, or inline-block elements
• Parent-child margin collapse: a child’s margin-top can “escape” and become the parent’s margin if the parent has no padding, border, or overflow set. Fix: add padding-top: 1px or overflow: hidden to the parent.

• Why do most CSS resets set box-sizing: border-box globally, and what breaks without it?
• Explain margin collapse. When does it happen and when does it not?
• How does the box model differ for inline elements vs block elements?

• JavaScript does not physically move code. During the creation phase of an execution context, the engine scans for declarations and allocates memory for them.
• Function declarations are fully hoisted — both the name AND the function body are available before the line they are written on.
• var declarations are hoisted but initialized to undefined. The assignment happens at runtime when that line executes. This is why console.log(x); var x = 5; logs undefined, not an error.
• let and const declarations are hoisted but NOT initialized. They exist in a Temporal Dead Zone (TDZ) from the start of the block until the declaration line. Accessing them in the TDZ throws a ReferenceError.
• Function expressions and arrow functions assigned to var are treated as var — hoisted as undefined. Assigned to let/const — in the TDZ.

console.log(a); // undefined (var is hoisted, initialized to undefined)
console.log(b); // ReferenceError: Cannot access 'b' before initialization
console.log(c()); // "hello" (function declaration is fully hoisted)
console.log(d()); // TypeError: d is not a function (var hoisted as undefined)

var a = 1;
let b = 2;
function c() { return "hello"; }
var d = function() { return "world"; };

• The TDZ is why let/const are safer — they fail loudly instead of silently giving undefined
• Hoisting is why you can call function declarations before they appear in code (useful for structuring files with main logic at top, helper functions below)
• Understanding hoisting is essential for debugging closure-related bugs and var in loops

• What is the Temporal Dead Zone and why does it exist?
• What is the difference between hoisting a function declaration vs a function expression?
• Why does var inside a for loop cause unexpected closure behavior, and how do let/const fix it?

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Prints: 3, 3, 3 (var is function-scoped, all closures share the same i)

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Prints: 0, 1, 2 (let creates a new binding per iteration)

const user = { name: "Alice" };
user.name = "Bob"; // This WORKS — object mutation is allowed
user = { name: "Charlie" }; // TypeError — reassignment is not allowed

• If const does not make objects immutable, how do you achieve immutability in JavaScript?
• What happens if you declare var x twice in the same scope vs let x twice?
• Why does var in a loop with setTimeout produce unexpected results, and how does let fix it?

1. User clicks a specific child element (the event target)
2. The event bubbles up through the DOM tree: child -> parent -> grandparent -> … -> document
3. The listener on the parent catches the event
4. You use event.target to determine which specific child was clicked
5. You apply logic based on the target

// BAD: 1000 listeners for 1000 list items
document.querySelectorAll('li').forEach(li => {
  li.addEventListener('click', handleClick);
});

// GOOD: 1 listener on the parent
document.querySelector('ul').addEventListener('click', (e) => {
  if (e.target.tagName === 'LI') {
    handleClick(e);
  }
});

• Performance: 1 listener vs 1,000 listeners. Each listener consumes memory. In a list with thousands of items (think: a chat app, a data table), the difference is measurable — potentially saving several MB of memory.
• Dynamic elements: If you add new <li> elements after the initial render, delegation automatically handles them. Without delegation, you have to manually attach listeners to every new element.
• Memory leaks: Fewer listeners means fewer opportunities for memory leaks from forgotten removeEventListener calls.

1. Capture phase — event travels DOWN from window to the target (rarely used, but available via addEventListener('click', handler, true))
2. Target phase — event reaches the actual clicked element
3. Bubble phase — event travels UP from target to window (this is where delegation works)

• event.stopPropagation() stops bubbling (use sparingly — it can break other listeners that depend on bubbling)
• event.stopImmediatePropagation() stops bubbling AND prevents other listeners on the same element from firing

• What is the difference between event.target and event.currentTarget?
• What events do NOT bubble, and how would you handle delegation for those?
• How does React’s event system relate to native event delegation?

function createCounter() {
  let count = 0; // This variable is "closed over"
  return function() {
    count++;
    return count;
  };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
// count is not accessible from outside, but the inner function remembers it

• Data privacy / encapsulation: The module pattern uses closures to create private variables. Before ES6 modules, this was THE way to avoid global namespace pollution.
• Factory functions: createLogger('AUTH') returns a function that always prefixes logs with “AUTH” — the prefix is closed over.
• Event handlers and callbacks: Every callback that references outer variables uses closures. setTimeout, addEventListener, Promise .then() handlers.
• Partial application / currying: const add5 = createAdder(5) — the 5 is closed over.
• React hooks internally: useState, useEffect, and every hook relies on closures to associate state with the specific component instance.

function setupButtons() {
  for (var i = 0; i < 5; i++) {
    buttons[i].addEventListener('click', function() {
      console.log(i); // Always logs 5, not 0-4
    });
  }
}

const [count, setCount] = useState(0);
useEffect(() => {
  const interval = setInterval(() => {
    console.log(count); // Always logs the initial value — stale closure!
  }, 1000);
  return () => clearInterval(interval);
}, []); // Empty deps = closure captures count from first render only

• How can closures cause memory leaks, and how do you prevent them?
• Explain stale closures in React hooks and how to fix them.
• How would you use closures to implement a private variable pattern?

1. Synchronous code runs on the call stack
2. Async operations (fetch, setTimeout, DOM events) are handled by Web APIs (outside the JS engine)
3. When an async operation completes, its callback goes to the task queue (macrotask) or microtask queue
4. The event loop checks: “Is the call stack empty? If yes, move the next task from the queue to the stack.”
5. Microtasks (Promises, queueMicrotask, MutationObserver) have priority over macrotasks (setTimeout, setInterval, I/O)

• Callbacks — the original way. Problem: callback hell (deeply nested callbacks become unreadable)
• Promises — chainable, cleaner error handling via .catch(). Problem: still can get messy with many .then() chains
• async/await — syntactic sugar over Promises. Reads like synchronous code but is async. The current standard.

console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
// Output: 1, 4, 3, 2
// Sync first (1, 4), then microtask (3), then macrotask (2)

• Unhandled promise rejections used to silently fail. Modern Node.js (v15+) crashes on unhandled rejections. Always use .catch() or try/catch with await.
• Promise.all fails fast — one rejection rejects all. Promise.allSettled waits for all to complete regardless of rejection. Choose based on your use case.

• Explain the event loop. What are microtasks vs macrotasks and why does the order matter?
• What is the output of this code? [setTimeout 0, Promise.resolve, console.log]
• When would you use Promise.all vs Promise.allSettled vs Promise.race?

0 == ""          // true (both coerce to 0)
0 == "0"         // true (string "0" coerces to number 0)
"" == "0"        // false (string comparison, different strings)
false == "0"     // true (false -> 0, "0" -> 0)
null == undefined // true (special rule in the spec)
null == 0        // false (null only coerces to undefined, not 0)
NaN == NaN       // false (NaN is not equal to anything, including itself)

• value == null — this checks for both null AND undefined in one expression. Some style guides (including some internal ones at large companies) allow this as the one exception.
• ESLint’s eqeqeq rule with "allow-null" option exists specifically for this pattern.

• Behaves like === but handles two edge cases differently: Object.is(NaN, NaN) returns true, and Object.is(+0, -0) returns false. React uses Object.is internally for state comparison in hooks.

• Can you explain the coercion steps that make [] == false evaluate to true?
• When is == actually appropriate to use?
• What is Object.is() and how does it differ from ===?

// Imperative (jQuery)
$('#counter').text(count);
if (count > 10) $('#counter').addClass('warning');

// Declarative (React)
<span className={count > 10 ? 'warning' : ''}>{count}</span>

• Class components -> Function components + Hooks (React 16.8+)
• Client-side only -> Server Components (React 18+)
• react-router for routing, Redux/Zustand/Jotai for state management
• Next.js, Remix, Gatsby as full-stack frameworks built on React

• What is the difference between a library and a framework, and why is React a library?
• How does React’s unidirectional data flow compare to two-way data binding in Angular?
• Why did React move from class components to hooks?

• Different element types produce different trees — React will tear down the old tree and build a new one (e.g., changing <div> to <span> does not try to patch)
• key props tell React which children in a list are the same across renders, enabling efficient reordering instead of re-creating

• Direct DOM manipulation is expensive — the DOM is a complex C++ object model. Reading element.offsetHeight can trigger a full layout recalculation (reflow).
• The virtual DOM lets React batch multiple state updates into a single DOM update pass (automatic batching since React 18).
• The diffing algorithm is O(n) — not the theoretical O(n^3) for tree diff — because of the two heuristics above.

• “Virtual DOM is faster than the real DOM” — No. The virtual DOM adds overhead (creating JS objects, diffing). It is faster than NAIVE DOM manipulation (re-rendering the entire page). A hand-optimized imperative approach (like what Svelte compiles to) can be faster because it skips the diffing step entirely.
• React 18’s concurrent features (Suspense, transitions) build on top of the virtual DOM — they allow React to pause, resume, and prioritize rendering work.

• Incremental rendering: React can split rendering work across multiple frames, preventing long renders from blocking the main thread
• Priority-based updates: User interactions (clicks) get higher priority than background updates (data fetching)
• Concurrent Mode: Multiple versions of the virtual DOM can exist simultaneously

• Why is the virtual DOM not always faster than direct DOM manipulation? When would a framework like Svelte be faster?
• What is React Fiber and how does it improve on the original reconciliation algorithm?
• How do key props affect reconciliation performance, and what happens when you use array index as keys?

• Data passed from parent to child components
• Read-only in the receiving component — a child should NEVER modify its own props
• Changing props triggers a re-render of the child component
• Think of props as function arguments — the parent calls <Child name="Alice" /> like calling Child({ name: "Alice" })
• Can pass any JavaScript value: strings, numbers, objects, arrays, functions, even other components (render props pattern)

• Data managed within a component via useState (function components) or this.setState (class components)
• Mutable — the component itself can update its state
• State updates trigger a re-render of that component AND all its children (unless optimized with React.memo, useMemo, etc.)
• State is asynchronous — setState does not update immediately. React batches state updates for performance.

Props = inputs from outside (read-only)
State = internal memory (read-write)

Parent owns the data -> passes down via props -> child renders based on props
Child needs internal data -> uses state -> updates trigger re-render
Child wants to communicate up -> calls a callback function received as a prop

• Derived state anti-pattern: Copying props into state (const [name, setName] = useState(props.name)) creates a stale copy that does not update when props change. Instead, derive values directly from props or use useMemo.
• Too much state: Not everything needs to be state. If you can calculate it from existing state/props, do not store it as separate state.
• Prop drilling: Passing props through many levels of components. Solutions: Context API, state management libraries (Zustand, Redux), or component composition.

• What is the derived state anti-pattern and how do you avoid it?
• How do you decide whether data should be state, a prop, or derived from existing data?
• What is prop drilling, and what are the trade-offs between Context API and state management libraries for solving it?

• React state is the single source of truth for the input value
• Every keystroke triggers onChange -> updates state -> React re-renders the input with the new value

const [email, setEmail] = useState('');
<input value={email} onChange={(e) => setEmail(e.target.value)} />

• Advantages: Full control over the value at all times. Can validate, transform, or reject input on every keystroke (e.g., formatting a phone number, preventing non-numeric characters). Can disable submit buttons based on validation state. Easier to test because the value is always in React state.
• Trade-off: More code. Every input needs state and an onChange handler. For large forms with 20+ fields, this is boilerplate-heavy without a form library.

• The DOM itself is the source of truth. You access the value when you need it (typically on submit) via a ref.

const emailRef = useRef();
<input ref={emailRef} defaultValue="" />
// On submit: emailRef.current.value

• Advantages: Less code, simpler for basic forms. Better performance for large forms (no re-render on every keystroke). Easier integration with non-React code.
• Trade-off: Cannot easily validate on every keystroke, cannot conditionally enable/disable UI based on current input values, harder to test.

• value makes it controlled (React owns it)
• defaultValue makes it uncontrolled (sets initial DOM value, React does not track changes)
• Setting value without an onChange handler creates a read-only input that React warns about

• React Hook Form uses uncontrolled components internally (refs + register) for performance, but provides a controlled API. This is why it is faster than Formik for large forms — fewer re-renders.
• Formik uses controlled components by default, which can cause performance issues in forms with many fields (every keystroke re-renders the entire form unless optimized with <FastField>).

• When would you choose an uncontrolled component over a controlled one?
• How does React Hook Form achieve better performance than Formik, architecturally?
• What happens if you set value on an input without an onChange handler?

• When React diffs a list of children, it compares elements by their key. Same key = same element (possibly updated). Missing key = removed. New key = added.
• With keys, React can reorder DOM elements instead of destroying and recreating them. This preserves component state, focus, scroll position, and animation state.

// BAD: Using index as key
items.map((item, index) => <Item key={index} {...item} />)

• Without proper keys (using index): React thinks every item changed (item at index 0 is different, index 1 is different…). It re-renders ALL items.
• With unique keys: React knows the old items just shifted position. It inserts one new DOM node and moves the rest.

• The list is static (never reordered, filtered, or items added/removed)
• Items have no internal state (no inputs, checkboxes, animations)
• The list is used purely for display

• Database IDs (ideal: key={user.id})
• Unique business identifiers (email, SKU)
• crypto.randomUUID() generated at data creation time (not at render time — generating in render creates new keys every render, defeating the purpose)
• Never generate keys during render: key={Math.random()} re-creates every element on every render

• Show me a scenario where using array index as a key causes a bug with component state.
• What happens to component state when a key changes?
• Why should you never use Math.random() or Date.now() as a key in render?

// 1. Runs after EVERY render (no dependency array)
useEffect(() => { /* runs every time */ });

// 2. Runs only ONCE after mount (empty array)
useEffect(() => { /* runs on mount */ }, []);

// 3. Runs when specific dependencies change
useEffect(() => { /* runs when userId changes */ }, [userId]);

useEffect(() => {
  const subscription = dataSource.subscribe(handleChange);
  return () => {
    subscription.unsubscribe(); // Cleanup runs before next effect or unmount
  };
}, [dataSource]);

• Before the effect re-runs (when dependencies change)
• When the component unmounts Common use: clearing intervals, unsubscribing from WebSockets, canceling fetch requests via AbortController.

// BUG: runs on every render because effect updates state, which triggers re-render
useEffect(() => {
  setData(transformData(rawData));
}); // Missing dependency array!

// Also a bug: object/array in deps
useEffect(() => { ... }, [{ id: 1 }]); // New object ref every render = infinite loop

// BAD — unnecessary effect
useEffect(() => {
  setFullName(firstName + ' ' + lastName);
}, [firstName, lastName]);

// GOOD — calculate during render
const fullName = firstName + ' ' + lastName;

useEffect(() => {
  let cancelled = false;
  fetch(`/api/user/${id}`).then(res => res.json()).then(data => {
    if (!cancelled) setUser(data); // Only update if not stale
  });
  return () => { cancelled = true; };
}, [id]);

• When should you NOT use useEffect? Give examples of things developers put in effects that should be elsewhere.
• How do you handle race conditions in useEffect when fetching data?
• What is the difference between useEffect and useLayoutEffect?

const expensiveResult = useMemo(() => {
  return data.filter(item => item.active).sort((a, b) => a.name.localeCompare(b.name));
}, [data]);

• Returns the result of the function
• Only recomputes when dependencies change
• Use case: expensive calculations (sorting/filtering large arrays), creating objects/arrays passed to child components (prevents unnecessary re-renders via reference equality)

const handleClick = useCallback((id) => {
  setItems(items => items.filter(item => item.id !== id));
}, []);

• Returns the function itself (not its return value)
• The function reference stays the same between renders unless dependencies change
• useCallback(fn, deps) is equivalent to useMemo(() => fn, deps)

• Passing callbacks to child components wrapped in React.memo — without useCallback, the new function reference breaks memoization
• Passing objects/arrays as props — useMemo prevents creating new references that cause re-renders
• Dependencies of other hooks — if a value is in useEffect’s dependency array, memoize it to avoid unnecessary effect runs
• Genuinely expensive computations (not just simple calculations)

• Simple calculations (adding two numbers, string concatenation)
• Functions not passed to memoized children
• Inline event handlers on DOM elements (not custom components)
• The overhead of useMemo/useCallback itself (comparing dependencies) can be MORE than just recomputing a simple value

// This is WORSE than not memoizing:
const name = useMemo(() => firstName + ' ' + lastName, [firstName, lastName]);
// The dependency comparison is more expensive than the string concatenation

• When does memoization actually hurt performance instead of helping?
• How does React.memo work with useCallback to prevent child re-renders?
• What is the React Compiler and how might it change the way we use these hooks?

const [form, setForm] = useState({ email: '', password: '' });
const handleChange = (e) => {
  setForm(prev => ({ ...prev, [e.target.name]: e.target.value }));
};

const { register, handleSubmit, formState: { errors } } = useForm();
<input {...register("email", { required: true, pattern: /^\S+@\S+$/i })} />

• Uses uncontrolled components internally (refs, not state)
• Minimal re-renders — only the changed field re-renders, not the entire form
• Built-in validation with declarative rules
• Integrates with Zod/Yup for schema validation
• ~8KB gzipped
• Best for: Most production forms. 10+ fields, complex validation, dynamic fields.

• Uses controlled components by default
• More re-renders than React Hook Form (every keystroke re-renders the form)
• <FastField> component for optimizing specific fields
• Larger bundle, more boilerplate
• When you see it: Legacy projects, projects started before React Hook Form matured

• Client-side: Zod + React Hook Form resolver for type-safe validation. Define the schema once, get TypeScript types AND validation rules.
• On-blur vs on-change vs on-submit: On-change is aggressive (errors while typing feel annoying). On-blur is standard (validate when user leaves the field). On-submit is simplest but least helpful.
• Server-side validation is mandatory — client-side validation is for UX, server-side is for security. Never trust the client.

• Every input needs a <label> with matching htmlFor/id
• Error messages should be linked via aria-describedby
• Use aria-invalid="true" on invalid fields
• Focus management: move focus to the first error on submit failure

• Why does React Hook Form perform better than Formik for large forms?
• How would you implement a multi-step wizard form with validation per step?
• How do you handle async validation (e.g., checking if a username is taken)?

// 1. Create context with a default value
const ThemeContext = createContext('light');

// 2. Provide the value at a higher level
<ThemeContext.Provider value={theme}>
  <App />
</ThemeContext.Provider>

// 3. Consume it anywhere below
const theme = useContext(ThemeContext);

• Truly global, infrequently-changing data: theme, locale/language, authenticated user, feature flags
• Dependency injection: providing services/configurations to deeply nested components
• Compound components: <Select> providing shared state to <Option> children

// BAD: Every consumer re-renders when ANY property changes
<AppContext.Provider value={{ user, theme, locale, notifications }}>

// BETTER: Split into separate contexts
<UserContext.Provider value={user}>
  <ThemeContext.Provider value={theme}>

• Split contexts by update frequency (user data changes rarely, notifications change often)
• Memoize the context value: const value = useMemo(() => ({ user, logout }), [user])
• Use React.memo on intermediate components to prevent cascading re-renders

• Zustand — minimal, performant, no boilerplate. Selectors prevent unnecessary re-renders.
• Redux Toolkit — best for large apps with complex state logic, time-travel debugging, middleware
• Jotai/Recoil — atomic state management, fine-grained reactivity

• How does a Context value change cause re-renders, and how do you optimize this?
• When would you use Context vs Zustand vs Redux?
• How would you structure contexts in a large application to minimize unnecessary re-renders?

// React 18: ONE re-render, not three
function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  setName('Alice');
}

• Why is React’s diffing O(n) instead of O(n^3), and what assumptions make that possible?
• How does automatic batching in React 18 change rendering behavior compared to React 17?
• What happens during reconciliation when you conditionally render different component types at the same position?

• SEO: Client-rendered React apps (Create React App) send an empty HTML shell to the browser — search engine crawlers see nothing. Next.js can server-render or statically generate full HTML.
• Performance: First Contentful Paint (FCP) is faster with SSR/SSG because the browser receives rendered HTML immediately, rather than waiting for JS to download, parse, and execute.
• Routing: React has no built-in router. Next.js provides file-system based routing with zero configuration.
• Full-stack capability: API routes let you build backend endpoints in the same project, eliminating the need for a separate Express/Fastify server for simple APIs.

• Pages Router (legacy but stable): pages/ directory, getServerSideProps, getStaticProps, getStaticPaths. Each file = a route.
• App Router (Next.js 13+, current standard): app/ directory, React Server Components by default, layout.tsx, loading.tsx, error.tsx conventions, streaming, server actions. Fundamentally different mental model.

• next/image — automatic image optimization (WebP conversion, lazy loading, responsive sizing, CDN-based resizing)
• Middleware — runs before a request is processed. Use for auth checks, redirects, A/B testing, geolocation
• ISR (Incremental Static Regeneration) — static pages that revalidate in the background at specified intervals, combining SSG performance with data freshness
• Server Actions — mutate data from the server directly in components, no API routes needed
• Edge Runtime — deploy functions to edge locations (Cloudflare Workers-style) for low-latency responses

• What are the key differences between the App Router and Pages Router?
• When would you choose ISR over SSR, and what are the trade-offs?
• How does Next.js middleware work, and what are practical use cases?

• Browser downloads a minimal HTML shell + JavaScript bundle
• JavaScript renders the UI on the client
• Pros: Simple deployment (static files), rich interactivity, no server cost
• Cons: Poor SEO (empty HTML), slow First Contentful Paint (FCP), loading spinners
• Use when: Dashboards, admin panels, authenticated apps where SEO does not matter
• Example: Create React App, Vite + React

• Server renders full HTML on every request, sends it to the browser
• Browser displays HTML immediately (fast FCP), then “hydrates” with JavaScript for interactivity
• Pros: Great SEO, fast FCP, always fresh data
• Cons: Server cost (every request = render work), slower Time to First Byte (TTFB) for expensive pages, server scaling complexity
• Use when: Personalized content (user profiles), frequently changing data, SEO-critical pages with dynamic content
• Next.js (App Router): Server Components are SSR by default. In Pages Router: getServerSideProps

• Pages rendered at build time, served as static HTML files from a CDN
• Pros: Fastest possible performance (CDN-served, no server computation), highly cacheable, nearly free to host
• Cons: Data is stale until next build, build times grow with page count (100K pages = long builds), no personalization
• Use when: Blog posts, documentation, marketing pages, product listings that change infrequently
• Next.js: generateStaticParams (App Router) or getStaticPaths + getStaticProps (Pages Router)

• Combines SSG and SSR: pages are statically generated but revalidate in the background after a configured time interval
• User 1 gets the cached static page. After the revalidation period, the next request triggers a background regeneration. User 2 gets the fresh page.
• Pros: SSG-level performance with near-real-time data freshness, no full rebuild needed
• Cons: Data can be stale within the revalidation window, more complex mental model, cache invalidation can be tricky
• Use when: E-commerce product pages (prices change daily, not per-second), news articles, any content that is “mostly static” with periodic updates
• Next.js: revalidate: 60 in fetch options or page config

Does it need SEO? No -> CSR
Yes -> Does data change per request? Yes -> SSR
No -> Does data change at all? No -> SSG
Yes -> ISR (with appropriate revalidation interval)

• A client wants an e-commerce site with 50,000 product pages. Which rendering strategy do you choose and why?
• What is the difference between on-demand revalidation and time-based revalidation in ISR?
• How does streaming SSR (React 18) change the traditional SSR trade-offs?

• pages/users/[id].js matches /users/1, /users/abc, etc.
• Access the parameter: const { id } = useRouter().query (client) or from getServerSideProps({ params })
• Catch-all routes: pages/docs/[...slug].js matches /docs/a, /docs/a/b/c (any depth)
• Optional catch-all: pages/docs/[[...slug]].js also matches /docs (the base path)

• app/users/[id]/page.tsx matches /users/1
• Access parameter: function Page({ params }: { params: { id: string } })
• Catch-all: app/docs/[...slug]/page.tsx
• Route groups: app/(marketing)/about/page.tsx — the (marketing) folder creates a layout group without affecting the URL
• Parallel routes: app/@dashboard/page.tsx — render multiple pages in the same layout simultaneously
• Intercepting routes: app/(.)photo/[id]/page.tsx — intercept a route for modal behavior (like Instagram’s photo modal)

// App Router
export async function generateStaticParams() {
  const users = await getUsers();
  return users.map(user => ({ id: user.id.toString() }));
}

// Pages Router
export async function getStaticPaths() {
  const users = await getUsers();
  return {
    paths: users.map(u => ({ params: { id: u.id.toString() } })),
    fallback: 'blocking', // or true, or false
  };
}

• false: Only pre-generated paths work, 404 for everything else
• true: Non-generated paths show a loading state, then render on first visit and cache
• 'blocking': Non-generated paths SSR on first visit (no loading state), then cache. Best for SEO.

• What is the difference between fallback: true and fallback: 'blocking' and when would you use each?
• How do parallel routes and intercepting routes work in the App Router?
• How would you implement a nested dynamic route like /blog/[category]/[slug]?

• Use next/image exclusively — it handles WebP/AVIF conversion, responsive srcset, lazy loading, and blur placeholder
• Set explicit width and height (or use fill) to prevent Cumulative Layout Shift (CLS)
• Configure remotePatterns in next.config.js for external image domains
• Use priority prop on above-the-fold images (hero images) to disable lazy loading

• Default to SSG/ISR for content pages — served from CDN edge, fastest possible
• Use SSR only when per-request personalization is needed
• Stream long-running server components with <Suspense> boundaries
• Use loading.tsx for route-level loading states

• Next.js automatically code-splits by route
• Use dynamic() (equivalent to React.lazy) for heavy components: const Chart = dynamic(() => import('./Chart'), { ssr: false })
• ssr: false is key for client-only libraries (D3, maps, rich text editors) — avoids server-side import errors
• Analyze bundle with @next/bundle-analyzer — identify unexpected large dependencies. A common find: importing all of lodash instead of lodash/debounce

• Use React Server Components to fetch data on the server (zero client-side JavaScript for data fetching)
• Colocate data fetching with components — avoid waterfall requests by fetching in parallel
• Use fetch with next: { revalidate: N } for ISR caching
• Implement next: { tags: ['products'] } + revalidateTag('products') for on-demand cache invalidation

• Use next/font to self-host Google Fonts (eliminates external network request)
• display: 'swap' prevents invisible text during font loading
• Reduces CLS from font loading

• Use next/script with strategy="lazyOnload" for analytics, chat widgets, etc.
• strategy="afterInteractive" for scripts needed soon but not blocking render
• Avoid loading heavy third-party scripts synchronously

• Largest Contentful Paint (LCP) < 2.5s
• First Input Delay (FID) < 100ms
• Cumulative Layout Shift (CLS) < 0.1
• Time to First Byte (TTFB) < 800ms

• How would you diagnose a slow LCP on a Next.js page?
• What is the difference between dynamic() with ssr: false and a regular React.lazy?
• How does React Server Components change the performance optimization landscape compared to client-side React?

• Variables without the prefix (e.g., DATABASE_URL) are only available on the server (Server Components, API routes, getServerSideProps). They are never included in the client bundle.
• Variables with NEXT_PUBLIC_ prefix (e.g., NEXT_PUBLIC_API_URL) are inlined into the client JavaScript bundle at build time. They are visible to anyone who inspects your JavaScript.
• Critical security implication: Never put secrets (API keys, database credentials, JWT secrets) in NEXT_PUBLIC_ variables. They will be exposed in client-side code.

1. .env — default for all environments
2. .env.local — local overrides (gitignored by default)
3. .env.development / .env.production / .env.test — environment-specific
4. .env.development.local / .env.production.local — environment-specific local overrides

• Priority: .env.*.local > .env.local > .env.* > .env
• process.env.NODE_ENV is automatically set (development, production, test)

• Putting DATABASE_URL as NEXT_PUBLIC_DATABASE_URL — now your database credentials are in the browser bundle
• Not restarting the dev server after adding new env vars — Next.js reads them at startup
• Using process.env.SOME_VAR in client components without NEXT_PUBLIC_ — it will be undefined on the client (no error, just silently missing)

• NEXT_PUBLIC_ variables are replaced at build time (string replacement in the bundle). If you deploy the same build to staging and production, the values from the build-time environment are baked in.
• Server-side variables are read at runtime via process.env
• For runtime client-side config, use Next.js runtime configuration or fetch from an API endpoint

• Store secrets in your deployment platform (Vercel Environment Variables, AWS Secrets Manager, Doppler)
• Use .env.local for local development only
• Validate env vars at startup using a schema (Zod + t3-env library is the gold standard)
• Never commit .env.local to git (it should be in .gitignore)

• What happens if you access a non-NEXT_PUBLIC variable in a client component?
• How would you validate that all required environment variables are present at build/startup time?
• What is the difference between build-time and runtime environment variables, and when does this distinction matter?

• JavaScript: user.naem silently returns undefined. You discover this from a bug report in production.
• TypeScript: user.naem shows a red squiggly immediately. The typo never reaches git.
• Studies (Airbnb, Bloomberg) show TypeScript prevents 15-20% of bugs that would otherwise reach production.

// Without TS: What does this function accept? What does it return? Read the implementation.
function processOrder(order, options) { ... }

// With TS: The signature IS the documentation
function processOrder(order: Order, options: ProcessOptions): Promise<Receipt> { ... }

• Learning curve — generics, utility types, and type narrowing take time to master
• Build step required — cannot just run .ts files in the browser (though tools like Bun and Deno can execute TS directly)
• Occasional type gymnastics — complex types (conditional types, mapped types) can be harder to read than the code they protect
• Third-party type quality varies — @types/ packages can be outdated or incorrect

• Does TypeScript have any runtime overhead? Why or why not?
• What is the strict mode in tsconfig and what does it enable?
• When might TypeScript not be the right choice for a project?

interface User {
  id: number;
  name: string;
  email: string;
}

// Declaration merging — interfaces with the same name merge
interface User {
  role: string; // Added to the original User interface
}

// Extends (inheritance)
interface Admin extends User {
  permissions: string[];
}

type User = {
  id: number;
  name: string;
  email: string;
};

// Union types (interface CANNOT do this)
type Status = 'active' | 'inactive' | 'pending';
type Result = Success | Error;

// Intersection (similar to extends)
type Admin = User & { permissions: string[] };

// Mapped types, conditional types, template literals
type Readonly<T> = { readonly [P in keyof T]: T[P] };

• interface for object shapes and public APIs: Declaration merging is useful for library authors (consumers can extend your interfaces). Extends keyword reads more naturally for OOP-style hierarchies.
• type for everything else: Unions, intersections, utility types, complex type transformations, primitives, tuples.
• Team convention matters most. Many teams standardize on one. The React community tends toward type for props; library authors tend toward interface for extensibility.

• What is declaration merging and when is it useful?
• Can you create a union type with interfaces? Why or why not?
• When would you prefer type over interface for React component props?

// Without generics: loses type information
function first(arr: any[]): any {
  return arr[0];
}
const result = first([1, 2, 3]); // result is 'any' — no autocomplete, no safety

// With generics: preserves type information
function first<T>(arr: T[]): T {
  return arr[0];
}
const result = first([1, 2, 3]); // result is 'number' — full type safety

function merge<T, U>(obj1: T, obj2: U): T & U {
  return { ...obj1, ...obj2 };
}

// T must have a 'length' property
function longest<T extends { length: number }>(a: T, b: T): T {
  return a.length >= b.length ? a : b;
}
longest("hello", "hi"); // Works: strings have length
longest(10, 20);        // Error: numbers have no length

interface ListProps<T> {
  items: T[];
  renderItem: (item: T) => React.ReactNode;
}

function List<T>({ items, renderItem }: ListProps<T>) {
  return <>{items.map(renderItem)}</>;
}

// Usage: T is inferred as User
<List items={users} renderItem={(user) => <span>{user.name}</span>} />

interface ApiResponse<T = unknown> {
  data: T;
  status: number;
  message: string;
}

function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}
getProperty(user, 'name'); // Returns string
getProperty(user, 'foo');  // Compile error: 'foo' is not a key of User

• API hooks: useQuery<User>('/api/user') returns typed data
• Form libraries: useForm<FormValues>() gives type-safe field access
• Table components: <DataTable<Product> columns={...} data={products} />
• State management: Zustand stores use generics for typed state

• How do generic constraints work, and when would you use extends in a generic?
• Write a generic type that makes all properties of an object optional except for id.
• How would you type a generic API hook that fetches data and returns typed results?

interface User { id: number; name: string; email: string; }
type UpdateUser = Partial<User>;
// { id?: number; name?: string; email?: string; }
// Use case: PATCH endpoints where you only send changed fields

type UserPreview = Pick<User, 'id' | 'name'>;
// { id: number; name: string; }
// Use case: List views that only need a subset of fields

type CreateUser = Omit<User, 'id'>;
// { name: string; email: string; }
// Use case: Create forms where id is auto-generated

type ImmutableUser = Readonly<User>;
// Attempting to reassign any property = compile error
// Use case: Redux state, config objects

type UserRoles = Record<string, 'admin' | 'user' | 'guest'>;
// Use case: Lookup maps, dictionaries

type Status = 'active' | 'inactive' | 'pending' | 'deleted';
type ActiveStatus = Exclude<Status, 'deleted'>;
// 'active' | 'inactive' | 'pending'

function getUser() { return { id: 1, name: 'Alice' }; }
type User = ReturnType<typeof getUser>;
// { id: number; name: string; }
// Use case: Inferring types from existing functions without manual duplication

// Create form type: all fields optional except id (which is omitted entirely)
type UserForm = Partial<Omit<User, 'id'>>;

// Make only certain fields required
type UserWithRequiredEmail = Omit<Partial<User>, 'email'> & Pick<User, 'email'>;

• How would you create a type where all properties are optional EXCEPT id and email?
• What is the difference between Omit and Exclude?
• How does ReturnType work under the hood (hint: conditional types and infer)?

interface ButtonProps {
  variant: 'primary' | 'secondary' | 'danger';
  size?: 'sm' | 'md' | 'lg';
  onClick: (event: React.MouseEvent<HTMLButtonElement>) => void;
  children: React.ReactNode;
  disabled?: boolean;
}

function Button({ variant, size = 'md', onClick, children, disabled }: ButtonProps) {
  return <button className={`btn-${variant} btn-${size}`} onClick={onClick} disabled={disabled}>{children}</button>;
}

// Compile error: 'warning' is not assignable to type 'primary' | 'secondary' | 'danger'
<Button variant="warning" onClick={() => {}}>Click</Button>

// useState infers type, or you can be explicit
const [user, setUser] = useState<User | null>(null);

// useRef with proper typing
const inputRef = useRef<HTMLInputElement>(null);

// useReducer with discriminated union actions
type Action =
  | { type: 'INCREMENT'; payload: number }
  | { type: 'RESET' };

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case 'INCREMENT': return { count: state.count + action.payload };
    case 'RESET': return { count: 0 };
  }
}

interface ApiResponse<T> {
  data: T;
  error: string | null;
}

async function fetchUser(id: string): Promise<ApiResponse<User>> {
  const res = await fetch(`/api/users/${id}`);
  return res.json();
}
// Autocomplete works on the returned data: response.data.name

const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  setValue(e.target.value);
};

const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
  e.preventDefault();
};

interface SelectProps<T> {
  options: T[];
  getLabel: (item: T) => string;
  getValue: (item: T) => string;
  onChange: (item: T) => void;
}

function Select<T>({ options, getLabel, getValue, onChange }: SelectProps<T>) { ... }

• React.FC vs function declaration — React.FC implicitly includes children (pre-React 18) and does not support generics well. Most teams now prefer explicit function declarations with typed props.
• ComponentPropsWithoutRef<'button'> — extend native HTML element props
• as const for literal types — const sizes = ['sm', 'md', 'lg'] as const creates a readonly tuple type

• How would you type a component that accepts all native button props plus custom ones?
• What is the difference between React.FC<Props> and a regular function with typed props?
• How do you handle typing for a component that can render as different HTML elements (polymorphic components)?

• Bundle analysis: Use webpack-bundle-analyzer or @next/bundle-analyzer to visualize your bundle. Common finds: shipping all of moment.js (330KB) when you need date-fns (tree-shakeable), or importing entire lodash (70KB) instead of lodash/debounce (1KB).
• Tree shaking: Use ES modules (import/export) not CommonJS (require). Modern bundlers (Webpack 5, Vite, Turbopack) eliminate unused exports.
• Code splitting: Split by route (automatic in Next.js), split heavy components with React.lazy() / dynamic().
• Dependency audit: npm ls --all | wc -l — if you have 1500+ dependencies, some are likely unused.

• Minimize re-renders: React.memo for pure components, useMemo/useCallback where profiling shows impact, avoid passing new object/array literals as props.
• Virtualize long lists: react-window or @tanstack/virtual for lists with 100+ items. Rendering 10,000 DOM nodes kills scrolling performance.
• Avoid layout thrashing: Batch DOM reads and writes. Do not interleave element.offsetHeight reads with style changes.
• Use CSS containment: contain: layout paint on independent sections.

• Images: WebP/AVIF format, responsive srcset, lazy loading, proper sizing (do not serve a 4000px image in a 400px container). next/image handles this automatically.
• Fonts: Self-host (next/font), use font-display: swap, subset to only needed characters.
• Videos: Lazy load, use poster images, prefer streaming formats.

• Caching: Set proper Cache-Control headers. Immutable assets (hashed filenames) get max-age=31536000. HTML gets no-cache or short TTL.
• CDN: Serve static assets from edge locations (Vercel, Cloudflare, CloudFront).
• Preconnect/Prefetch: <link rel="preconnect" href="https://api.example.com"> for known third-party origins.
• HTTP/2 or HTTP/3: Multiplexing eliminates the need for domain sharding or sprite sheets.

• Chrome DevTools Performance tab for runtime profiling
• Lighthouse for overall audit
• Web Vitals library for real-user monitoring (RUM)
• React DevTools Profiler for component-level render analysis

• Walk me through how you would diagnose and fix a slow page from scratch.
• What is the difference between lab data (Lighthouse) and field data (CrUX), and why does it matter?
• How would you set up performance budgets in a CI/CD pipeline?

const HeavyChart = React.lazy(() => import('./HeavyChart'));

function Dashboard() {
  return (
    <Suspense fallback={<div>Loading chart...</div>}>
      <HeavyChart />
    </Suspense>
  );
}

• import() creates a separate webpack chunk that loads on demand
• Suspense provides a fallback UI while the chunk loads
• The component’s JavaScript only downloads when <HeavyChart> first renders

const Map = dynamic(() => import('./Map'), {
  loading: () => <MapSkeleton />,
  ssr: false, // Critical for client-only libraries like Mapbox, D3
});

• ssr: false prevents the component from rendering on the server (avoids window is not defined errors)
• Built-in loading component option

• Next.js automatically code-splits per route — each page is its own chunk
• React Router: lazy(() => import('./routes/Dashboard')) in route definitions
• Users only download JavaScript for the routes they visit

function LazySection({ children }) {
  const [isVisible, ref] = useInView({ triggerOnce: true });
  return <div ref={ref}>{isVisible ? children : <Placeholder />}</div>;
}

• Native: <img loading="lazy" /> (supported in all modern browsers)
• next/image does this by default (except when priority is set)

• Waterfall loading: If lazy-loaded component A loads and then triggers loading of component B, you get a sequential waterfall. Preload critical lazy chunks: import(/* webpackPreload: true */ './HeavyChart')
• Loading state flicker: If the chunk loads in <200ms, showing a spinner creates an unpleasant flash. Use a minimum delay or skeleton screens.
• Error boundaries: What happens if the chunk fails to load (network error)? Wrap lazy components in error boundaries to show a retry UI.

• When would lazy loading actually hurt performance instead of helping?
• How do you handle errors when a lazy-loaded chunk fails to download?
• What is the difference between React.lazy and Next.js dynamic?

function debounce(fn, delay) {
  let timeoutId;
  return function(...args) {
    clearTimeout(timeoutId);
    timeoutId = setTimeout(() => fn.apply(this, args), delay);
  };
}

// Use case: search-as-you-type
const handleSearch = debounce((query) => {
  fetch(`/api/search?q=${query}`); // Only fires after 300ms of no typing
}, 300);

function throttle(fn, interval) {
  let lastTime = 0;
  return function(...args) {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      fn.apply(this, args);
    }
  };
}

// Use case: scroll position tracking
const handleScroll = throttle(() => {
  updateScrollIndicator(window.scrollY);
}, 100); // Updates at most every 100ms

• Debounce groups multiple calls into ONE call at the END of the burst
• Throttle allows ONE call per time interval DURING the burst

// Using lodash/debounce with useCallback to maintain reference stability
const debouncedSearch = useCallback(
  debounce((query) => fetchResults(query), 300),
  []
);
// Or use the useDebouncedCallback hook from 'use-debounce' library

• You need to implement auto-save that saves 2 seconds after the user stops typing, but also saves every 30 seconds while they are continuously typing. How would you combine debounce and throttle?
• How would you implement debouncing in a React component without causing stale closure issues?
• What is requestAnimationFrame throttling and when is it better than time-based throttling?

// Webpack config
optimization: {
  splitChunks: {
    cacheGroups: {
      vendor: { test: /node_modules/, name: 'vendors', chunks: 'all' }
    }
  }
}

// Only load PDF library when user clicks "Export PDF"
async function exportPDF() {
  const { jsPDF } = await import('jspdf');
  const doc = new jsPDF();
  // ...
}

• webpack-bundle-analyzer — visual treemap of your bundle
• source-map-explorer — analyze bundle composition from source maps
• @next/bundle-analyzer — Next.js-specific wrapper
• Chrome DevTools Coverage tab — shows what percentage of downloaded JS is actually executed on the current page

• How does bundle splitting interact with HTTP caching strategies?
• What is the overhead of having too many small chunks (hint: HTTP/1.1 vs HTTP/2)?
• How would you analyze your bundle to find the best splitting opportunities?

• WebP: 25-35% smaller than JPEG at equivalent quality. Supported by 97%+ of browsers.
• AVIF: 50% smaller than JPEG, better than WebP. Supported by 90%+ of browsers. Slower to encode.
• Use <picture> for progressive enhancement:

<picture>
  <source srcset="image.avif" type="image/avif" />
  <source srcset="image.webp" type="image/webp" />
  <img src="image.jpg" alt="Description" />
</picture>

• SVG for icons, logos, illustrations — infinitely scalable, tiny file size for simple graphics

<img
  srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
  src="image-800.jpg"
  alt="Product photo"
/>

• Native: loading="lazy" attribute (supported in all modern browsers)
• Only loads images when they are near the viewport
• Never lazy load above-the-fold images — these should load immediately (use loading="eager" or Next.js priority prop)

• ALWAYS set width and height attributes (or use CSS aspect-ratio)
• Without dimensions, the browser does not know the image size until it loads, causing Cumulative Layout Shift (CLS) — content jumps around as images pop in

import Image from 'next/image';
<Image src="/hero.jpg" width={1200} height={630} alt="Hero" priority />

• Automatic format conversion (WebP/AVIF)
• Automatic responsive sizing
• Built-in lazy loading
• Blur placeholder option (placeholder="blur")
• On-demand image optimization API (resizes at the edge, not at build time)

• Serve images from a CDN (Cloudflare Images, Cloudinary, Imgix, Vercel Image Optimization)
• These services resize, format-convert, and cache images at edge locations
• Cloudinary example: https://res.cloudinary.com/demo/image/upload/w_400,f_auto,q_auto/sample.jpg — auto-format, auto-quality, 400px wide

• What is Cumulative Layout Shift and how do images cause it?
• How would you handle image optimization for user-uploaded content at scale?
• When would you choose a CDN-based image service over Next.js built-in image optimization?

• Legal requirement: ADA (US), EAA (EU), AODA (Canada). Web accessibility lawsuits increased 300%+ between 2018-2023. Target, Dominos, and Winn-Dixie all faced major lawsuits.
• Business impact: Accessible sites reach more users. The disability community controls ~$8 trillion in annual disposable income globally.
• SEO benefit: Accessible sites rank better — semantic HTML, alt text, and proper heading hierarchy are both accessibility AND SEO best practices.

• Level A: Minimum accessibility (alt text, keyboard navigation, no seizure-inducing content)
• Level AA: Standard target for most organizations (color contrast 4.5:1, resize to 200%, focus visible)
• Level AAA: Enhanced (contrast 7:1, sign language for video). Rarely required as a blanket target.

• Perceivable: Information must be presentable in ways all users can perceive (alt text, captions, sufficient contrast)
• Operable: UI must be operable by all (keyboard navigation, no time limits, no seizure triggers)
• Understandable: Content and UI must be understandable (clear language, predictable navigation, error identification)
• Robust: Content must be robust enough for assistive technologies to interpret (valid HTML, ARIA attributes)

• Semantic HTML (<nav>, <main>, <button> not <div onClick>)
• All images have descriptive alt text (or alt="" for decorative images)
• Color contrast ratio minimum 4.5:1 for normal text, 3:1 for large text
• Full keyboard navigation (Tab, Shift+Tab, Enter, Escape, arrow keys)
• Visible focus indicators (never outline: none without a replacement)
• ARIA labels for interactive elements without visible text (aria-label, aria-labelledby)
• Skip navigation link for keyboard users
• Form inputs with associated <label> elements
• Error messages that are programmatically associated with inputs (aria-describedby)

• Walk me through how a screen reader user would navigate a page you have built.
• What is the difference between aria-label, aria-labelledby, and aria-describedby?
• How do you test for accessibility during development, not just at the end?

“The more your tests resemble the way your software is used, the more confidence they can give you.” — Kent C. Dodds

• Jest or Vitest — test runner and assertion library
• React Testing Library (RTL) — renders components and provides user-centric queries
• MSW (Mock Service Worker) — mocks API calls at the network level
• Playwright or Cypress — E2E testing in real browsers

import { render, screen, fireEvent } from '@testing-library/react';

test('increments counter on click', () => {
  render(<Counter />);
  const button = screen.getByRole('button', { name: /increment/i });
  fireEvent.click(button);
  expect(screen.getByText('Count: 1')).toBeInTheDocument();
});

1. getByRole — queries by ARIA role (most accessible, most robust)
2. getByLabelText — for form inputs
3. getByPlaceholderText — fallback for inputs
4. getByText — for non-interactive content
5. getByTestId — last resort (test-specific, not user-facing)

• Test: User interactions, rendered output, conditional rendering, error states, form validation, accessibility (role queries prove accessibility)
• Do not test: Implementation details (state variable names, hook call counts, internal methods), CSS styling, third-party library internals

import { rest } from 'msw';
import { setupServer } from 'msw/node';

const server = setupServer(
  rest.get('/api/users', (req, res, ctx) => {
    return res(ctx.json([{ id: 1, name: 'Alice' }]));
  })
);

test('displays users from API', async () => {
  render(<UserList />);
  expect(await screen.findByText('Alice')).toBeInTheDocument();
});

test('user can log in and see dashboard', async ({ page }) => {
  await page.goto('/login');
  await page.fill('[name=email]', 'user@test.com');
  await page.fill('[name=password]', 'password');
  await page.click('button[type=submit]');
  await expect(page.locator('h1')).toContainText('Dashboard');
});

• Why does React Testing Library discourage testing implementation details?
• How does MSW differ from mocking fetch or axios directly?
• What is your strategy for deciding what to unit test vs integration test vs E2E test?

test('renders correctly', () => {
  const { container } = render(<Button variant="primary">Click me</Button>);
  expect(container).toMatchSnapshot();
});

• First run: creates a .snap file with the serialized DOM output
• Subsequent runs: compares current output against the stored snapshot
• If they differ: test fails. You review the diff and either update the snapshot (intentional change) or fix the bug (unintentional change).

• Inline snapshots (toMatchInlineSnapshot) for small, focused outputs — the snapshot lives in the test file, easier to review
• API response shapes — verify the structure of serialized data
• Configuration objects — catch unintended changes to complex configs
• As a change detection tool during refactoring — temporarily add snapshots, refactor, verify nothing changed, then remove them

• Targeted assertions: expect(screen.getByRole('heading')).toHaveTextContent('Welcome')
• Visual regression testing: Percy, Chromatic, or Playwright visual comparisons (pixel-level comparison of screenshots)

• What happens when a team routinely runs --updateSnapshot without reviewing changes?
• When would you use visual regression testing instead of snapshot testing?
• How do inline snapshots improve on file-based snapshots?

<!-- Explicit association (preferred) -->
<label htmlFor="email">Email Address</label>
<input id="email" type="email" name="email" />

<!-- Implicit association (wrapping) -->
<label>
  Email Address
  <input type="email" name="email" />
</label>

• Every <input>, <select>, and <textarea> MUST have an associated label
• Placeholder text is NOT a substitute for labels — it disappears on input and has low contrast
• aria-label for visually hidden labels (search inputs with icon-only UI)

<label htmlFor="email">Email Address</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
/>
<span id="email-error" role="alert">Please enter a valid email address</span>

• aria-invalid="true" signals to screen readers that the field has an error
• aria-describedby links the error message to the input — screen readers announce it when the input is focused
• role="alert" makes the error announced immediately when it appears (live region)
• On submit failure: Move focus to the first invalid field so keyboard/screen reader users know where to fix

• Tab through all fields in logical order (use tabindex only when necessary, and avoid tabindex values > 0)
• Enter submits the form (native <button type="submit"> handles this)
• Escape closes modals/dropdowns
• Custom dropdowns must support arrow key navigation
• Do not trap focus (user must be able to Tab out of the form) — except in modals, where focus trapping IS correct

<fieldset>
  <legend>Shipping Address</legend>
  <label htmlFor="street">Street</label>
  <input id="street" />
  <!-- more fields -->
</fieldset>

• <fieldset> + <legend> groups related inputs and provides context to screen readers
• Critical for radio button groups

• Use correct type attributes: email, tel, url, number, date — these trigger appropriate mobile keyboards and enable browser autofill
• Use autocomplete attributes: autocomplete="email", autocomplete="given-name" — reduces user effort and errors

• Show a visible success/error message after submission
• Use aria-live="polite" regions for dynamic status updates
• Do not rely solely on color to indicate errors (colorblind users)

• How would you make a custom select/dropdown component accessible?
• What is the difference between aria-live="polite" and aria-live="assertive"?
• How do you test form accessibility during development?

• ESLint eslint-plugin-jsx-a11y — catches 30+ accessibility issues at code time (missing alt text, click handlers on non-interactive elements, missing labels). Runs in IDE as you type.
• TypeScript — proper typing of ARIA attributes catches invalid attribute values at compile time
• Browser DevTools Accessibility panel — inspect the accessibility tree, computed roles, labels, and name computation for any element
• axe DevTools browser extension — one-click accessibility audit of the current page, highlights issues with WCAG rule references

• jest-axe — integrate axe-core into your test suite:

import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);

test('form is accessible', async () => {
  const { container } = render(<LoginForm />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

• Playwright axe integration — run accessibility checks in E2E tests
• Storybook accessibility addon — shows a11y status for each component story

• Lighthouse CI — set accessibility score thresholds. Fail the build if score drops below 90.
• Pa11y CI — automated WCAG compliance checking in pipelines
• axe-core/cli — command-line accessibility testing

• Screen reader testing: VoiceOver (macOS), NVDA (Windows, free), JAWS (Windows, enterprise). Automated tools catch ~30% of accessibility issues. Screen reader testing catches interaction, flow, and comprehension issues that no automated tool can.
• Keyboard-only navigation: Unplug your mouse and navigate your entire app with just Tab, Shift+Tab, Enter, Space, Escape, and arrow keys.
• Zoom testing: Zoom to 200% and verify nothing breaks, overlaps, or becomes unusable.
• Color contrast testing: Use tools like Colour Contrast Analyser or browser DevTools contrast checker.

• Disability community testing services like Fable, accessiBe UserWay. Nothing replaces feedback from actual users with disabilities.

• What percentage of accessibility issues can automated tools catch, and what requires manual testing?
• How would you integrate accessibility testing into a CI/CD pipeline?
• Have you done screen reader testing? What surprised you about the experience?

• Zero-config deployment (built by the same team that builds Next.js)
• Automatic preview deployments for every PR
• Edge Functions, serverless functions, ISR support out of the box
• CDN edge network for static assets
• Analytics and Web Vitals monitoring built in
• Trade-off: Vendor lock-in, can get expensive at scale ($20/seat/month pro, usage-based pricing)

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]

• Full control over infrastructure
• Required for compliance (data sovereignty, on-premise requirements)
• Deploy to AWS ECS/EKS, Google Cloud Run, or any container platform
• You manage scaling, CDN, SSL, health checks

• next export (Pages Router) or output: 'export' in config (App Router)
• Deploy to Cloudflare Pages, Netlify, AWS S3 + CloudFront, GitHub Pages
• Cheapest option, fastest delivery, but no SSR/ISR/API routes

• Managed serverless deployment with SSR support
• More control than Vercel, less than self-hosted

• npm run build produces a dist or build folder of static files
• Host anywhere that serves static files: Netlify, Cloudflare Pages, S3 + CloudFront, Vercel, GitHub Pages
• Configure SPA routing: all paths should return index.html (common gotcha: 404 on refresh because the server does not know about client-side routes)

• Build optimization: NODE_ENV=production, minification, tree shaking
• Error monitoring: Sentry, Bugsnag, or Datadog RUM
• Performance monitoring: Vercel Analytics, SpeedCurve, or Web Vitals
• Health checks and uptime monitoring
• Rollback strategy (keep previous deployment available)
• Environment variables configured in the deployment platform (not committed to git)

• When would you choose self-hosted Docker over Vercel for a Next.js app?
• How do you handle the SPA routing problem when deploying a React app to a static host?
• What is your rollback strategy when a deployment introduces a bug?

• What: Attacker injects malicious JavaScript that executes in other users’ browsers
• Prevention:
  • React auto-escapes JSX output (safe by default)
  • NEVER use dangerouslySetInnerHTML with user input without sanitizing with DOMPurify first
  • Set Content-Security-Policy headers to restrict script sources
  • Sanitize all user-generated HTML on the server side
  • Use HttpOnly cookies for auth tokens (JavaScript cannot read them, so XSS cannot steal them)