React Interview Questions

React is a JavaScript library for building user interfaces with a component-based model. You describe UI as a function of state, and React updates the DOM efficiently when data changes. Teams choose it for its ecosystem, reusable components, strong hiring market, and declarative style that scales for complex UIs.

function Welcome({ name }) {
  return <h1>Hello, {name}</h1>;
}

// App composes components instead of manipulating the DOM by hand
export default function App() {
  return <Welcome name="Alex" />;
}

• Is React a framework or a library?
• What problems does React solve that jQuery does not?
• What is the declarative vs imperative difference?

• Calling React a ‘framework’ without mentioning routing/state libraries
• Saying React updates the DOM directly on every change
• Not mentioning components or one-way data flow

Describe your portfolio or capstone as a tree of components (layout, pages, shared UI) instead of one big HTML file.

The Virtual DOM is a lightweight in-memory representation of the real DOM. When state changes, React builds a new virtual tree, diffs it against the previous one (reconciliation), and applies the minimal set of updates to the actual DOM. You still write JSX as if the DOM updates wholesale; React batches and optimizes the work.

// You think in UI updates:
function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}
// React figures out which DOM node text to change.

• Is the Virtual DOM always faster than direct DOM updates?
• What is reconciliation?
• Does React 18 change how updates are scheduled?

• Claiming React never touches the real DOM
• Confusing Virtual DOM with Shadow DOM
• Saying VDOM is the same as the browser DOM

When a list re-renders in your project, React’s diffing is why changing one item does not rebuild the entire page manually.

JSX is a syntax extension that lets you write HTML-like markup inside JavaScript. It is not HTML: className replaces class, you embed expressions with {}, and self-closing tags are required. Build tools (Babel, Vite) compile JSX to React.createElement calls or the automatic JSX runtime.

const element = (
  <section className="card">
    <h2>{product.name}</h2>
    <p>{product.price.toFixed(2)}</p>
  </section>
);

• Can you use React without JSX?
• Why className instead of class?
• What gets returned from a component?

• Treating JSX as a template language that runs in the browser raw
• Using class in JSX
• Forgetting a single parent or Fragment wrapper when returning siblings

Your .jsx files are JSX; mentioning compile step shows you understand the toolchain (Vite/CRA).

Functional components are plain functions that return JSX and use hooks for state and side effects. Class components extend React.Component, use this.state, and lifecycle methods. Since React 16.8+, functions + hooks are the standard; classes are mainly for maintenance or older tutorials.

// Functional (preferred)
function Greeting({ name }) {
  const [wave, setWave] = useState(false);
  return <p onClick={() => setWave(!wave)}>Hi {name}{wave ? " 👋" : ""}</p>;
}

// Class (legacy)
class GreetingClass extends React.Component {
  state = { wave: false };
  render() {
    return <p onClick={() => this.setState({ wave: !this.state.wave })}>Hi {this.props.name}</p>;
  }
}

• Can hooks be used in class components?
• How do you migrate a class to a function?
• What is this binding in class components?

• Starting new projects with class components
• Not knowing equivalent hooks for lifecycle methods
• Confusing function components with ‘stateless’ only

Write new features in your project as function components; if you read old examples, map componentDidMount to useEffect(..., []).

Props (properties) are read-only inputs passed from a parent to a child. They make components reusable and configurable. A child must not mutate props; if the UI needs to change, the parent updates state and passes new props down.

function Avatar({ src, alt, size = 48 }) {
  return <img src={src} alt={alt} width={size} height={size} />;
}

<Avatar src="/me.jpg" alt="Profile" size={64} />

• Props vs state?
• How do you pass a function as a prop?
• What is prop types / TypeScript for props?

• Trying to modify props inside the child
• Drilling the same prop through many layers without Context
• Spreading unknown props without care ({...props}) onto DOM nodes

Shared UI in your app (buttons, cards) should accept props for text, variants, and callbacks.

State is data owned by a component that can change over time. When state updates, React re-renders the component and typically its children. State updates should be treated as immutable — create new objects/arrays rather than mutating existing state.

function Toggle() {
  const [on, setOn] = useState(false);
  return (
    <button onClick={() => setOn((prev) => !prev)}>
      {on ? "On" : "Off"}
    </button>
  );
}

• Where should state live?
• What triggers a re-render?
• State vs refs?

• Mutating state directly (state.push, state.count++)
• Putting derived data in state when it can be computed
• Too much state in one component

Form inputs, modals open/closed, and fetched data in your project are all state candidates — explain where you kept each.

Prop drilling is passing props through many intermediate components that do not use them, only to reach a deep child. Fixes include lifting state only as high as needed, Context for widely shared values (theme, auth user), composition (children/slots), or dedicated state libraries for complex global state.

// Theme via Context instead of drilling through Layout > Sidebar > Link
const ThemeContext = createContext("light");

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Layout />
    </ThemeContext.Provider>
  );
}

function Link() {
  const theme = useContext(ThemeContext);
  return <a className={theme}>Home</a>;
}

• When is prop drilling acceptable?
• Context vs Redux?
• What is component composition?

• Using Context for every piece of state
• Globalizing state that should stay local
• Not recognizing drilling in your own codebase

