Top 62 React Interview Questions and Answers (2026)

React is a JavaScript library for building user interfaces out of components: functions that take inputs and return a description of the UI. It's declarative, so you say what the UI should look like for a given state and React figures out the DOM changes.

The problem it solves is keeping a complex UI in sync with changing data. Instead of hand-writing DOM updates, you update state and React re-renders the affected parts, which makes large interactive apps far easier to reason about.

JSX is a syntax extension that lets you write markup-like code inside JavaScript. It looks like HTML but it's really syntactic sugar for function calls that create element objects.

Browsers don't understand JSX. A compiler like Babel or the framework's build step transforms each JSX tag into a React.createElement call, or the newer automatic jsx runtime, before the code ships.

Return a single root element (or a Fragment), close every tag, and use camelCase for attributes like className and onClick. Embed JavaScript expressions with curly braces, but only expressions, not statements.

You can't put an if statement inside JSX, but you can use a ternary or logical && for conditional rendering. A Fragment (<>...</>) groups siblings without adding a wrapper node.

A component is a reusable piece of UI written as a function that returns JSX. Props are the inputs a parent passes down to a component, received as a single object argument.

Props are read-only from the child's point of view: a component must never modify its own props. This one-way data flow, parent to child, is what makes React apps predictable.

Props are passed in from a parent and are read-only to the component that receives them. State is data a component owns and manages internally, updated through a setter that triggers a re-render.

The rule of thumb: if a value is passed from above and never changed here, it's a prop; if the component changes it over time in response to interaction, it's state.

useState returns a pair: the current state value and a setter function. Calling the setter schedules a re-render with the new value. The argument to useState is the initial value, used only on the first render.

React remembers state between renders by call order, which is why you call useState at the top level and never inside conditions. Each call to the component reads the latest stored value.

When the new state depends on the previous state, pass an updater function: setCount(c => c + 1). React guarantees it receives the latest value, which matters because state updates can batch and the closed-over variable may be stale.

If you call setCount(count + 1) three times in a row with a plain value, they all read the same count and you get one increment. The functional form gives three.

React decides whether to re-render by comparing the previous and next state references. If you mutate an object or array in place, the reference doesn't change, so React may skip the update entirely.

Always create a new object or array instead: spread the old one and change what you need. This is why you see {...state, key: value} and [...list, item] everywhere in React code.

You pass a function to a camelCased event prop like onClick or onChange. React wraps native events in a synthetic event for cross-browser consistency, and you get the event object as the handler's argument.

Pass the function itself, not its call: onClick={handleClick}, not onClick={handleClick()}. Use an arrow function when you need to pass arguments: onClick={() => remove(id)}.

Because JSX is JavaScript, you use ordinary expressions: a ternary for either/or, logical && to render something or nothing, or an early return for whole-component branches.

One trap: && with a number like 0 renders the 0 on screen, because 0 is falsy but still a valid React child. Guard with a boolean (count > 0 && ...) instead of a bare count.

You map an array to elements: items.map(item => <Row key={item.id} ... />). React needs a key on each element so it can match items to their previous instances across renders and update only what changed.

Keys must be stable and unique among siblings. Using the array index as a key breaks when the list reorders or items are inserted, because the index no longer identifies the same item, which corrupts component state.

In a controlled component, form input values live in React state and every change flows through onChange, so React is the single source of truth. In an uncontrolled component, the DOM holds the value and you read it with a ref when you need it.

Controlled inputs are the default recommendation because they make validation, conditional disabling, and derived UI straightforward. Uncontrolled inputs are handy for simple forms or integrating non-React widgets.

A plain variable declared in a component resets to its initial value on every render, and changing it doesn't tell React to re-render. State survives across renders and, when updated through the setter, schedules a new render.

So the two jobs state does that a variable can't: it persists between renders, and it triggers the UI to update. If a value needs neither, a plain constant is fine and cheaper.

Hooks are functions that let function components use React features that used to require classes: state (useState), side effects (useEffect), context (useContext), refs (useRef), and more. Their names all 'use' comes first.

They arrived in React 16.8 and became the standard way to write components. Before hooks, stateful logic lived in class lifecycle methods; hooks let you organize that logic by concern and share it through custom hooks instead.

