Frontend Interview Prep — In Depth

1 Global vs local state — and Context vs Redux vs TanStack Query

The single most important framing: there are two completely different kinds of "state," and most teams break their app by treating them as one.

The decision ladder (climb only as high as you need)

1. Local useState — one component owns it. Default. Stay here until it hurts.
2. Lift state up — two siblings need it → move it to their parent, pass props down.
3. Context — many components deep in the tree need a low-frequency value (theme, locale, current user). Solves "prop drilling."
4. Zustand / Redux — global client state that changes often and is read in many places, where Context would re-render too much.
5. TanStack Query — the data came from a server. Different axis entirely; you'll often use it alongside one of the above.

Context — what it actually is, and its trap

Context is a dependency-injection / transport mechanism, not a state manager. It moves a value down the tree without prop drilling. It has no optimization built in.

// 1. Create
const ThemeContext = createContext('light');

// 2. Provide
function App() {
  const [theme, setTheme] = useState('light');
  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      <Dashboard />
    </ThemeContext.Provider>
  );
}

// 3. Consume — anywhere below, no prop drilling
function ThemeToggle() {
  const { theme, setTheme } = useContext(ThemeContext);
  return <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>{theme}</button>;
}

Fix 1 — useMemo the value object so its reference is stable across renders that don't change its contents:

function App() {
  const [theme, setTheme] = useState('light');

  // ❌ Without useMemo: a NEW object every render → all consumers re-render
  // const value = { theme, setTheme };

  // ✅ Stable reference — only changes when `theme` actually changes
  const value = useMemo(() => ({ theme, setTheme }), [theme]);

  return <ThemeContext.Provider value={value}><Dashboard /></ThemeContext.Provider>;
}

Fix 2 — split into two contexts: the changing value and the stable setter. Components that only dispatch (a toggle button) subscribe to the setter context and never re-render when theme changes:

const ThemeValueContext = createContext(null);   // changes often
const ThemeSetContext   = createContext(null);   // stable forever

function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');
  // setTheme from useState is referentially stable — no useMemo needed
  return (
    <ThemeSetContext.Provider value={setTheme}>
      <ThemeValueContext.Provider value={theme}>{children}</ThemeValueContext.Provider>
    </ThemeSetContext.Provider>
  );
}

// ✅ Only re-renders when `theme` changes
function ThemeLabel() {
  const theme = useContext(ThemeValueContext);
  return <span>{theme}</span>;
}

// ✅ Subscribes to the SETTER only → NEVER re-renders when theme changes
function ThemeToggle() {
  const setTheme = useContext(ThemeSetContext);
  return <button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>flip</button>;
}

Zustand — when Context's re-render model breaks down

Zustand gives you a global store with selector-based subscriptions: a component re-renders only when the specific slice it selected changes — not the whole store. That's the thing Context can't do natively.

import { create } from 'zustand';

const useCartStore = create((set) => ({
  items: [],
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
  clear: () => set({ items: [] }),
}));

// This component re-renders ONLY when items.length changes —
// not when other parts of the store update.
function CartBadge() {
  const count = useCartStore((s) => s.items.length);
  return <span>{count}</span>;
}

Redux Toolkit — when you actually need it

Redux's value isn't "global variables." It's a strict, predictable update contract: state is read-only, the only way to change it is dispatching an action, and a pure reducer computes the next state. That gives you time-travel debugging, a single audit log of every change, and middleware (sagas, logging, analytics).

import { createSlice, configureStore } from '@reduxjs/toolkit';

const cartSlice = createSlice({
  name: 'cart',
  initialState: { items: [] },
  reducers: {
    addItem: (state, action) => { state.items.push(action.payload); }, // Immer = safe "mutation"
    clear: (state) => { state.items = []; },
  },
});

export const { addItem, clear } = cartSlice.actions;
export const store = configureStore({ reducer: { cart: cartSlice.reducer } });

TanStack Query — server state done right

Replaces the entire useEffect + useState fetch dance. You declare what data you want with a key; it handles caching, dedup, background refetch, retries, and loading/error states.

const { data, isLoading, error } = useQuery({
  queryKey: ['user', userId],        // cache identity — same key = shared cache, deduped
  queryFn: () => fetchUser(userId),
  staleTime: 60_000,                // fresh for 60s → no refetch on remount
});

// Mutations + cache invalidation:
const qc = useQueryClient();
const mutation = useMutation({
  mutationFn: updateUser,
  onSuccess: () => qc.invalidateQueries({ queryKey: ['user', userId] }), // refetch fresh
});

★ TanStack Query — deep dive

The one idea everything hangs on: TanStack Query is an async cache, not a state manager. People install it thinking "Redux replacement" — wrong model. Its job is managing the lifecycle of data that lives somewhere else (a server) where you only hold a copy.

What you're actually replacing

The hand-rolled fetch everyone writes first is broken in six ways — and TanStack Query fixes all six by default. That's the real value: correctness you didn't know you were missing, not nicer syntax.

// The naive version — looks fine, isn't
function useUser(id) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);
  useEffect(() => {
    setLoading(true);
    fetch(`/api/users/${id}`).then(r => r.json())
      .then(setData).catch(setError).finally(() => setLoading(false));
  }, [id]);
  return { data, loading, error };
}

Mechanic 1 — the query key is cache identity

const { data, isLoading, error } = useQuery({
  queryKey: ['user', id],          // ← the cache address
  queryFn: () => fetchUser(id),
});