If your navbar, sidebar, and page all needed the logged-in user, explain whether you drilled props or used Context.

useState returns a state value and a setter function. Calling the setter schedules a re-render with the new value. You can pass an initial value or a lazy initializer function for expensive setup. Use functional updates setCount(c => c + 1) when the next state depends on the previous state.

function Cart() {
  const [items, setItems] = useState([]);

  function addItem(item) {
    setItems((prev) => [...prev, item]);
  }

  return <button onClick={() => addItem({ id: 1 })}>Add</button>;
}

• Why functional updates?
• Does the setter merge objects?
• Can you call useState conditionally?

• Mutating arrays/objects in state
• Assuming setState merges like class setState (it replaces for objects)
• Calling useState inside loops or conditions

Shopping cart or todo list in your project is a perfect useState story with immutable array updates.

useEffect runs after render when React has painted the DOM (by default). You use it to synchronize with external systems: fetching data, subscribing to events, timers, or integrating non-React libraries. Return a cleanup function to run before re-run or unmount.

useEffect(() => {
  document.title = `Unread: ${count}`;
}, [count]);

• When does useEffect run?
• What is the dependency array?
• useEffect vs useLayoutEffect?

• Using useEffect for every state change without need
• Missing dependencies (stale closures)
• No cleanup on subscriptions

Fetching project list on mount or syncing a document title are classic useEffect examples you can cite.

The second argument to useEffect lists values that the effect reads from the component scope. When any dependency changes, the effect re-runs. An empty array [] means run once after mount (and cleanup on unmount). Omitting the array runs the effect after every render (rarely what you want).

useEffect(() => {
  let cancelled = false;
  fetch(`/api/user/${userId}`)
    .then((r) => r.json())
    .then((data) => { if (!cancelled) setUser(data); });
  return () => { cancelled = true; };
}, [userId]);

• Why do exhaustive-deps lint rules exist?
• Are setState functions stable dependencies?
• What is a stale closure in an effect?

• Empty deps when the effect uses props/state
• Putting objects/functions in deps without memoization
• Disabling eslint instead of fixing deps

When your effect fetched data for a selected id, [selectedId] in the dependency array prevented showing wrong user’s data.

Return a function from useEffect. React calls it before the effect runs again (if dependencies changed) and when the component unmounts. Use cleanup to clear intervals, abort fetches, remove event listeners, or unsubscribe from sockets.

useEffect(() => {
  const id = setInterval(() => setTick((t) => t + 1), 1000);
  return () => clearInterval(id);
}, []);

• What happens if you forget cleanup?
• Does cleanup run on first mount?
• How to abort fetch in cleanup?

• Adding duplicate listeners on every render
• Not clearing timers
• Assuming cleanup runs only on unmount when deps change too

A search-as-you-type feature should cancel in-flight requests or ignore stale responses in cleanup.

useRef returns a mutable object { current } that persists across renders. Common uses: accessing DOM nodes (inputRef.current.focus()), storing timer IDs, or keeping previous values. Updating ref.current does not trigger a re-render.

function Search() {
  const inputRef = useRef(null);
  useEffect(() => {
    inputRef.current?.focus();
  }, []);
  return <input ref={inputRef} />;
}

• useRef vs useState?
• Can refs hold any value?
• When to use callback refs?

• Storing UI state in refs to avoid re-renders (wrong tool)
• Reading ref.current during render for UI logic
• Overusing refs instead of controlled components

Auto-focus on a login field or measuring an element height are practical ref examples.

useContext(SomeContext) reads the nearest matching Provider value above in the tree. Pair with createContext and Provider. Good for theme, locale, or auth snapshot. When the provided value changes, consuming components re-render.

const AuthContext = createContext(null);

function Dashboard() {
  const user = useContext(AuthContext);
  if (!user) return <p>Please log in</p>;
  return <p>Welcome, {user.name}</p>;
}

• Does Context replace Redux?
• How to avoid unnecessary re-renders?
• Default context value?

• Putting fast-changing data in Context for the whole app
• Creating context inside render
• Not memoizing Provider value objects

If you shared login state across routes, Context is a simple story before introducing Redux.

useMemo caches the result of an expensive calculation between renders until dependencies change. Use it when profiling shows real cost, or when you need referential stability for child memoization. Do not wrap every computation — it has overhead.

const sorted = useMemo(
  () => [...items].sort((a, b) => a.price - b.price),
  [items]
);

• useMemo vs useCallback?
• Does useMemo prevent re-renders?
• React Compiler and memoization?

• Memoizing cheap operations
• Wrong dependency arrays
• Expecting useMemo to fix all performance issues

Filtering a large product list before display is a believable useMemo example if sorting/filtering was slow.

useCallback returns a memoized function that only changes when its dependencies change. Useful when passing callbacks to React.memo children or listing functions in useEffect dependencies without re-firing every render.

const handleSave = useCallback(() => {
  saveItem(draft);
}, [draft]);

return <MemoizedEditor onSave={handleSave} />;

• useCallback vs inline arrow functions?
• Do all children need memo?
• Inlining vs callback stability

• Wrapping every handler in useCallback
• Empty deps when closure uses stale state
• Using useCallback without React.memo downstream