A Fragment lets you return multiple elements from a component without wrapping them in an extra DOM node like a div. You write it as <>...</> or <React.Fragment>...</React.Fragment>.

It matters for valid HTML (a table row can't be wrapped in a div) and for keeping the DOM flat, which avoids styling and layout headaches from unnecessary wrappers.

Data in React flows in one direction: down the component tree, from parent to child through props. A child can't reach up and change its parent's data directly; it can only call a callback the parent passed down.

This makes apps predictable: to find why something on screen has a value, you trace props up toward where the state lives. When a child needs to change shared data, the parent owns the state and hands down both the value and a setter.

With function components, you set defaults right in the destructuring of the parameter: function Button({ variant = 'primary' }). If the prop is undefined, the default applies.

This replaced the older defaultProps static on function components, which React is phasing out. Destructuring defaults are the current standard and read clearly.

children is a special prop holding whatever you nest between a component's opening and closing tags. It lets you build wrapper and layout components that don't know their contents in advance.

This is the basis of composition in React: a Card or Modal renders {children} in the right place, and callers pass any JSX they want inside.

A single-page application loads one HTML shell and then updates the view with JavaScript as the user moves around, instead of requesting a fresh page from the server each time. Navigation feels instant because only data changes, not the whole document.

React renders and re-renders those views on the client. A router like React Router maps URLs to components so the address bar and back button still work, all without full page reloads.

The virtual DOM is a lightweight in-memory description of your UI: plain JavaScript objects that mirror the element tree. When state changes, React builds a new virtual tree and compares it to the previous one.

From that comparison React computes the minimal set of real DOM changes and applies just those. You write code as if re-rendering everything, and React makes the actual updates cheap.

Each component usually lives in its own file and is exported, then imported where it's used. A file can have one default export and any number of named exports.

Keeping one component per file makes the tree easy to read and reuse. The import path and the export style (default vs named) just have to match on both ends.

StrictMode is a development-only wrapper that helps you catch problems early. It intentionally double-invokes component render functions and effect setup so impure logic and missing cleanup show up loudly.

It renders nothing itself and has zero effect in production builds. Seeing an effect or a console log fire twice in development is usually StrictMode doing its job, not a bug.

Only when the list is static: it never reorders, items are never inserted or removed from the middle, and the items have no local state or uncontrolled inputs. In that narrow case the index is stable enough.

Any list that can change order or size needs a stable ID from the data. The safe default is to always prefer a real ID and treat index keys as a smell you can defend.

Common options: plain CSS or CSS Modules imported into the component, utility classes like Tailwind via className, CSS-in-JS libraries, or the inline style prop which takes a camelCased object.

The inline style prop is fine for a handful of dynamic values but shouldn't replace a stylesheet. Note style takes an object ({{ color: 'red' }}) with camelCased keys, not a string.

useEffect runs a side effect after the render is committed to the screen. The dependency array controls when it re-runs: with a list of values, it re-runs whenever one changed; with an empty array, it runs once after mount; with no array at all, it runs after every render.

If the effect returns a function, that's the cleanup. React runs it before the next effect and on unmount, which is where you remove event listeners, clear timers, or cancel subscriptions.

The big ones: omitting dependencies the effect actually uses (leading to stale values), causing an infinite loop by setting state that's also a dependency without a guard, forgetting cleanup so listeners and timers leak, and putting logic in an effect that could just be computed during render.

A useful reframe interviewers like: many effects shouldn't exist. If you're syncing state derived from props, compute it during render instead. Effects are for synchronizing with systems outside React, network, DOM, subscriptions.

useRef returns a mutable object with a .current property that persists across renders and, notably, changing it does not trigger a re-render. First use: hold a reference to a DOM node so you can focus it, measure it, or scroll it.

Second use: store a mutable value that outlives renders but shouldn't cause re-renders, like a timer ID, a previous value, or a mutable counter. If changing a value should update the UI, that's state, not a ref.

useMemo memoizes a computed value: it re-runs the expensive function only when a dependency changes, otherwise it returns the cached result. useCallback memoizes a function reference so it stays identical across renders while its dependencies are unchanged.

They're the same idea applied to different things. useCallback(fn, deps) is literally useMemo(() => fn, deps). You reach for useCallback when a stable function reference matters, for example passing a callback to a memoized child.

When you've measured a real cost: a component that renders often and does expensive work, or a large list where an unstable prop keeps breaking a memoized child. React.memo, useMemo, and useCallback all trade a little memory and complexity for skipped work.

They're not free and they're not automatic wins. Adding them everywhere adds comparison overhead and noise. Profile first with the React DevTools Profiler, then memoize the hot path.

Two rules: only call hooks at the top level of a component or another hook, never inside conditions, loops, or nested functions; and only call them from React function components or custom hooks, not regular functions.

The reason is how React tracks hook state: it relies on the call order being identical on every render to match each useState or useEffect to its stored slot. A conditional hook shifts that order and corrupts the mapping, which is why the linter enforces this.

A custom hook is a function whose name starts with 'use' and which calls other hooks to package reusable stateful logic. It lets you share behavior, like fetching data or reading window size, without repeating the same useState and useEffect wiring.

It shares logic, not state: each component that calls the hook gets its own independent state. Write one when the same hook combination shows up in two or more components.

Both run after render, but at different moments. useEffect runs asynchronously after the browser has painted, so it doesn't block the visual update. useLayoutEffect runs synchronously after the DOM is updated but before paint, so it can read layout and change it without the user seeing a flicker.

The default is useEffect. Reach for useLayoutEffect only when you must measure the DOM (size, scroll position) and adjust it before the frame is shown, for example positioning a tooltip. Overusing it blocks painting and hurts perceived speed.

Context lets a parent provide a value that any descendant can read, without passing props through every level in between. It solves prop drilling, threading a value through components that don't need it just to reach one that does.

You create a context, wrap a subtree in its Provider with a value, and read it with useContext. It fits truly global-ish data: theme, current user, locale. It's not a general state manager, and every consumer re-renders when the value changes.

When two sibling components need to share or stay in sync with the same data, you move that state up to their closest common parent and pass it down as props, along with a setter callback. The parent becomes the single source of truth.

This keeps data flowing one way: state lives in one place, children receive it and report changes upward through callbacks. It's the standard fix for 'these two components need the same value'.

React apps reuse code by composing components, passing children and props, rather than by extending base component classes. A generic Dialog takes children and renders them; a specialized dialog just renders a Dialog with specific content inside.

The React team explicitly recommends composition, and in practice inheritance almost never comes up. Props, children, and custom hooks cover the reuse cases inheritance would.

React.memo wraps a component so that if its props are shallowly equal to the previous render, React skips re-rendering it and reuses the last output. It's the component-level equivalent of caching a render.

It helps when a component re-renders often with the same props and its render is non-trivial. It backfires if props are new objects or functions every render (the shallow check always fails), which is where useCallback and useMemo on the parent come in.

When state changes, React renders a new element tree and diffs it against the previous one. Rather than a costly full tree comparison, it uses heuristics: elements of different types are replaced wholesale, and children are matched by key.

That's why key matters: it tells React which child in the new list corresponds to which in the old list, so it can move and reuse DOM nodes instead of recreating them. The output of reconciliation is the minimal set of real DOM operations.

Three triggers: its own state changed (a setter was called), a context it consumes changed, or its parent re-rendered. That last one surprises people: a parent re-render re-renders all its children by default, even if their props didn't change.

Note that a re-render doesn't always mean DOM changes. React re-runs the component function and diffs the result; if the output is identical, no DOM work happens. That's why 'extra renders' aren't automatically a performance problem.

useReducer manages state through a reducer function that takes the current state and an action and returns the next state. You dispatch actions instead of calling setters directly.

Prefer it over useState when state is complex or the next value depends on the previous in non-trivial ways, when several values update together, or when you want update logic centralized and testable outside the component. Simple independent values stay with useState.

The classic pattern is a useEffect that fetches on mount and stores the result in state, tracking loading and error alongside it. You add cleanup to ignore a response if the component unmounted or the request is stale.

In real apps, most teams use a data library like React Query or SWR, or a framework's built-in loader, because they handle caching, deduping, retries, and stale-while-revalidate that hand-rolled effects miss. Mention that; it indicates production experience.

An error boundary is a component that catches JavaScript errors thrown during rendering in its child tree, logs them, and shows a fallback UI instead of crashing the whole app. It uses the lifecycle methods getDerivedStateFromError and componentDidCatch.

Notably, error boundaries are still written as class components, one of the few places classes remain necessary. They don't catch errors in event handlers, async code, or the boundary itself; those you handle with try/catch.

createPortal renders children into a different part of the DOM tree, outside the parent component's DOM node, while keeping them in the React tree for props, context, and events. Event bubbling still follows the React tree, not the DOM position.

The typical use is overlays: modals, tooltips, dropdowns that must escape a parent's overflow: hidden or z-index stacking context but still behave like children of the component that owns them.

Keep the form values in a single state object and update it immutably on change, using the input's name to know which field to set. One handler can serve every input this way.

On submit, call preventDefault to stop the browser's default navigation, then read from state. For anything beyond a few fields, teams reach for a form library like React Hook Form to handle validation and reduce re-renders.

Prop drilling is passing a prop down through many intermediate components that don't use it, just to reach a deep child. It clutters components with props they only forward.

Fixes, in order of reach: restructure with composition so the data-owner renders the consumer directly, use Context for genuinely shared values like theme or user, or adopt a state library for large cross-cutting state. Reach for the lightest fix that works.

React ties a component's identity to its position and key. Give a component a new key and React unmounts the old instance and mounts a fresh one, resetting all its internal state. Same key, same instance, state preserved.

This is a deliberate technique: keying a form on the selected record ID resets the form cleanly when the user switches records, no manual state-clearing effect needed.

React works in two phases. In the render phase it calls your component functions to compute the new element tree and reconciles it against the previous one; this phase is pure and can be paused or discarded. In the commit phase it applies the computed changes to the real DOM and then runs layout effects and effects.

Understanding the split explains real behavior: render must be side-effect-free (that's why StrictMode double-invokes it), and effects run in commit, after paint, which is why you can't read updated layout during render.

Concurrent rendering lets React interrupt, pause, and resume the render phase instead of blocking the main thread until a render finishes. It can prepare a new UI in the background and keep the current one responsive, then commit when ready.

You mostly use it through features built on it: useTransition to mark non-urgent updates so typing stays snappy, useDeferredValue to defer expensive derived UI, and Suspense for coordinated loading. The point is prioritizing urgent updates over expensive ones.

Suspense lets a component 'wait' for something (code, data) before rendering, showing a declared fallback in the meantime. You wrap part of the tree in <Suspense fallback={...}> and any suspending child triggers the fallback until it's ready.

It started with React.lazy for code-splitting and now underpins data loading in frameworks and server components. The value is declarative loading states: no manual isLoading flags scattered through the tree.

Server Components render on the server and send a serialized description of the UI to the client, never shipping their own JavaScript to the browser. They can read the database or filesystem directly and reduce bundle size, since their code stays on the server.

They interleave with Client Components, which run in the browser and hold interactivity and state (marked with 'use client'). The mental model: server components for data and structure, client components for anything with hooks, events, or browser APIs. Frameworks like Next.js drive most real usage today.

the lightest option and escalate only when you feel the pain comes first. Local useState for component-owned state; lift it to the nearest common parent when siblings share it; Context for a few genuinely global values like theme or auth; a dedicated library only for large, frequently-updated, cross-cutting state.

A key distinction seniors draw: server state (data from an API) and client state (UI state) have different needs. Server state wants caching and revalidation, which is React Query or SWR territory, not a global store. Conflating the two is the common mistake.

Every memoization adds cost: the comparison of dependencies, the memory for cached values, and the cognitive load of dependency arrays that can go stale or wrong. Applied without a measured need, it often makes things slower and buggier, not faster.

The discipline is to profile with the DevTools Profiler, find components that render often and expensively, and memoize those specifically. It's also worth mentioning that the React team's Compiler aims to automate much of this, which reframes the whole topic.

A good custom hook has a focused responsibility, a clear return shape (tuple for two values, object for more), stable references where callers depend on them, and complete effect cleanup. It reads like a small API, not a dumping ground.

Pitfalls: returning new object or function references every render (which breaks consumers' memoization unless you useCallback/useMemo inside), hidden effects that surprise callers, and stale-closure bugs from missing dependencies. Test hooks in isolation to catch these.

Virtualize it: render only the rows in and near the viewport with a windowing library (react-window, TanStack Virtual) instead of thousands of DOM nodes. That alone usually removes the jank because DOM size, not React, is the bottleneck.

Then supporting fixes: stable keys, memoize row components so unrelated state changes don't re-render every row, memoize the callbacks passed to rows, and move expensive derived data out of render. Measure with the Profiler before and after.

React Testing Library renders components and queries them the way a user would: by role, label, and visible text, then simulates interaction and asserts on what the user sees. It deliberately discourages reaching into implementation details like state or instance internals.

The philosophy is 'test behavior, not implementation', so tests survive refactors. Pair it with a runner like Jest or Vitest, query by accessible role, use userEvent for interactions, and mock network boundaries with something like MSW.

In development, StrictMode intentionally runs component bodies twice and mounts, unmounts, then remounts components once, running each effect an extra setup/cleanup cycle. It's not random: it forces impure renders and effects that lack proper cleanup to fail visibly.

Bugs it surfaces: mutating props or module-level state during render, effects that subscribe without unsubscribing, and setup that assumes it runs exactly once. Code that's correct under React's rules survives the double invocation unchanged, which is the point.

To let a parent's ref reach a child's DOM node, forward it. In current React you can accept ref as a normal prop; older code uses forwardRef. When you need to expose specific imperative methods rather than the raw node, use useImperativeHandle to define a small controlled surface.

The caution to voice: imperative handles are an escape hatch. Prefer props and state; reach for this only for genuinely imperative actions like focus, scroll, or media playback that don't fit the declarative model.

Higher-order components (a function that takes a component and returns a wrapped one) and render props (a prop that's a function returning UI) were the pre-hooks ways to share stateful logic. Both work but add wrapper nesting and can obscure where props come from.

Hooks replaced most of these cases: a custom hook shares logic without adding to the tree or causing wrapper hell. You still see HOCs in older libraries and for cross-cutting concerns like connecting to a store, so recognizing them matters, but new code reaches for hooks.

React groups multiple state updates that happen in the same event into a single re-render, so several setters fire one render, not one each. Since React 18, automatic batching extends this to updates inside promises, timeouts, and native event handlers too, not just React events.

This is why functional updaters matter for dependent updates, and why you occasionally reach for flushSync to force a synchronous update when you must read the DOM immediately after. Knowing 18 broadened batching beyond React events is the detail seniors are expected to have.

Every consumer re-renders when a context value changes, and a fresh object literal as the value re-renders consumers on every provider render. First fix: memoize the value with useMemo so its reference is stable.

Structural fixes: split one big context into several narrow ones so a change to one slice doesn't re-render consumers of another, separate rarely-changing from frequently-changing values, or move to a store that supports selector-based subscriptions (Zustand, Redux) when the state is large and hot.

Split the bundle so users download only the code for the route or feature they're using, not the whole app upfront. React.lazy plus dynamic import() loads a component on demand, wrapped in Suspense for the loading fallback; routers and frameworks do route-level splitting automatically.

The payoff is faster initial load and better Core Web Vitals, since a smaller first bundle improves load and interaction readiness. The judgment is splitting at meaningful boundaries (routes, heavy modals, rarely-used features) rather than over-splitting into many tiny chunks.

Clarify first: server-side or client-side pagination, page size fixed or user-set, and whether the total count is known. Then shape the state: current page, page size, and either the current page's rows (server) or the full dataset sliced in a memo (client). Fetch keyed on page and size with a useEffect or a data hook, tracking loading and error.

Close on the edges the key signal is: disable Previous on page one and Next on the last page, keep controls usable during loading (show a pending state, don't unmount), reset to page one when filters change, and reflect the page in the URL so it's shareable and survives refresh.

The core problem is not firing a request on every keystroke. Keep the input controlled, then debounce the query: wait until the user pauses typing (say 300ms) before searching. A useEffect keyed on the term with a setTimeout, cleared on each change, is the idiomatic debounce; the cleanup cancels the pending call.

Then the race condition interviewers wait for: responses can arrive out of order, so a slow early request can overwrite a fast later one. Guard it with an ignore flag in the effect cleanup or an AbortController. Also handle empty input (skip the call), loading state, and errors.