Same key anywhere in the app = same cached entry. Mount this in 10 components with ['user', 5] → one network request, one shared result, all 10 update together. That's automatic dedup + sharing, and it's the single most important concept. Keys are hierarchical and serializable — ['todos', { status: 'done', page: 2 }] — so you can invalidate broadly (['todos'] kills every todo query) or narrowly.

Mechanic 2 — staleTime vs gcTime (the #1 confusion)

useQuery({
  queryKey: ['feed'],
  queryFn: fetchFeed,
  staleTime: 60_000,   // trust this data 60s — no refetch on remount within window
  gcTime: 5 * 60_000, // keep it 5min after the LAST component unmounts
});

Mechanic 3 — refetch triggers (free freshness)

By default it refetches on window refocus, network reconnect, component remount, and key change. The refocus one is the magic: alt-tab away, come back, data silently refreshes. All configurable per-query or globally.

Mechanic 4 — mutations + invalidation (the write path)

Queries read; mutations write, then tell the cache what's now stale.

const qc = useQueryClient();
const mutation = useMutation({
  mutationFn: (updates) => api.updateUser(id, updates),
  onSuccess: () => qc.invalidateQueries({ queryKey: ['user', id] }), // mark stale → auto-refetch
});
mutation.mutate({ name: 'New Name' });

invalidateQueries is the heart of write-then-read consistency: you changed the server, so the cached copy is a lie — mark it stale and let it refetch.

Mechanic 5 — optimistic updates (the advanced move)

Update the UI before the server confirms; roll back if it fails. The pattern — snapshot → optimistic update → rollback on error → reconcile — is worth memorizing cold.

useMutation({
  mutationFn: toggleLike,
  onMutate: async (postId) => {
    await qc.cancelQueries({ queryKey: ['post', postId] }); // stop in-flight refetch
    const previous = qc.getQueryData(['post', postId]);    // snapshot for rollback
    qc.setQueryData(['post', postId], (old) => ({ ...old, liked: !old.liked })); // instant UI
    return { previous };                                   // context → onError
  },
  onError: (_err, postId, ctx) => qc.setQueryData(['post', postId], ctx.previous), // revert
  onSettled: (_d, _e, postId) => qc.invalidateQueries({ queryKey: ['post', postId] }), // reconcile w/ truth
});

When to use it — and when NOT to

The whole rule: use TanStack Query when the data comes from a server you don't control.

What kinds of projects use it

Worked scenario — stock-trading dashboard

2 memo vs useMemo vs useCallback — when, why, and the caveats

All three cache something to avoid wasted work. The confusion is that they cache different things. Lock this table in:

The mental model that ties them together

React re-renders a component when its parent renders. React.memo says "skip me if my props didn't change." But it compares props with shallow equality (Object.is) — and in JS, {} !== {} and (() => {}) !== (() => {}). So every render, a parent creates new object and function props, which breaks React.memo's comparison. useMemo and useCallback exist to keep those references stable so React.memo can do its job. They're a team.

The problem — feel it first

function Parent() {
  const [count, setCount] = useState(0);

  // ❌ New array + new function created EVERY render
  const rows = data.filter(r => r.active);
  const handleClick = (id) => console.log(id);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      <ExpensiveList rows={rows} onClick={handleClick} /> // re-renders on every count++
    </>
  );
}

Every time count changes, rows and handleClick are recreated, so <ExpensiveList> re-renders even though its data didn't change.

The fix — all three together

const ExpensiveList = React.memo(function ExpensiveList({ rows, onClick }) {
  /* heavy render */
});

function Parent() {
  const [count, setCount] = useState(0);

  const rows = useMemo(() => data.filter(r => r.active), [data]);     // stable value
  const handleClick = useCallback((id) => console.log(id), []);       // stable reference

  // Now ExpensiveList only re-renders if rows/onClick actually change.
}

3 Preventing unnecessary re-renders in large apps

First, the mental model interviewers want: a component re-renders when (1) its own state changes, (2) its parent re-renders, (3) a context it consumes changes, or (4) — if memoized — its props change. The non-obvious one: a child re-renders whenever its parent does even if props are identical, unless wrapped in React.memo. So "props didn't change" does not stop a re-render on its own — memoization is what makes props the deciding factor. Get that right and the rest follows.

Always diagnose before optimizing

React DevTools Profiler → record an interaction → it highlights what rendered and "why did this render?" Optimizing blind is how you add 40 useMemos that slow the app down. Measure first.

Technique 1 — Composition (the most underrated)

Pass expensive subtrees as children. A component's children prop is created by the parent above it, so when state changes in the middle component, children keeps its reference and doesn't re-render.

// ❌ ExpensiveTree re-renders every time `open` toggles
function Layout() {
  const [open, setOpen] = useState(false);
  return <div><Toggle open={open} onToggle={setOpen} /><ExpensiveTree /></div>;
}

// ✅ Move state into a wrapper; pass ExpensiveTree as children
function Layout({ children }) {
  const [open, setOpen] = useState(false);
  return <div><Toggle open={open} onToggle={setOpen} />{children}</div>;
}
// <Layout><ExpensiveTree /></Layout> — ExpensiveTree no longer re-renders on toggle

Technique 2 — State colocation

Move state down to the smallest component that needs it. If a search box's text lives at the app root, every keystroke re-renders the whole app. Push it into the search component and only that subtree updates.

Technique 3 — React.memo + stable props

(See Q2.) Memoize pure, expensive children; keep their object/function props stable with useMemo/useCallback.

Technique 4 — Context splitting / selectors