Passing onSubmit to a memoized form component is a common useCallback scenario.

useReducer takes a reducer (state, action) => newState and an initial state, returning [state, dispatch]. Prefer it when state logic has multiple sub-values, next state depends on previous in non-trivial ways, or actions are easier to name than many setX calls.

function reducer(state, action) {
  switch (action.type) {
    case "add": return { ...state, items: [...state.items, action.item] };
    case "clear": return { ...state, items: [] };
    default: return state;
  }
}

const [state, dispatch] = useReducer(reducer, { items: [] });

• useReducer vs Redux?
• Can useReducer be combined with Context?
• Immer with reducers?

• Using useReducer for a single boolean
• Mutating state inside reducer
• Huge switch statements without splitting logic

A multi-step wizard or form with several fields can be explained with useReducer actions.

A custom hook is a function whose name starts with use that calls other hooks. It lets you extract stateful logic (fetch, form, media query) into one place. Each component using the hook gets its own isolated state.

function useLocalStorage(key, initial) {
  const [value, setValue] = useState(() => {
    const stored = localStorage.getItem(key);
    return stored ? JSON.parse(stored) : initial;
  });
  useEffect(() => {
    localStorage.setItem(key, JSON.stringify(value));
  }, [key, value]);
  return [value, setValue];
}

• Can custom hooks return anything?
• Rules of Hooks in custom hooks?
• Testing custom hooks?

• Custom hooks that do not call hooks but use the use prefix
• Sharing one state instance across app incorrectly
• Putting JSX inside custom hooks

Extract useFetchProjects from your portfolio if you repeated fetch + loading + error logic.

A controlled component has form values driven by React state — the input’s value comes from state and onChange updates state. Uncontrolled components store values in the DOM; you read them via refs (e.g. on submit). Controlled gives validation and single source of truth; uncontrolled can be simpler for quick forms.

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

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

• defaultValue vs value?
• When is file input uncontrolled?
• React Hook Form — controlled or not?

• Mixing controlled and uncontrolled (value without onChange)
• Using defaultValue after first render to reset
• Not lifting controlled state for shared forms

Your login form is likely controlled — say how you validated email before submit.

Keys help React identify which list items changed, were added, or removed. Stable keys preserve component state and DOM nodes for the correct item. Use stable unique IDs from data, not array index when the list can reorder or items can be inserted in the middle.

{tasks.map((task) => (
  <TaskRow key={task.id} task={task} />
))}

• Index as key — when is it OK?
• What happens if keys duplicate?
• Keys on Fragments?

• Using key={index} on sortable lists
• Generating keys with Math.random() on each render
• Putting key on the wrong element in a map

Buggy checkboxes after deleting a todo usually means wrong keys — mention fixing with todo.id.

Reconciliation is React’s process of comparing the new element tree with the previous one and deciding the minimal DOM updates. It uses heuristics (same component type at same position updates in place; different types unmount/remount). Keys improve matching in lists. Fiber architecture enables interruptible work in React 18.

// Swapping types remounts — state resets
{loggedIn ? <Dashboard key="dash" /> : <Login key="login" />}

• What is the Fiber reconciler?
• How do keys affect reconciliation?
• diff O(n) heuristic?

• Thinking React diffs the whole DOM character by character
• Not understanding remount on key/type change
• Ignoring state loss on remount

Explain why changing key on a component resets its internal state (useful for ‘reset form’ patterns).

When two components need the same data, move state to their closest common ancestor and pass state plus updaters down as props. Siblings stay in sync because one parent owns the truth.

function Parent() {
  const [text, setText] = useState("");
  return (
    <>
      <Editor value={text} onChange={setText} />
      <Preview text={text} />
    </>
  );
}

• Lift state vs Context?
• Colocation of state?
• Prop drilling after lifting?

• Lifting state too high globally
• Duplicating state in siblings
• Not passing callback to update shared state

Temperature converter or shared search box between list and map views are interview-friendly examples.

Use JavaScript in JSX: if before return, ternary for two branches, && for simple show/hide (careful with 0), or early returns for guard clauses. Keep conditions readable; extract subcomponents when JSX gets nested.

if (loading) return <Spinner />;
if (error) return <ErrorBanner message={error} />;
return items.length ? <List items={items} /> : <EmptyState />;

• Danger of count && <Badge />?
• Switch vs object map for many cases?
• Suspense for loading?

• Using && with numbers that can be 0
• Deeply nested ternaries
• Duplicating layout in every branch

Your data-fetching page should mention loading, error, and empty UI — interviewers love that.

Install react-router-dom, wrap the app in a router (BrowserRouter or createBrowserRouter + RouterProvider), define Route elements with path and element, and use Link/NavLink for navigation without full page reloads.

import { BrowserRouter, Routes, Route, Link } from "react-router-dom";

export default function App() {
  return (
    <BrowserRouter>
      <nav><Link to="/">Home</Link></nav>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    BrowserRouter>
  );
}

• BrowserRouter vs HashRouter?
• Nested routes?
• 404 route?

• Using <a href> for internal links causing full reload
• Routes outside Router
• Forgetting basename on deployed subpaths

Your portfolio’s /projects and /contact pages are natural React Router talking points.

useParams reads URL parameters from dynamic segments like /users/:id. useNavigate returns a function to change routes in code (after form submit, logout, etc.), optionally with replace or state.

function UserPage() {
  const { id } = useParams();
  const navigate = useNavigate();
  return (
    <button onClick={() => navigate("/users", { replace: true })}>
      User {id} — Back
    </button>
  );
}

• useSearchParams?
• Relative navigation?
• Protecting routes?

• Parsing window.location manually
• Not handling missing params
• Navigate in render causing loops

Project detail /projects/:slug is a strong useParams example from your own app.

Use Context when many components need the same moderately stable data (theme, auth, language) and prop drilling hurts. Avoid Context for high-frequency updates to the entire tree or when simple props suffice. You can combine Context with useReducer for richer logic.

const LocaleContext = createContext("en");
// Provider at app root; consumers read with useContext

• Splitting contexts?
• Context performance?
• Server Components and context?

• One giant context causing global re-renders
• Using Context as a full Redux replacement blindly
• Not documenting what belongs in context

Explain what you would not put in Context (e.g. every keystroke in a huge form).

Error boundaries catch JavaScript errors in child component trees during render, in lifecycle methods, or in constructors. They show fallback UI via getDerivedStateFromError / componentDidCatch and do not catch event handlers, async code, or SSR errors by themselves. There is no hook equivalent yet — use a class boundary or library.

class ErrorBoundary extends React.Component {
  state = { hasError: false };
  static getDerivedStateFromError() { return { hasError: true }; }
  componentDidCatch(error, info) { log(error, info); }
  render() {
    return this.state.hasError ? <h2>Something went wrong.</h2> : this.props.children;
  }
}

• What errors are not caught?
• Error boundary per route?
• react-error-boundary package?

• Trying to catch errors in event handlers with boundaries only
• No logging in componentDidCatch
• Wrapping every tiny component separately

Wrap route-level content so one broken widget does not white-screen your whole portfolio.

React.memo is a higher-order component that skips re-rendering a child if props are shallowly equal to last render. It helps when the parent re-renders often but the child is expensive and props are stable. Pair with useCallback/useMemo for object/function props.

const Chart = React.memo(function Chart({ data }) {
  return <ExpensiveVisualization data={data} />;
});

• memo vs useMemo?
• Custom comparison function?
• Default shallow compare limitations?

• Memoizing every component
• New object props every render defeating memo
• Optimizing without measuring

If parent state toggled a sidebar but chart data unchanged, memo avoids redundant chart work.

Techniques: keep state local and colocated, avoid unnecessary context updates, virtualize long lists, code-split routes with React.lazy, debounce expensive handlers, use Web Workers for heavy work off main thread, and profile with React DevTools Profiler. React 18 concurrent features help keep UI responsive during updates.

const Admin = React.lazy(() => import("./Admin"));

<Suspense fallback={<Spinner />}>
  <Admin />
</Suspense>

• What is virtualization?
• startTransition?
• Bundle size optimizations?

• Premature optimization
• Huge lists without keys or virtualization
• Storing everything in one context

Mention lazy-loading an admin panel or heavy chart library in your project.

<StrictMode> is a development helper that activates additional checks and warnings (deprecated APIs, unexpected side effects). In React 18 Strict Mode, certain functions including effects may run twice in development to surface impure side effects. It does not affect production builds.

import { StrictMode } from "react";

createRoot(document.getElementById("root")).render(
  <StrictMode>
    <App />
  </StrictMode>
);

• Why double useEffect in dev?
• Does StrictMode render twice in production?
• Finding StrictMode bugs?

• Removing StrictMode instead of fixing non-idempotent effects
• Assuming production double-fetch
• Ignoring StrictMode warnings

If fetch ran twice in dev only, explain Strict Mode and adding abort/cleanup.

Fragments let you group multiple children without adding a wrapper DOM element. Syntax: <></> or <Fragment key={...}>. Useful for table rows, lists, or layout where an extra div breaks CSS or semantics.

return (
  <>
    <h1>Title</h1>
    <p>Paragraph</p>
  </>
);

• Fragment with key in lists?
• Fragment vs div?
• Short syntax limitations?

• Wrapping everything in unnecessary divs
• Using short syntax when key needed
• Fragment in wrong place breaking flex layout

Replacing wrapper divs in a card component keeps CSS grid/flex predictable.

Portals render children into a different DOM node (often document.body) while keeping the same React tree and event bubbling. createPortal(child, domNode) is used for modals, dropdowns, and tooltips.

import { createPortal } from "react-dom";

function Modal({ open, children }) {
  if (!open) return null;
  return createPortal(
    <div className="modal-backdrop">{children}</div>,
    document.getElementById("modal-root")
  );
}

• Do portal events bubble through React tree?
• SSR with portals?
• Focus trap in modals?

• Rendering modals inline under overflow: hidden parent
• Forgetting accessibility (focus, aria)
• Multiple portals without container

Your project’s modal likely should portal to body — good architecture detail.

React wraps native browser events in SyntheticEvent for cross-browser consistency and pooling (legacy). Handlers receive synthetic events; call event.preventDefault() as usual. React 17+ attaches listeners to the root — not per element — for performance.