Split a fast-changing value out of a shared context, or use a selector store (Zustand) so components subscribe to slices, not the whole object. (See Q1's Context caveat.)

Technique 5 — List virtualization

Rendering 10,000 rows mounts 10,000 DOM nodes. Virtualization (TanStack Virtual, react-window) renders only the ~20 rows in the viewport and recycles them as you scroll. DOM size becomes constant regardless of data size.

const rowVirtualizer = useVirtualizer({
  count: rows.length,
  getScrollElement: () => parentRef.current,
  estimateSize: () => 35,        // row height px
});
// render only rowVirtualizer.getVirtualItems() — ~20 nodes, not 10,000

4 Suspense for data fetching

Suspense is a declarative boundary for "not ready yet." A component can suspend — signal to React "I'm waiting on something" — and the nearest <Suspense> ancestor shows its fallback until the component is ready. Mechanically, a suspending component throws a promise; React catches it, shows the fallback, and retries the render when the promise resolves.

<Suspense fallback={<Spinner />}>
  <Profile userId={id} />   // suspends while its data loads
</Suspense>

Why it's better than isLoading flags

How you actually wire it (you don't throw promises by hand)

• TanStack Query: useSuspenseQuery — the hook suspends instead of returning isLoading.
• Next.js App Router / RSC: async server components + a loading.tsx file is an automatic Suspense boundary.
• React 19 use() hook: unwraps a promise directly and suspends.

// React 19 — the use() hook
function Profile({ userPromise }) {
  const user = use(userPromise);   // suspends until resolved
  return <h1>{user.name}</h1>;
}

// Next.js App Router — async server component
async function Page() {
  const data = await getData();   // loading.tsx shows while this awaits
  return <Dashboard data={data} />;
}

Two things to pair it with

• Error Boundaries — Suspense handles the pending state; an Error Boundary handles the rejected state. They're complementary; you wrap both.
• Streaming SSR — on the server, React streams HTML in chunks: it sends the shell with fallbacks immediately, then streams each section's HTML as its data resolves. This is what makes RSC feel fast.

5 Structuring a large-scale component library

The goal of a component library is consistency and accessibility by default across many apps and teams — change a token once, every product updates. Here's the architecture I'd defend:

1. Layer the components (atomic-ish)

• Primitives: Button, Input, Text, Box — the alphabet.
• Composites: SearchBar, FormField, Card — primitives combined.
• Patterns: DataTable, Modal, Wizard — full interaction units.

2. Headless behavior + token-driven styling (the key architectural call)

Build on headless primitives — Radix UI or React Aria — which give you correct behavior and accessibility (focus traps, ARIA roles, keyboard nav, screen-reader support) with zero styling. You layer your own styles on top via design tokens.

3. Design tokens as the single source of truth

/* tokens.css — one place defines the system */
:root {
  --color-primary: #1f6feb;
  --space-md: 12px;
  --radius-md: 8px;
  --font-body: 'Inter', sans-serif;
}
/* Components consume tokens, never hard-coded values.
   Rebrand or dark-mode = swap the token layer, nothing else. */

4. Repo & tooling

• Monorepo (pnpm workspaces + Turborepo) — library, docs, and demo apps version together; Turborepo caches builds.
• Storybook — develop & document each component in isolation, every state/variant on display.
• Chromatic (or Playwright snapshots) — visual regression testing catches "this PR shifted Button padding by 2px" automatically.
• Changesets — semver versioning + changelogs for releases.

5. API design discipline (LLD of a component)

• Controlled + uncontrolled support (accept value or defaultValue).
• forwardRef so consumers can reach the DOM node.
• Polymorphic as prop — render a Button as an <a> when it's a link.
• Spread rest props to the root element so consumers can pass aria-*, data-*, etc.
• TypeScript-first — props are the contract; good types are the docs.

const Button = forwardRef(({ as: Tag = 'button', variant = 'primary', ...rest }, ref) => (
  <Tag ref={ref} className={styles[variant]} {...rest} />   // rest = consumer escape hatch
));

R Virtual DOM — what it is and why it's fast

The Virtual DOM is a lightweight JS object tree describing what the UI should look like. When state changes, React builds a new tree, diffs it against the previous one (reconciliation), and applies only the minimal set of real DOM changes.

R useState vs useReducer (and lazy initial state)

Both hold local state. The split is about how complex the transitions are.

// useReducer: transitions are explicit, centralized, testable
function reducer(state, action) {
  switch (action.type) {
    case 'increment': return { count: state.count + 1 };
    case 'reset':     return { count: 0 };
    default: throw new Error('unknown action');
  }
}
const [state, dispatch] = useReducer(reducer, { count: 0 });
// dispatch({ type: 'increment' })  — same Command pattern as Redux, but local

R useRef & list virtualization

useRef — the two jobs

A ref is a mutable box whose .current persists across renders but does NOT trigger a re-render when it changes. Two uses:

• Access a DOM node — focus an input, measure size, play a video: <input ref={inputRef}/> then inputRef.current.focus().
• Hold a mutable value that shouldn't cause renders — a timer/interval ID, the previous value of a prop, a "has this mounted yet" flag.

Virtualization (windowing)

Rendering 10,000 rows means 10,000 DOM nodes → the browser chokes. Virtualization renders only the ~20 rows visible in the viewport (plus a small buffer) and recycles them as you scroll, using padding to fake the full scroll height.

import { FixedSizeList } from 'react-window';
<FixedSizeList height={600} itemCount={10000} itemSize={40} width={'100%'}>
  {({ index, style }) => <div style={style}>Row {index}</div>}  /* only ~15 mounted at once */
</FixedSizeList>

R Meta-frameworks, React without one & when to build an SPA

What's a "meta-framework"?

React is just a UI library — it renders components and nothing else. A meta-framework (Next.js, Remix/React Router, TanStack Start) wraps React with the things a real app needs: routing, data fetching, SSR/SSG, bundling, code splitting, API layer. "Meta" = a framework built on top of a library.

React without a meta-framework

Totally valid: Vite + React + a router (React Router / TanStack Router) gives you a pure client-side SPA. You choose this when you don't need SSR/SEO — internal tools, dashboards behind a login, admin panels.

When to build an SPA (vs MPA/SSR)

R WAI-ARIA — what it is and the #1 rule

WAI-ARIA (Accessible Rich Internet Applications) is a spec of attributes — role, aria-label, aria-expanded, aria-live — that describe the purpose and state of custom UI to assistive tech (screen readers), when native HTML can't.

// Native — accessible by default, zero ARIA needed
<button onClick={open}>Menu</button>

// Custom widget that HAS no native element — ARIA describes state to screen readers
<div role="tablist">
  <button role="tab" aria-selected={active} aria-controls="panel-1">Tab 1</button>
</div>
<div role="region" aria-live="polite">{statusMessage}</div>  // announces updates

JS Map vs Object — when and why

Both store key→value. The instinct is "they're the same." They are not — they're optimized for different jobs.

// The killer difference: Map keys can be ANY value
const el = document.querySelector('#btn');
const meta = new Map();
meta.set(el, { clicks: 0 });        // DOM node as a key — impossible with Object
meta.get(el).clicks++;

// Object footgun: numeric keys become strings, and inherited keys exist
const o = {};
o[1] = 'a'; console.log(Object.keys(o)); // ['1']  — number became a string
console.log(o['toString']);                // ƒ toString() — a key you never set!

JS Map vs WeakMap — the memory-leak question

A WeakMap is a Map whose keys are held weakly: if the only reference left to a key object is the WeakMap entry, the garbage collector is free to delete it.

// Use case: attach private data to an object WITHOUT leaking when it dies
const privateData = new WeakMap();

class Widget {
  constructor(node) {
    privateData.set(this, { node, listeners: [] });
  }
}
// When a Widget is no longer referenced, its WeakMap entry is GC'd automatically.
// With a normal Map, the entry would pin the Widget in memory forever → leak.

JS === vs Object.is() (and why == is banned)

Three equality checks, increasingly precise:

• == (loose) — coerces types before comparing. 0 == '', 1 == true, null == undefined are all true. Source of bugs → never use it (except the one idiom x == null to catch both null & undefined).
• === (strict) — no coercion; same type AND same value. The default you should reach for.
• Object.is() — like === with two fixes.

// The two cases where === lies and Object.is tells the truth:
NaN === NaN;            // false  — but NaN really IS NaN
Object.is(NaN, NaN);   // true  ✅

-0 === +0;               // true  — but they're distinguishable
Object.is(-0, +0);      // false ✅  (1/-0 = -Infinity, 1/+0 = +Infinity)

JS Object.freeze() — and why it's shallow

Object.freeze(obj) makes an object immutable: no adding, deleting, or reassigning properties. In strict mode, attempts throw; otherwise they fail silently.

const config = Object.freeze({ api: '/v1', retries: 3 });
config.retries = 5;          // silently ignored (throws in strict mode)
Object.isFrozen(config);     // true

// ⚠️ SHALLOW — nested objects are still mutable!
const state = Object.freeze({ user: { name: 'Sonali' } });
state.user.name = 'Changed'; // ✅ works — freeze didn't reach inside

// Deep freeze = recurse
function deepFreeze(o) {
  Object.keys(o).forEach(k => {
    if (typeof o[k] === 'object' && o[k] !== null) deepFreeze(o[k]);
  });
  return Object.freeze(o);
}

JS async/await vs .then() chains

Same Promises underneath — async/await is syntax sugar over .then(). The difference is readability and control flow.

// .then chain — pyramid grows, error handling is a separate .catch
fetchUser(id)
  .then(user => fetchPosts(user.id))
  .then(posts => render(posts))
  .catch(err => showError(err));

// async/await — reads like sync code, try/catch is normal
async function load(id) {
  try {
    const user  = await fetchUser(id);
    const posts = await fetchPosts(user.id);
    render(posts);
  } catch (err) { showError(err); }
}

// ❌ 3 sequential round-trips (~3× latency)
const a = await getA(); const b = await getB(); const c = await getC();

// ✅ fired together, await once (~1× latency)
const [a, b, c] = await Promise.all([getA(), getB(), getC()]);

JS Generators — functions that pause

A generator (function*) is a function that can pause at yield and resume later, producing a sequence of values lazily — one at a time, on demand, instead of all at once.

function* idGenerator() {
  let id = 1;
  while (true) yield id++;   // infinite, but lazy — only runs when asked
}
const gen = idGenerator();
gen.next().value; // 1
gen.next().value; // 2  — function resumed where it paused

// Lazy sequence: only computes what you consume
function* take(iter, n) {
  for (const x of iter) { if (n-- <= 0) return; yield x; }
}

JS Hoisting & the Temporal Dead Zone

Before any code runs, the engine scans the scope and registers declarations. That's hoisting. How they're registered differs by keyword — and that's the whole question.

console.log(a); // undefined  — var hoisted & initialized
var a = 1;

console.log(b); // ❌ ReferenceError — let is in the TDZ until its line
let b = 1;

greet();        // ✅ works — function declarations are fully hoisted
function greet() { return 'hi'; }

CSS CSS-in-JS, why Meta moved off it, and StyleX

CSS-in-JS (styled-components, Emotion) means writing styles as JavaScript, scoped to a component. It solved a real problem — global namespace collisions — by generating unique class names so no two components' styles clash.

const Button = styled.button`
  background: ${p => p.primary ? '#6e8efb' : '#2d333b'};
  padding: 10px 16px;
`;  // → generates a unique class, scoped, dynamic from props

// StyleX — looks like CSS-in-JS, but compiles to static atomic CSS
import * as stylex from '@stylexjs/stylex';
const s = stylex.create({
  box: { padding: 16, background: '#161b22' },
});
// <div {...stylex.props(s.box)} />  → static classes, zero runtime

CSS Native nesting, container queries & subgrid

Three features that shipped to all major browsers recently and show up as "are you current?" questions.

1 · Native CSS nesting

You can now nest selectors in plain CSS — no Sass/preprocessor needed.

.card {
  padding: 16px;
  & .title { font-weight: 700; }     /* & = the parent selector */
  &:hover { border-color: #6e8efb; }
}

2 · Container queries — the big one

Media queries respond to the viewport. Container queries respond to the parent element's size. That's the difference that makes components truly reusable.

.sidebar { container-type: inline-size; }   /* declare a containment context */

/* "when MY container is ≥ 400px wide, go horizontal" — ignores the viewport */
@container (min-width: 400px) {
  .card { display: grid; grid-template-columns: 120px 1fr; }
}

3 · Subgrid

Lets a nested grid inherit its parent grid's tracks, so children of different cards line up across cards.

.cards { display: grid; grid-template-columns: repeat(3, 1fr); grid-template-rows: auto 1fr auto; }
.card  { display: grid; grid-row: span 3; grid-template-rows: subgrid; }  /* inherit parent rows */

NX SSR vs SSG vs ISR vs CSR — and the legacy data APIs

// Pages Router (legacy) — the API the gist asks about:
export async function getStaticProps() {      // runs at BUILD time → SSG
  const posts = await getPosts();
  return { props: { posts }, revalidate: 60 };  // add revalidate → ISR
}
export async function getServerSideProps(ctx) {  // runs on EVERY request → SSR
  const user = await getUser(ctx.req.cookies.token);
  return { props: { user } };               // personalized, never cached
}

// App Router (current) — the SAME choices, expressed on the fetch itself:
await fetch(url);                              // cached → SSG-like
await fetch(url, { next: { revalidate: 60 } });  // ISR
await fetch(url, { cache: 'no-store' });        // SSR (per request)

NX getStaticPaths & next/image

getStaticPaths — pre-rendering dynamic routes

For a dynamic route like /blog/[slug], SSG needs to know which slugs to build pages for. getStaticPaths returns that list.

export async function getStaticPaths() {
  const posts = await getPosts();
  return {
    paths: posts.map(p => ({ params: { slug: p.slug } })), // build these at build time
    fallback: 'blocking',  // unknown slug? render on-demand & cache (don't 404)
  };
}

next/image — why not just <img>

Images are the #1 LCP killer. next/image automates every image best-practice you'd otherwise do by hand:

• Auto format + resize — serves WebP/AVIF and the right size per device (no shipping a 4000px image to a phone).
• Lazy-loads by default — off-screen images don't block load.
• Reserves space from width/height → prevents CLS (no layout jump when the image arrives).
• Blur placeholder while loading → better perceived perf.

<Image src="/hero.jpg" width={1200} height={600} priority placeholder="blur" />
// priority = preload this one (it's the LCP element); skip lazy-loading it

NX API routes, deploying off-Vercel, serverless, CDN & Server Components

API routes

Next.js is full-stack: a file in app/api/ (or pages/api/) becomes a backend endpoint in the same project — same repo, same deploy. Great for BFF (backend-for-frontend) work: hiding API keys, proxying, light mutations.

// app/api/users/route.js  → GET /api/users
export async function GET() {
  const users = await db.query('SELECT * FROM users');
  return Response.json(users);
}

Deploying off Vercel

Next.js is open-source and not locked to Vercel. Options: next start on any Node server (Docker → AWS/GCP/Render/Railway), output: 'standalone' for a minimal self-contained Docker image, adapters like OpenNext for AWS Lambda/Cloudflare, or output: 'export' for a pure static bundle on any CDN/S3 (loses SSR/ISR/API routes — static only). Vercel is just the zero-config first-party host.

Serverless mode & the static CDN

React Server Components — the current model

In the App Router, components are Server Components by default: they render on the server, can await data directly, and ship zero JavaScript to the browser. You opt into client interactivity with 'use client'.

// Server Component (default) — no useState/onClick, runs server-side, 0 client JS
async function ProductList() {
  const products = await db.products.findAll(); // query DB right here — no API layer
  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}

'use client';  // ↓ this one ships JS — it needs state/handlers
function AddToCart() { const [n, setN] = useState(0); /* … */ }

6 Handling slow API responses or large payloads

Split the problem into two questions: (a) how do I move less data / fewer times? and (b) how do I make waiting feel instant? Senior answers cover both — actual perf and perceived perf.

Reduce the data on the wire

• Pagination / cursor paging: never fetch 10k rows. Cursor-based (?after=id) beats offset paging — offset gets slow and drifts when rows are inserted mid-scroll.
• Fetch only needed fields: GraphQL, or REST sparse fieldsets (?fields=id,name). Stops over-fetching.
• Compression: gzip/brotli at the server/CDN — often 70%+ smaller for JSON.
• BFF (Backend-for-Frontend): a thin server layer that aggregates and trims responses for the UI, so the client makes one shaped call instead of five raw ones.

Reduce the number of requests

• Dedup in-flight requests — TanStack Query collapses identical concurrent queries into one.
• Debounce/throttle user-driven requests (search-as-you-type).
• Cancel stale requests with AbortController so a fast typist doesn't race responses.

function useSearch(term) {
  return useEffect(() => {
    const ctrl = new AbortController();
    fetch(`/search?q=${term}`, { signal: ctrl.signal })
      .then(r => r.json())
      .catch(e => { if (e.name !== 'AbortError') throw e; });
    return () => ctrl.abort();   // cancel previous on new keystroke / unmount
  }, [term]);
}

Make waiting feel instant (perceived performance)

• Skeleton screens over spinners — they preview layout, feel faster, and prevent layout shift.
• Optimistic updates — update the UI immediately, roll back if the server rejects.
• stale-while-revalidate — show cached data instantly, refetch in the background, swap when fresh.
• Streaming — render the page shell immediately, stream slow sections in (Suspense + RSC).

// Optimistic update with TanStack Query
useMutation({
  mutationFn: toggleLike,
  onMutate: async (id) => {
    await qc.cancelQueries({ queryKey: ['post', id] });
    const prev = qc.getQueryData(['post', id]);
    qc.setQueryData(['post', id], p => ({ ...p, liked: !p.liked })); // instant UI
    return { prev };                                            // rollback context
  },
  onError: (_e, id, ctx) => qc.setQueryData(['post', id], ctx.prev),  // revert
});

7 Bundle optimization — tree shaking, lazy loading, dynamic imports

The framing that makes these click: tree shaking shrinks the bundle at build time; code splitting defers parts of it to runtime. Different problems. One removes code you never use; the other delays code you don't need yet.

Tree shaking — remove dead code

The bundler statically analyzes import/export and drops exports nobody uses. Requirements:

• ES modules, not CommonJS. Tree shaking relies on static import/export — require() is dynamic and can't be analyzed.
• Named imports. import { debounce } from 'lodash-es' shakes; import _ from 'lodash' pulls the whole library.
• "sideEffects": false in package.json tells the bundler "importing this file does nothing but export" so it can safely drop unused ones. (List exceptions like CSS imports.)

Code splitting + lazy loading — defer to runtime

import { lazy, Suspense } from 'react';

const Dashboard = lazy(() => import('./routes/Dashboard')); // own chunk, loaded on demand

<Suspense fallback={<PageSkeleton />}>
  <Dashboard />
</Suspense>

Dynamic imports — load heavy things only when used

// Don't ship a 300kb charting lib in the main bundle —
// load it only when the user opens the analytics panel.
async function openCharts() {
  const { renderChart } = await import('./heavy-charts'); // returns a promise
  renderChart();
}

Other levers

• Analyze: vite-bundle-visualizer / webpack-bundle-analyzer — see what's actually big.
• Swap heavy deps: moment.js (~70kb) → day.js/date-fns; lodash → lodash-es or native.
• Dedupe React — two copies of React is a classic bundle bloat + runtime bug.
• Compression + hashed filenames for long-term caching (see Q9).

8 Web Vitals — measuring and improving LCP, INP, CLS

The three Core Web Vitals

Why INP replaced FID (the depth)

How to measure — lab vs field

• Lab (synthetic): Lighthouse, PageSpeed Insights, Chrome DevTools — reproducible, but one machine/network. INP isn't fully measurable in lab (needs real interactions).
• Field (RUM — real user monitoring): the web-vitals npm library reports real users' metrics to your analytics; Chrome UX Report (CrUX) is field data Google actually ranks you on.

import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(sendToAnalytics);
onINP(sendToAnalytics);   // real-user field data — what Google ranks on
onCLS(sendToAnalytics);

9 Caching strategy for frontend apps

There's no single cache — there are layers, each catching a different request closer to the user. Name them as a stack; that's the senior framing.

1. HTTP caching + content hashing (the foundation)

Build tools fingerprint filenames: app.9f2a1c.js. Because the hash changes when content changes, you can cache these forever (Cache-Control: max-age=31536000, immutable) and bust the cache by shipping a new filename. The index.html stays no-cache so it always points at the latest hashed assets.

2. The cache strategies (name them)

• Cache-first: serve from cache, only hit network on miss. For immutable assets (fonts, hashed JS).
• Network-first: try network, fall back to cache. For data that should be fresh but must work offline.
• Stale-while-revalidate: serve cache instantly and refetch in background, update next time. The sweet spot for most data — instant + eventually fresh. This is TanStack Query's default model.

// TanStack Query caching knobs
useQuery({
  queryKey: ['feed'],
  queryFn: fetchFeed,
  staleTime: 30_000,   // "fresh" 30s → served from cache, no refetch
  gcTime: 5 * 60_000, // kept in memory 5min after unused, then garbage-collected
});

10 Identifying and fixing memory leaks in React

A leak is memory the app no longer needs but the garbage collector can't reclaim because something still references it. In React, that "something" is almost always a subscription, timer, or listener that outlived its component.

The four classic causes — and fixes

• Uncleaned timers/subscriptions: setInterval, event listeners, WebSocket, store subscriptions. → Return a cleanup function from useEffect.
• State update after unmount: async resolves after the component is gone, calls setState on a dead component. → Abort the request / guard with a flag.
• Closures capturing large objects in long-lived references: a callback stored in a ref, a global subscription, or module-level cache closes over a big structure (or a whole component's props/state) and keeps it alive after it's no longer needed.
• Listeners on window/document: not removed → the handler (and everything it closes over) stays alive forever.

function LiveClock() {
  const [now, setNow] = useState(() => Date.now()); // lazy init

  useEffect(() => {
    const id = setInterval(() => setNow(Date.now()), 1000);
    return () => clearInterval(id);   // ✅ cleanup — without this, the timer leaks on unmount
  }, []);

  return <span>{now}</span>;
}

// Async fetch — cancel to avoid "setState on unmounted component"
useEffect(() => {
  const ctrl = new AbortController();
  fetch(url, { signal: ctrl.signal }).then(setData).catch(() => {});
  return () => ctrl.abort();         // ✅ cancel in-flight on unmount
}, [url]);

How to detect (this is what separates juniors)

1. Chrome DevTools → Performance Monitor: watch "JS heap size" while using the app. A sawtooth that trends upward and never drops after GC = leak.
2. Memory tab → Heap snapshots: take a snapshot, perform the suspect action (open/close a modal 10×), take another, and compare. Filter for "Detached" DOM nodes — DOM removed from the page but still referenced by JS — the smoking gun.
3. Allocation timeline: records allocations over time so you can see what's growing.

11 Environment configs for different builds

The core decision is one most people get wrong: build-time config vs runtime config. Get this distinction right and the rest is detail.

Build-time config (the default)

Values are baked into the bundle when you build. Vite exposes only VITE_-prefixed vars via import.meta.env; everything else stays out of the client for safety.

# .env.development
VITE_API_URL=http://localhost:3000

# .env.production
VITE_API_URL=https://api.myapp.com

const apiUrl = import.meta.env.VITE_API_URL;  // inlined at build time

Vite auto-loads .env.[mode] based on the --mode flag. CI runs a separate build per environment.

Runtime config (for containers / one-build-everywhere)

// public/config.json — swapped per environment at deploy, not build
{ "apiUrl": "https://api.myapp.com" }

// app bootstraps from it
const cfg = await fetch('/config.json').then(r => r.json());

12 Workflow with Webpack / Vite / Turbopack

The thing to understand isn't the tools — it's the architectural shift they represent: from "bundle everything before serving" to "serve native ES modules and only bundle for production."

Why Vite's dev server is so much faster (the depth)

13 Managing feature flags

The one-sentence purpose: feature flags decouple deploy from release. You ship code to production turned off, then flip it on for whoever you choose, whenever you choose — no redeploy.

What they unlock

• Gradual rollout: enable for 1% → 10% → 100%, watching metrics.
• Kill switch: something's on fire → flip off instantly, no rollback deploy.
• A/B testing: show variant A to half, B to the other half.
• Trunk-based development: merge incomplete features to main behind a flag instead of long-lived branches.
• Targeting: beta users, internal staff, specific plans/regions.

Implementation

// Provider wraps the app; flags evaluated per-user from a service
<FlagProvider userId={user.id} attributes={{ plan: user.plan, region }}>
  <App />
</FlagProvider>

// Consume with a hook
function Checkout() {
  const newFlow = useFlag('new-checkout-flow');
  return newFlow ? <NewCheckout /> : <LegacyCheckout />;
}

• Tools: LaunchDarkly (the standard), Split.io, Unleash (open source), or a homegrown service + config endpoint.
• Client vs server eval: client-side is simple but flag values are visible to users (don't gate security with them); server-side keeps logic private and avoids flicker.

14 Monitoring & logging frontend issues (Sentry, Datadog)

Frame it as three distinct questions you're answering with different tools: What broke? How does it feel for real users? What are people actually doing?

What I actually wire up

• Error boundaries → Sentry: catch React render errors and report them with component stack.
• Source map upload in CI: the killer detail — without it, prod stack traces are minified gibberish (a.b.c is not a function). Upload maps on deploy so traces map back to real source.
• Release tracking: tag errors with the release/commit so you know which deploy introduced a spike — and regressions are obvious.
• web-vitals → analytics: field performance data (see Q8).
• Alerting: error-rate spike or new error type → Slack/PagerDuty.

import * as Sentry from '@sentry/react';

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,
  release: import.meta.env.VITE_COMMIT_SHA,   // tie errors to a deploy
  tracesSampleRate: 0.1,                     // sample perf traces (cost control)
  integrations: [Sentry.replayIntegration()], // session replay of the crash
});

15 Design a dashboard that scales to 10K concurrent users

First, reframe it like a senior would: "10K concurrent" is mostly a backend/infra problem — the static frontend scales trivially. The real frontend challenge is real-time data fan-out and rendering efficiency." Saying that up front shows you know where the hard part actually lives.

1. The app shell scales for free

The HTML/JS/CSS are just files. Put them on a CDN and 10K or 10M users cost the same per-user — edge nodes serve cached static assets. Zero origin load. This part is solved.

2. Real-time data is the actual problem

3. Rendering — don't melt the client

• Granular subscriptions: each widget subscribes to its data slice, so one metric tick re-renders one widget, not the whole dashboard. (Selector store — Q1/Q3.)
• Virtualization for big tables/lists (Q3) — constant DOM size.
• Aggregate server-side: ship computed summaries, not 100k raw rows for the client to crunch.
• Web workers for any heavy client-side computation so the main thread stays responsive (protects INP).

4. Resilience & data freshness

• Reconnect with exponential backoff on socket drop; degrade gracefully to polling if sockets fail.
• Optimistic UI for user actions; stale-while-revalidate for reads.
• Backpressure: if updates arrive faster than render, drop/coalesce intermediate frames — show the latest, not every one.

16 Ensuring consistent design and behavior across modules

Consistency doesn't come from telling people to be careful — it comes from making the consistent path the only easy path. You enforce it with tooling, not discipline.

The layers of enforcement

• Design tokens — one source of truth for color/space/type (Q5). Modules can't drift because they all consume the same tokens.
• Shared component library — every module uses the same Button, Modal, Table. Behavior is consistent because it's literally the same code.
• Linting + formatting as gates: ESLint, Prettier, Stylelint, run in CI and pre-commit hooks (Husky + lint-staged) so non-conforming code can't merge.
• Shared TypeScript types / contracts — modules agree on data shapes; a contract change breaks the build, not production.
• Visual regression (Chromatic) — catches unintended visual drift in PRs automatically.
• Documentation (Storybook) — devs reach for the existing component because they can find and see it.

For micro-frontends specifically

17 Code splitting and lazy loading routes

The whole point: a user visiting the login page shouldn't download the admin dashboard's code. Route-level splitting maps your bundle to your navigation so people download only what they use.

The standard pattern

import { lazy, Suspense } from 'react';
import { Routes, Route } from 'react-router-dom';

const Dashboard = lazy(() => import('./routes/Dashboard'));
const Settings  = lazy(() => import('./routes/Settings'));

function App() {
  return (
    <Suspense fallback={<PageSkeleton />}>
      <Routes>
        <Route path="/dashboard" element={<Dashboard />} />
        <Route path="/settings"  element={<Settings />} />
      </Routes>
    </Suspense>
  );
}

lazy(() => import(...)) tells the bundler to split that route into its own chunk, fetched only when the route is hit. Suspense shows a fallback during the fetch.

The senior detail — prefetching to hide the latency

// Prefetch on hover — chunk is ready by the time they click
<Link
  to="/dashboard"
  onMouseEnter={() => import('./routes/Dashboard')}
>Dashboard</Link>

Where to draw split boundaries

• Routes — the primary, highest-leverage boundary.
• Heavy below-the-fold / on-interaction widgets — charts, rich-text editors, maps, modals.
• Large conditional features — admin-only panels, rarely-used flows.

18 Ensuring accessibility (a11y) and cross-browser compatibility

Accessibility — semantics first, ARIA last

• Semantic HTML: <button>, <nav>, <main>, <label> for inputs, heading hierarchy.
• Keyboard navigation: every interactive element reachable and operable by keyboard; visible focus indicators; logical tab order.
• Focus management: open a modal → trap focus inside + return it on close. (This is why headless libs like Radix are worth it — Q5.)
• Color contrast: WCAG AA — 4.5:1 for body text.
• Screen-reader labels: aria-label on icon buttons, alt on images, live regions for dynamic updates.

How to test a11y

• Automated: eslint-plugin-jsx-a11y (catches issues as you type), axe DevTools, Lighthouse a11y audit. Catches ~30–40% — the mechanical stuff.
• Manual: the other 60% — unplug your mouse and navigate by keyboard; turn on VoiceOver (Mac) / NVDA (Windows) and listen to your key flows. Automation can't tell you if the experience makes sense.

Cross-browser compatibility

• browserslist — declare your target browsers in one place; Babel, PostCSS, and Autoprefixer all read it.
• Autoprefixer / PostCSS — adds vendor prefixes automatically based on your targets.
• Babel — transpiles modern JS to what your targets support; polyfills (core-js) for missing APIs.
• Feature detection over UA sniffing — check if ('IntersectionObserver' in window), don't parse the user-agent string (brittle, spoofable).
• Progressive enhancement — core functionality works everywhere; enhancements layer on where supported.
• Cross-browser testing: Playwright runs your suite across Chromium/Firefox/WebKit; BrowserStack/Sauce for real-device matrices.

Prototype chain & prototypal inheritance

Every JS object has a hidden link ([[Prototype]]) to another object. When you read a property, JS looks on the object, then walks up each link until it finds it or hits null. That walk is the prototype chain — it's how inheritance works in JS.

const arr = [1, 2, 3];
// arr.map() works even though arr has no `map` of its own:
// arr → Array.prototype (map, filter, push…) → Object.prototype (toString…) → null
Object.getPrototypeOf(arr) === Array.prototype;            // true
Object.getPrototypeOf(Array.prototype) === Object.prototype; // true
Object.getPrototypeOf(Object.prototype) === null;            // end of chain

• ES6 class is sugar over this — extends just wires one prototype to another. No classical inheritance underneath; it's prototypes all the way down.
• hasOwnProperty checks only the object itself (not the chain) — useful when iterating to skip inherited props.
• Perf: a property found 4 links up costs 4 lookups vs 1. Deep chains in a hot loop add up — though engines optimize heavily.

Property lookup walks the chain left → right until found (or hits null).

The lookup algorithm as a flowchart — this loop is the prototype chain.

Closures

A function remembers the variables from the scope where it was created, even after that outer function has returned. This is what powers debounce/throttle (the timer lives in the closure), memoization (the cache lives in the closure), and module privacy.

function counter() {
  let count = 0;              // private — survives because the inner fn closes over it
  return () => ++count;
}
const next = counter();
next(); next(); // 1, 2 — `count` persists between calls

The inner function keeps a live reference to count, so it survives after counter() returns — that's the closure.

Hoisting, this, == vs ===, value vs reference

• Hoisting: var & function declarations are moved to the top of scope (var = undefined until assigned). let/const hoist too but sit in the temporal dead zone — accessing before declaration throws.
• this: determined by how a function is called, not where it's defined. Arrow functions have no own this — they inherit it from the enclosing scope (why they're used for callbacks).
• == vs ===: == coerces types (0 == '' is true); === doesn't. Always use ===.
• Value vs reference: primitives copy by value; objects/arrays copy by reference. This is why a shallow copy ({...obj}) shares nested objects — and why deep-clone questions exist.