function Form() {
  function handleSubmit(e) {
    e.preventDefault();
    // submit logic
  }
  return <form onSubmit={handleSubmit}>...</form>;
}

• passive events?
• Event delegation in React 17+?
• stopPropagation pitfalls?

• Assuming e.target is always an input
• Reading async pooled event fields (older React)
• Attaching native listeners without cleanup when React could handle it

Login form preventDefault to avoid full page POST is a simple synthetic event win.

Keep state as local as possible (colocation). Lift or use Context when multiple distant components need it. Global libraries (Redux, Zustand) help when many features share complex async state, caching, middleware, or devtools needs. Start simple; add global state when pain is real.

// Local: modal open flag inside ModalTrigger
// Global: authenticated user available across routes

• URL as state?
• Server state vs client state?
• React Query role?

• Redux on day one for every app
• Everything in useState at App root
• Duplicating server data in many places

Argue which state in your project stayed in the page vs a context/store.

Redux stores application state in a single immutable tree. You dispatch actions (plain objects describing what happened) to a reducer (pure function) that returns new state. UI subscribes via useSelector; updates flow one direction. Redux Toolkit simplifies boilerplate today.

// Conceptual flow: UI -> dispatch(action) -> reducer -> new state -> UI
const count = useSelector((s) => s.counter.value);
const dispatch = useDispatch();
<button onClick={() => dispatch(increment())}>{count}</button>

• Redux vs Context?
• What is RTK?
• When is Redux overkill?

• Mutating state in reducers
• Putting non-serializable values in store without reason
• Using Redux for local UI toggles only

Say whether your project used Redux or would reach for Zustand/Context first.

Concurrent rendering lets React prepare multiple versions of the UI, interrupt low-priority updates, and keep the app responsive. Features like startTransition, useDeferredValue, and Suspense integrate with this model. Updates have urgency — typing should beat background list filtering.

const [query, setQuery] = useState("");
const [isPending, startTransition] = useTransition();

function onChange(e) {
  setQuery(e.target.value);
  startTransition(() => setFiltered(heavyFilter(e.target.value)));
}

• Concurrent vs parallel?
• Automatic batching in 18?
• createRoot requirement?

• Claiming concurrent means multi-threaded React everywhere
• Blocking main thread with heavy sync work
• Ignoring createRoot migration from legacy render

Mark search filtering as transition so input stays snappy — ties theory to UX.

Suspense lets components ‘wait’ for something (lazy-loaded code, async data in supported setups) and shows a fallback while waiting. Wrap lazy components or experimental data APIs in <Suspense fallback={...}>. Nested Suspense boundaries allow granular loading UI.

const Settings = React.lazy(() => import("./Settings"));

<Suspense fallback={<p>Loading settings...</p>}>
  <Settings />
</Suspense>

• Suspense for data fetching today?
• Error boundaries + Suspense?
• SSR Suspense?

• One Suspense at root with generic spinner only
• Forgetting lazy import default export
• Treating Suspense as error handling

Route-level lazy loading with a branded skeleton fallback looks polished in demos.

Typical approach: controlled inputs in state or a form library (React Hook Form, Formik), validate on change or submit, prevent default on submit, call API, show errors from server. For large forms, libraries reduce re-renders and boilerplate.

function Signup() {
  const [form, setForm] = useState({ email: "", password: "" });
  const [error, setError] = useState(null);

  async function handleSubmit(e) {
    e.preventDefault();
    setError(null);
    try {
      await api.signup(form);
    } catch (err) {
      setError(err.message);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input value={form.email} onChange={(e) => setForm({ ...form, email: e.target.value })} />
      {error && <p role="alert">{error}</p>}
      <button type="submit">Sign up</button>
    </form>
  );
}

• Client vs server validation?
• Accessible form errors?
• Uncontrolled with React Hook Form?

• No loading/disabled state on submit
• Password in plain state logged accidentally
• Missing htmlFor / labels

Walk through your signup or contact form validation and error display.

Use React Testing Library with Vitest or Jest: render components, query as users do (getByRole, getByLabelText), fire events, assert outcomes. Test behavior not implementation. Mock network with MSW. Avoid testing internal state directly.

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";

test("increments counter", async () => {
  render(<Counter />);
  await userEvent.click(screen.getByRole("button", { name: /increment/i }));
  expect(screen.getByText("1")).toBeInTheDocument();
});

• getBy vs queryBy?
• Testing async fetch?
• Snapshot tests?

• Testing implementation details (state names)
• Using enzyme patterns on hooks code
• No tests for critical flows

One test for your main CTA button or login validation is enough to mention in interviews.

Main phases: mount (constructor, render, componentDidMount), update (render, componentDidUpdate), unmount (componentWillUnmount). getDerivedStateFromProps and shouldComponentUpdate are advanced. componentDidCatch for errors.

class Profile extends React.Component {
  componentDidMount() { this.loadUser(); }
  componentDidUpdate(prev) {
    if (prev.userId !== this.props.userId) this.loadUser();
  }
  componentWillUnmount() { this.cancel(); }
}

• Deprecated UNSAFE methods?
• PureComponent?
• Lifecycle in Strict Mode?

• Using componentWillMount for data (deprecated)
• Not canceling async in unmount
• Confusing render with side effects

If you read old tutorials, show you can translate lifecycle to useEffect.

componentDidMount + componentWillUnmount → useEffect(fn, []) with cleanup. componentDidUpdate for specific props → useEffect(fn, [dep]). There is no exact getDerivedStateFromProps hook — derive during render or adjust state carefully in effect. shouldComponentUpdate → React.memo or useMemo.

useEffect(() => {
  load(userId);
  return () => cancel();
}, [userId]);

• Why not one effect emulating all lifecycles?
• useLayoutEffect mapping?
• Infinite loop in effect updates?

• Single effect with empty deps that uses all props (stale data)
• Missing cleanup mapping from unmount
• Running side effects during render

Explain how you refetched when route param changed using [id] dependency.

children is the content nested between opening and closing tags of a component. It can be text, elements, or render functions. Layout components (Card, Modal, Page) often use children for flexible composition.

function Card({ title, children }) {
  return (
    <section className="card">
      <h2>{title}</h2>
      <div className="card-body">{children}</div>
    </section>
  );
}

<Card title="Stats">{statsContent}</Card>

• children as function?
• React.Children utilities?
• children vs slots?

• Overusing render props when children suffice
• Not typing children in TypeScript
• Passing children and duplicate content props

Your layout wrapper likely wraps page content via children.

A component receives a function prop (often render or children) that returns JSX, sharing logic/state with the caller. The parent handles behavior; the caller decides UI. Largely replaced by custom hooks but still valid.

function MouseTracker({ render }) {
  const [pos, setPos] = useState({ x: 0, y: 0 });
  useEffect(() => {
    const move = (e) => setPos({ x: e.clientX, y: e.clientY });
    window.addEventListener("mousemove", move);
    return () => window.removeEventListener("mousemove", move);
  }, []);
  return render(pos);
}

• Render props vs hooks?
• Performance of render props?
• children as function naming?

• Deep nesting callback hell
• Not memoizing render prop functions
• Using pattern when a custom hook is clearer

Note you would refactor shared fetch logic to useFetch today instead of render props.

Compound components work together implicitly — often via Context — sharing state while letting the consumer arrange subparts (Tabs, Tabs.List, Tabs.Panel). Users compose markup instead of passing ten configuration props.

// Consumer API sketch
<Tabs defaultValue="profile">
  <Tabs.List>
    <Tabs.Trigger value="profile">Profile</Tabs.Trigger>
  </Tabs.List>
  <Tabs.Panel value="profile">...</Tabs.Panel>
</Tabs>

• Context in compound components?
• Radix/shadcn examples?
• vs single component with props?

• Leaking internal context
• Breaking composition with required order docs missing
• Over-engineering simple UI

If you used a UI library with Tab parts, describe that API as compound components.

Code splitting breaks the JS bundle into chunks loaded on demand. React.lazy accepts a dynamic import() and returns a component. Wrap with Suspense for fallback UI. Route-based splitting is the most common win.

const Dashboard = React.lazy(() => import("./pages/Dashboard"));

<Route path="/dashboard" element={
  <Suspense fallback={<PageSkeleton />}>
    <Dashboard />
  </Suspense>
} />

• Vite/Webpack dynamic import?
• Preloading routes?
• lazy + named exports?

• Lazy loading everything causing waterfall without planning
• Missing Suspense boundary
• Importing heavy lib in main bundle unnecessarily

Split admin or chart routes in your app to shrink initial load for interviewers.

Server-Side Rendering generates HTML on the server per request (or at build time for SSG), sends markup to the client, then React hydrates — attaching event listeners and making the page interactive. Benefits: faster first paint, SEO for content pages. Frameworks like Next.js handle routing and data loading patterns.

// Conceptual: server renders <App /> to HTML string; client hydrateRoot(container, <App />)

• SSR vs CSR?
• Hydration mismatch?
• RSC overview?

• Using browser APIs during SSR without guards
• Hydration errors from random IDs
• Claiming all React apps need SSR

If you used Next.js, explain one page that benefits from server render (marketing, blog).

Define handlers in the component (arrow functions or useCallback when needed). Pass reference to JSX: onClick={handleClick} not onClick={handleClick()} unless calling immediately. For lists, pass stable handlers or inline with id parameter. Debounce expensive handlers. Use form onSubmit for enter key behavior.

function ItemList({ items, onDelete }) {
  return items.map((item) => (
    <button key={item.id} onClick={() => onDelete(item.id)}>
      Delete {item.name}
    </button>
  ));
}

• Synthetic events and async?
• passing arguments to handlers?
• Document-level listeners in useEffect?

• Invoking handler in JSX causing instant run
• Creating new function each render when it breaks memo children
• forgetting preventDefault on forms

Delete button on a list item should call parent with id — classic pattern.

forwardRef lets a parent pass a ref to a child’s inner DOM node or imperative handle. Combine with useImperativeHandle to expose a limited API.

const FancyInput = forwardRef(function FancyInput(props, ref) {
  return <input ref={ref} className="fancy" {...props} />;
});

const ref = useRef();
<FancyInput ref={ref} />;
ref.current?.focus();

• forwardRef in TypeScript?
• useImperativeHandle?
• Refs on function components without forwardRef?

• Forwarding refs unnecessarily on every component
• Breaking ref by wrapping in div without merge
• Exposing entire DOM when only focus() needed

Design system input that parent focuses on validation error uses forwardRef.

Bad keys (random or index on reorderable lists) force React to remount items, losing internal state and hurting performance. Stable keys let React reuse instances and update in place. For dynamic lists, key on identity, not position.

// Bad after sort: index keys shuffle identity
// Good: key={item.id} stable across reorder

• Reconciliation cost?
• Animating list reorder?
• key on component vs element?

• Math.random() keys
• Index keys on filtered sorted tables
• Changing key to reset without understanding remount

After fixing todo keys, explain smoother edits and preserved input focus.

Examples: mutating state, massive components, useEffect for everything, copying props to state unnecessarily, index keys on dynamic lists, overusing Context/global state, fetching in render, ignoring dependency arrays, prop drilling when composition works, and premature memoization without profiling.

// Anti-pattern: derived state sync
const [fullName, setFullName] = useState("");
useEffect(() => {
  setFullName(`${first} ${last}`);
}, [first, last]); // just compute fullName in render

• God components?
• Boolean prop explosion?
• useEffect to respond to props?

• Fighting React with imperative DOM hacks
• Not lifting or colocating state thoughtfully
• Disabling lint rules globally

Pick one mistake you fixed in a project — interviewers prefer honest learning stories.

Only call hooks at the top level of React functions (components or custom hooks) — not in loops, conditions, or nested functions. Only call hooks from React function components or custom hooks. ESLint eslint-plugin-react-hooks enforces this.

// Wrong
if (loggedIn) {
  const [x, setX] = useState(0); // breaks rules
}

• Why do rules exist?
• Hooks in class components?
• Conditional hooks workaround?

• Conditional useState
• Calling hooks from regular utilities
• Custom hooks not named with use

Explain you extract conditional logic into child components so hooks stay unconditional.

React 18 batches multiple state updates from the same event into one re-render, including updates inside promises, timeouts, and native handlers (not only React events). This reduces redundant renders. flushSync forces synchronous flush when needed.

function handleClick() {
  setA(1);
  setB(2);
  // React 18: typically one re-render
}

• React 17 batching limits?
• flushSync use cases?
• Batching in async tests?

• Expecting immediate DOM read after setState in same function
• Overusing flushSync
• Confusing batching with concurrent features

Multiple field updates on one submit batching is why you did not see flicker.

A HOC is a function that takes a component and returns a new component with added props or behavior (auth, logging). Prefer hooks or composition today, but recognize HOCs in older code.

function withAuth(Wrapped) {
  return function AuthComponent(props) {
    const user = useAuth();
    if (!user) return <Navigate to="/login" />;
    return <Wrapped {...props} user={user} />;
  };
}

• HOC vs custom hook?
• Display name debugging?
• Multiple HOC wrapper hell?

• Wrapping HOCs without forwarding refs
• Using HOC for every tiny concern
• Not knowing modern hook alternative

If you see withAuth(Dashboard) in a codebase, explain what it injects.

useId generates stable unique IDs across server and client, useful for linking <label htmlFor> and id on inputs or aria attributes. IDs are not for list keys.

function Field({ label }) {
  const id = useId();
  return (
    <>
      <label htmlFor={id}>{label}</label>
      <input id={id} />
    </>
  );
}

• useId vs increment counter?
• SSR id mismatch?
• useId for keys?

• Using useId for list keys
• Hard-coded duplicate ids
• Skipping labels in forms

Accessible forms in your project should mention label/input association.

Data flows down via props; events flow up via callbacks. Parents own state; children request changes through functions passed as props. This predictability makes debugging easier than two-way binding spaghetti.

function Parent() {
  const [value, setValue] = useState("");
  return <Child value={value} onChange={setValue} />;
}

• Two-way binding in React?
• Unidirectional vs Flux?
• Props drilling limits?

• Child mutating parent state without callback
• Syncing two states for same data
• Global event bus instead of React patterns

Describe how a child search bar updated parent list via onSearch callback.

When mapping to multiple sibling elements, you may need <Fragment key={id}> because short syntax <> does not accept keys. Keys must be on the outermost element in the map.

{items.map((item) => (
  <Fragment key={item.id}>
    <dt>{item.term}</dt>
    <dd>{item.def}</dd>
  </Fragment>
))}

• dl/dt/dd grouping?
• key on first child only?
• React 19 changes?

• Key on inner element instead of fragment wrapper
• Using <> in map without key
• Duplicate keys across list

Glossary or FAQ list with term+definition pairs is a Fragment key example.

Split contexts by concern (theme vs user), memoize provider value with useMemo, avoid putting rapidly changing values in wide providers, and consume context low in the tree. Sometimes pass selectors via libraries (use-context-selector) or move fast state local.

const value = useMemo(() => ({ user, logout }), [user, logout]);
return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>;

• Context vs Zustand?
• React 19 context as provider?
• Measuring re-renders?

• New object/function in Provider every render
• Single context for entire store
• Not splitting read/write contexts

If theme toggle re-rendered entire app, explain splitting ThemeContext from AuthContext.

useLayoutEffect fires synchronously after DOM mutations but before the browser paints. Use when you must measure layout or mutate DOM before user sees flicker (tooltips position, scroll sync). Default to useEffect; reach for layout effect when visual glitch proves it.

useLayoutEffect(() => {
  const height = ref.current.getBoundingClientRect().height;
  setTooltipTop(height);
}, [open]);

• useLayoutEffect on server?
• Performance cost?
• ResizeObserver alternative?

• Using useLayoutEffect for all data fetching
• Running on server without guard
• Layout effect causing jank if work is heavy

Mention only if you fixed a flash of wrong tooltip position — otherwise say you would default to useEffect.

Hydration is when client-side React attaches to server-rendered HTML, wiring event handlers and reconciling the tree. Mismatches between server HTML and client first render cause hydration warnings/errors (e.g. random dates, invalid nesting).

// Server and client must render same initial markup for interactive islands

• hydrateRoot vs render?
• Suppressing hydration warning?
• Streaming HTML?

• Date.now() in initial render
• Browser-only APIs in SSR render
• Different data on server vs client without sync

If you saw hydration errors in Next.js, explain fixing typeof window guards or consistent data.

React recommends composing components via props, children, and hooks rather than subclassing components for reuse. Specialization happens by nesting components and passing configuration, not extending base classes.

function Dialog({ title, children, footer }) {
  return (
    <div className="dialog">
      <header>{title}</header>
      <main>{children}</main>
      <footer>{footer}</footer>
    </div>
  );
}

• Inheritance in React ever?
• Mixin history?
• Hooks replacing mixins?

• Deep inheritance hierarchies
• Copy-paste instead of small composable pieces
• Not using children for layout

Prefer composing PageHeader + PageBody over one mega Page with twenty props.

useImperativeHandle(ref, createHandle, deps) customizes the instance value exposed when parent uses ref on your component. Use sparingly for focus, scroll, or media play — keep React declarative by default.

const Video = forwardRef(function Video(props, ref) {
  const videoRef = useRef();
  useImperativeHandle(ref, () => ({
    play: () => videoRef.current.play(),
  }), []);
  return <video ref={videoRef} {...props} />;
});

• When not to use imperative handle?
• TypeScript typing ref handle?
• Refs vs state?

• Exposing entire internal API
• Overusing imperative patterns
• Missing forwardRef

Parent calling ref.current.play() on a wrapped video component is the textbook case.

In function components, use ES6 default parameters (function Btn({ size = 'md' })). Class components historically used static defaultProps. Default parameters are simpler and work well with TypeScript.

function Button({ variant = "primary", children }) {
  return <button className={`btn-${variant}`}>{children}</button>;
}

• defaultProps deprecation note?
• null vs undefined defaults?
• Default in destructuring vs defaultProps?

• Mutating default object/array literals shared across calls
• Relying on defaultProps in new function components
• Undefined vs null breaking defaults

Your design system button variants likely use default parameter for variant.

Keep stable key on item id, control filter state in parent or memoized derived list, avoid remounting the whole list when possible, and lift input state so filtering does not reset unrelated UI. For editable rows, key by id not index.

const visible = useMemo(
  () => todos.filter((t) => t.text.includes(query)),
  [todos, query]
);
return visible.map((t) => <TodoRow key={t.id} todo={t} />);

• Controlled filter input?
• Virtualization?
• Resetting state on filter change intentionally?

• Index keys while deleting filtered items
• Recreating list component with new key on each keystroke
• Filtering in render without memo on huge lists

Searchable todo list in your project — explain keys and filtered array.

PropTypes validate props at runtime in development (legacy in many TS projects). TypeScript checks types at compile time and is the modern default for new apps. Both encourage clear component contracts.

interface ButtonProps {
  label: string;
  onClick?: () => void;
}
function Button({ label, onClick }: ButtonProps) {
  return <button onClick={onClick}>{label}</button>;
}

• Runtime validation still needed?
• defaultProps with TS?
• children typing?

• Using any everywhere
• Not typing public component props
• PropTypes on every file in TS project redundantly

Mention TypeScript interfaces for your main components if your repo uses TS.

A component is a function or class (e.g. Button). An element is a plain object describing what to render (<Button /> or React.createElement(Button)). Elements are immutable descriptions; components are the recipes that produce elements.

const element = <Button primary />; // element object
function Button(props) { return <button className={props.primary ? 'p' : ''} />; }

• Re-render creates new elements?
• Element type field?
• Host vs composite components?

• Confusing component definition with instance
• Thinking JSX creates DOM nodes immediately
• Not knowing elements are lightweight

Helps explain why you can store JSX in variables and return conditionally.

useSyncExternalStore lets React subscribe to external stores (browser APIs, Redux, Zustand internals) safely with concurrent rendering, avoiding tearing. Library authors use it; app devs rarely touch it directly unless integrating custom stores.

const width = useSyncExternalStore(subscribe, () => window.innerWidth, () => 0);

• Tearing in concurrent mode?
• Redux 8+ and this hook?
• Server snapshot arg?

• Rolling custom global store without subscription pattern
• Reading window in render without subscribe
• Ignoring server snapshot for SSR

Optional deep answer if asked about Zustand/Redux working with React 18.