Technology interview warm-up
React interview questions and answers hub with coding prompts, concept questions, follow-ups, and common mistakes. Practice concise answers first, then expand into Study Plans, guides, and Company Prep.
On this page
Popular clusters
Short answers
React is a JavaScript library for building user interfaces from components. A React app describes what the UI should look like for a given state, and React updates the DOM when that state changes. Routing, server-state caching, and form validation are separate architectural choices rather than built-in React features.
React components are reusable UI units that receive props, hold state when needed, and return JSX. Function components are the standard shape in modern React, while class components still appear in older codebases. A component should keep rendering predictable by treating props as read-only and moving shared behavior into smaller components or hooks.
Review component rendering →JSX is a syntax extension that lets React UI look close to HTML while still being JavaScript. JSX expressions compile to function calls, so values inside braces are evaluated as JavaScript and must follow JavaScript rules. The common edge case is that attributes are React props, so names such as className and htmlFor differ from plain HTML.
Review the JSX transform →Props are read-only values passed from a parent component to a child component. They describe the child UI contract, such as labels, data, callbacks, and configuration. Mutating props breaks ownership and can hide update bugs because the parent still owns the source value.
Review props immutability →State is component-owned data that can change over time and trigger a new render. Use state for values that affect what the user sees, such as form input, selected tabs, loading state, and expanded sections. Values that can be derived directly from props or other state usually should not be stored separately.
Review useState →One-way data flow means data moves down from parent to child through props, while changes move up through callbacks. The parent owns the state transition and passes the updated value back down. This keeps ownership clear, but deeply nested updates may need component composition, Context, or a store.
Review lifting state up →Keys tell React which list item identity should be preserved across renders. Stable keys let React keep row state, focus, and DOM reuse aligned with the right data item. Index keys are risky when items can be inserted, removed, sorted, or filtered because state can move to the wrong row.
Review list keys →A controlled input gets its current value from React state and reports changes through events. An uncontrolled input keeps its current value in the DOM, usually read with a ref when needed. Switching a field between controlled and uncontrolled ownership can create warnings and broken form behavior.
Compare form ownership →Lifting state up means moving state to the closest shared parent that needs to coordinate multiple children. The parent passes the current value down as props and passes callbacks down for child events. It prevents duplicated state, but if the shared parent becomes too broad, rerenders and prop drilling can grow.
Practice state ownership →Hooks are functions that let function components use React features such as state, effects, refs, reducers, memoization, and context. They must run in a consistent order on every render so React can associate each hook call with its stored state. Custom hooks reuse stateful logic, but they do not share state unless they call shared external state.
Review common hooks →Hooks must be called at the top level of a React function component or custom hook. They should not be called inside loops, conditions, nested functions, or ordinary utility functions. Breaking the order makes React read the wrong stored hook state on later renders.
Review Rules of Hooks →useState stores a value that belongs to a component and should trigger rendering when it changes. The setter schedules an update instead of mutating the current value immediately. When the next value depends on the previous value, a functional update avoids stale reads.
Review useState →useEffect synchronizes a component with something outside rendering, such as subscriptions, timers, DOM APIs, analytics, or network state. It runs after React commits the UI, and cleanup runs before the effect is replaced or the component unmounts. Pure derived values usually belong in render instead of in an effect.
Review useEffect →An effect may return a cleanup function that removes the external work created by that effect. Cleanup runs before React reruns the effect with changed dependencies and when the component unmounts. Timers, subscriptions, event listeners, and in-flight async work should have clear cleanup ownership.
Review effect timing →A stale closure happens when a callback keeps reading values from an older render. It often appears in timers, promises, subscriptions, and event handlers that outlive the render that created them. Functional state updates, correct dependencies, refs, or moving logic into the event path can fix the ownership problem.
Debug stale closures →useState stores render-affecting data and schedules a rerender when changed. useRef stores a mutable value that persists across renders without causing a rerender. Refs are useful for DOM nodes, timer IDs, previous values, and imperative handles, but they can hide UI bugs if used as state.
Compare refs and state →useMemo memoizes the result of running a calculation. useCallback memoizes the function reference itself. Both depend on stable dependency arrays, and neither helps if the expensive work is small or the props passed to children are still unstable.
Compare memo hooks →When a Context provider value changes, consumers that read that context can render again. A broad provider with a new object value on every render can fan out updates across a large tree. Splitting providers, stabilizing values, using local state, or choosing an external store can reduce unnecessary work.
Debug Context performance →A component can re-render when its state updates, its parent renders, a consumed context value changes, or an external store subscription notifies it. Rendering does not always mean the DOM changes; React still compares the result before committing updates. Performance debugging should separate render frequency from actual slow commits.
Review rerender causes →State batching means React groups multiple state updates into a single render pass when it can. React 18 broadened automatic batching across more async boundaries. The important edge case is that reading state immediately after calling a setter still reads the value from the current render.
Review batching →Derived state is risky when you store data that can be calculated from props or other state. The duplicated value can drift out of sync and often creates an extra render through an effect. Keep pure derived values in render, and use memoization only when the calculation is expensive enough to matter.
Avoid derived state bugs →Error boundaries catch rendering errors in their child tree and let the app show a fallback UI instead of unmounting everything. They do not catch errors in event handlers, async callbacks, or server-side rendering. Place them around meaningful product regions so a failure is isolated to the smallest useful surface.
Review error boundaries →Portals render children into a DOM node outside the parent DOM hierarchy while keeping the React owner tree intact. They are useful for modals, popovers, tooltips, and overlays that need to escape clipping or stacking contexts. Events still bubble through the React tree, so event handling can differ from the physical DOM position.
Review portals →Render props share behavior by passing a function that returns UI. Higher-order components share behavior by wrapping a component and returning a new component. Hooks replaced many of these patterns, but render props and HOCs still appear in older libraries and can add wrapper or composition complexity.
Compare reuse patterns →StrictMode can intentionally mount, clean up, and remount components in development to reveal unsafe effects. This does not happen the same way in production, but the issue it exposes is real: effects must tolerate setup and cleanup correctly. Duplicate logs or requests usually mean the effect is not idempotent or the cleanup is incomplete.
Review StrictMode effects →Beginner to experienced
Start with React, components, JSX, props, state, one-way data flow, keys, controlled inputs, and lifting state up. These topics make hooks, effects, Context, and rendering behavior easier to reason about later.
Focus on ownership boundaries: effect cleanup, stale closures, Context performance, reconciliation, server/client component boundaries, testing async UI, and profiling before memoizing. These topics expose whether React knowledge holds up in production code.
Rendering internals
The Virtual DOM is a lightweight description of the UI that React creates from components. React compares the new description with the previous one, decides what changed, and commits the necessary host updates. The important detail is that the Virtual DOM is a means to coordinate updates, not a guarantee that every render is cheap.
Review Virtual DOM →The render phase calls components and calculates the next UI tree. The commit phase applies the chosen changes to the host environment and runs layout-related work. Render work can be restarted or discarded, so component render logic must stay pure and side effects belong in effects or event handlers.
Review render behavior →Reconciliation is the process React uses to compare the previous element tree with the next one. It matches elements by type and key, then decides which parts can be reused, updated, moved, or remounted. Incorrect keys or changing component types can reset state because React sees a different identity.
Review reconciliation →React uses heuristics instead of comparing every possible tree transformation. Different element types are treated as different subtrees, and keys tell React which children should keep identity across list changes. Those assumptions make updates practical, but unstable keys or accidental type changes can cause unexpected remounts.
Review diffing →Fiber is React internal architecture for organizing rendering work as units that can be scheduled, paused, resumed, or abandoned. It enables React to prioritize urgent updates differently from non-urgent work. You do not usually program against Fiber directly, but it explains why render logic must be pure and why concurrent rendering can restart work.
Review render internals →React uses keys to decide whether a child in a list is the same child across renders. A stable key preserves component state for the same data item, while a changed key forces React to treat it as a new instance. This is useful for intentional resets, but index keys can accidentally move state to the wrong row.
Review list keys →Fragments group multiple children without adding an extra DOM node. Keyed fragments can preserve identity for a group of siblings during reconciliation. Unkeyed fragments are useful for markup cleanliness, but lists of fragments still need stable keys when identity matters.
Review fragments and reconciliation →useEffect runs after the browser has painted the committed UI. useLayoutEffect runs after DOM mutations but before paint, so it can measure layout and synchronously adjust the UI before the user sees it. Overusing layout effects can block painting, so ordinary subscriptions and async work should stay in useEffect.
Compare effect timing →React 19 + server-first React
Actions are async functions used with transitions or form submissions to manage mutation workflows. React can coordinate pending state, errors, optimistic updates, and final state around the action. The practical benefit is reducing manual loading and error wiring for form-like mutations.
Open the React prep path →useActionState connects an action to state that updates when the action completes. It is useful when a form submit or mutation returns validation errors, success messages, or next state. The hook keeps pending and result handling close to the action, but the mutation contract still needs clear server and client ownership.
Review React 19 actions →useOptimistic lets the UI show an expected result before the server confirms it. It is useful for quick feedback on mutations such as adding comments, toggling likes, or reordering items. The edge case is rollback and ordering: failed or out-of-order responses must not leave the UI in a false state.
Review optimistic updates →useFormStatus reads the pending status of the nearest parent form submission. It lets a submit button or status message react to the form action without passing loading props through every component. It only works inside the form context, so placement matters.
Review form status →use() can read certain resources, such as promises or context, during rendering in supported React environments. When a promise is still pending, the nearest Suspense boundary can show fallback UI. The key requirement is that data ownership and caching are stable, otherwise rendering can repeatedly suspend or restart work.
Review Suspense data flow →Server Components render on the server and can access server-only data without shipping their component code to the browser. Client Components run in the browser and own interactivity, state, effects, and event handlers. Values passed from server to client boundaries must be serializable, and browser-only APIs belong on the client side.
Review server/client boundaries →The App Router encourages colocating data loading with server-rendered route segments and using client boundaries only where interactivity is needed. Caching, revalidation, and streaming behavior become part of the route contract. A good boundary keeps server data on the server while isolating client state to the smallest interactive surface.
Open the React prep path →Streaming lets the server send usable HTML before every part of the UI is ready. Suspense boundaries define where loading fallbacks can appear while delayed content streams in. Hydration mismatches happen when the first client render disagrees with the server HTML, often because the output depends on time, randomness, browser state, or inconsistent data.
Practice streaming UI →Testing
React Testing Library tests should assert behavior that a user can observe. Prefer role, label, text, and accessible name queries over component internals. A reliable test covers the visible state before and after interaction instead of asserting private methods or implementation details.
Open the React testing prep path →Jest and Vitest both provide test runners, assertions, mocks, and watch workflows. Vitest is often faster in Vite-based projects because it integrates with the Vite transform pipeline. The important choice is consistency with the app tooling, DOM environment, mocks, and coverage setup.
Review React test tooling →act() makes React flush updates related to an interaction or async step before assertions run. Testing utilities often wrap common user events for you, but warnings appear when a state update escapes the test boundary. The fix is to await the user action or async UI transition that causes the update.
Review async test timing →Start by asserting the initial state, trigger the user action or render path, then wait for loading, success, or error text that the user sees. The test should cover at least one failure path when the component has recovery UI. Avoid asserting raw promise timing because the visible transition is the behavior that matters.
Review async UI tests →Mock Service Worker style tests intercept requests at the network boundary instead of mocking every fetch call manually. That keeps the component closer to production behavior while still controlling success, error, delay, and malformed-response cases. The test should assert the UI contract, not the internals of the data-fetching library.
Review mocked API testing →A hook should be tested through a component when its value affects rendered UI or user interactions. That keeps the test aligned with React behavior such as render, commit, effects, and cleanup. Direct hook helpers can be useful for low-level reusable hooks, but user-facing behavior is usually safer to protect.
Review hook testing →StrictMode can run setup and cleanup more than once in development, which exposes effects that are not idempotent. Tests should not depend on an effect running exactly once when StrictMode is enabled. Assert the final user-visible behavior and make subscriptions, timers, and analytics calls cleanup-safe.
Review StrictMode effects →React tests become brittle when they assert component names, state variables, exact DOM nesting, or implementation-specific mocks. They also become flaky when async updates, timers, and network responses are not awaited through visible UI. Prefer stable user-facing queries, realistic interactions, and one clear assertion target per behavior.
Review React testing mistakes →Scenarios + code
function Counter() {
const [count, setCount] = useState(0);
function incrementLater() {
setTimeout(() => setCount(count + 1), 500);
}
}The timeout callback captures count from the render that created it. Multiple delayed clicks can all write the same next value. Use setCount((current) => current + 1) when the next value depends on previous state.
Debug stale closures →useEffect(() => {
const id = setInterval(() => poll(userId), 1000);
return () => clearInterval(id);
}, []);The effect reads userId but never reruns when userId changes. That leaves the interval polling the user from the first render. Include the dependency, or move ownership so the interval is recreated and cleaned up when the user changes.
Review effect dependencies →{users.map((user, index) => (
<UserRow key={index} user={user} />
))}React uses the key to match previous and next list items. If the list reorders or a row is inserted, an index key can point existing state at a different user. Use a stable ID from the data whenever row identity matters.
Review list keys →<AppContext.Provider value={{ user, theme, cart, setCart }}>
{children}
</AppContext.Provider>The provider creates a new object value whenever the parent renders, and every consumer sees the whole value as changed. Fast-changing cart state can rerender theme-only consumers. Split contexts or stabilize provider values around actual ownership boundaries.
Debug Context fan-out →const [fullName, setFullName] = useState('');
useEffect(() => {
setFullName(first + ' ' + last);
}, [first, last]);fullName is a pure value derived from first and last, so storing it creates a second source of truth. The effect also adds an extra render after every name change. Calculate it during render, or use useMemo only if the calculation is expensive.
Fix derived state →const [name, setName] = useState<string | undefined>();
return (
<input value={name} onChange={(event) => setName(event.target.value)} />
);The input starts with value undefined, so React treats it as uncontrolled. After typing, value becomes a string and React treats it as controlled. Initialize with an empty string or provide value={name ?? ""} so ownership is consistent.
Compare form ownership →const MemoChart = memo(Chart);
return <MemoChart options={{ theme, stacked: true }} />;The options object is recreated on every parent render, so the memoized child receives a different prop reference each time. React.memo can only skip work when props are equal by the comparison being used. Stabilize the object with useMemo or pass simpler stable props if profiling shows the chart is expensive.
Review memoization trade-offs →useEffect(() => {
analytics.startSession();
return () => analytics.stopSession();
}, []);StrictMode can remount components in development to check that effects clean up correctly. The effect should tolerate setup, cleanup, and setup again without leaking subscriptions or duplicating permanent work. Move one-time application boot logic outside component effects when component lifetime is not the right owner.
Review StrictMode behavior →Modern React
React 18 batches more state updates that happen in promises, timeouts, native events, and other async callbacks. Batching reduces extra renders by applying related updates together. Code still should not expect state variables to change immediately after calling setters within the same render.
Review batching →StrictMode enables extra development checks for unsafe rendering and effect behavior. It can reveal effects that do not clean up, render logic with side effects, and assumptions that fail under remounting. The fix is usually ownership and cleanup, not disabling StrictMode.
Review StrictMode purpose →Suspense boundaries let part of the UI show a fallback while a child is waiting for supported async work. They create loading boundaries instead of forcing the whole screen to block. Placement matters because a boundary that is too high hides too much UI, while one that is too low can create noisy loading fragments.
Open the React prep path →Transitions mark updates as non-urgent so React can keep urgent interactions responsive. They are useful when typing, clicking, or selecting should stay immediate while expensive UI updates can lag slightly. They do not make slow code fast, so profiling and splitting expensive work still matter.
Review render performance →Server Components render on the server and can access server-only resources without shipping their component code to the browser. Client Components still handle browser interactivity, state, effects, and event handlers. The boundary matters because props crossing from server to client must be serializable.
Open the React prep path →A hydration mismatch happens when server-rendered markup does not match the first client render. Common causes include time-dependent output, random IDs, browser-only data, locale differences, and conditional rendering that differs between server and client. Make the initial render deterministic, then move browser-only reads into effects or client-only boundaries.
Open the React prep path →Use local state for state owned by one component or a small subtree. Use Context sparingly for shared low-frequency values, and consider an external store when many components read and write frequently. Server-state libraries are a better fit for caching, dedupe, retries, stale data, and request status than hand-rolled effects.
Compare Context and stores →React tests should assert user-visible behavior instead of private implementation details. Good coverage includes initial render, interactions, validation, loading, error, cleanup, and rerender edge cases. Testing Library style queries keep tests closer to the way users and assistive technology observe the UI.
Open the React prep path →Critical for coding rounds and edge-case discussion.
Fix a component that renders twice per click because it stores derived state in `useEffect`. The correct fix is to remove the derived `parity` state and compute it directly from `count` during render, preventing the ext…
Open React coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a React debounced search input with fake API calls. Use useEffect + setTimeout cleanup to cancel stale requests, and manage loading, error, and empty states for realistic UX. Concepts: react, state, effects. React…
Open React coding interview challenge →Critical for coding rounds and edge-case discussion.
This hook should run the effect only on mount and clean up on unmount, even under React StrictMode development behavior. Concepts: react, hooks, effects, lifecycle, components. Mention StrictMode double-invocation, clea…
Open React coding interview challenge →Critical for coding rounds and edge-case discussion.
Build an **autocomplete search bar** in React. As the user types, show a dropdown of suggestions filtered from a dataset. Add debounced searching, mouse selection, keyboard navigation (↑/↓/Enter/Escape), and close-on-ou…
Open React coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a contact form using a React component with controlled inputs and basic validation. You will only work in `src/App.tsx` – the HTML shell and CSS are already set up. On submit, validate the input and send the form…
Open React coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a Material-like invite field in React. As users type, show autocomplete suggestions, convert selections into removable chips, and support keyboard shortcuts (Enter/comma/backspace).
Open React coding interview challenge →Need more implementation reps? Open the full coding list or follow a study plan.
Frequently tested in explanation-heavy rounds.
Explain lifting state up through sibling-sync bugs, duplicated local state drift, and the trade-off between a single source of truth, prop drilling, and over-lifting state too high.
Open React interview question →Frequently tested in explanation-heavy rounds.
Explain React rerenders through render vs commit, parent-child propagation, memo bailouts, context churn, and the follow-up confusion around remounts versus ordinary rerenders.
Open React interview question →Frequently tested in explanation-heavy rounds.
Explain useEffect as React’s external sync point through cleanup, dependency discipline, stale-closure debugging, and the common mistake of putting pure derived logic into effects.
Open React interview question →Frequently tested in explanation-heavy rounds.
Compare controlled and uncontrolled React inputs through validation, reset behavior, defaultValue, file-input limits, and the production warning/debugging cases that appear when a field switches ownership.
Open React interview question →Frequently tested in explanation-heavy rounds.
Keys are React's identity contract for list items. Use stable keys to prevent reordered rows, lost input state, random remounts, and production bugs where React preserves the wrong component.
Open React interview question →Frequently tested in explanation-heavy rounds.
Explain React rerendering through render work, reconciliation, commit, context fanout, and remount-vs-rerender identity bugs that make the DOM story easy to misread.
Open React interview question →Need more concept coverage? Open the full concepts list or browse company packs.
React coverage map
Props are read-only inputs owned by a parent, while state belongs to the component that changes it. Use callbacks to request parent state changes, lift state when siblings need the same value, and keep updates immutable so rerender behavior stays predictable.
Review props immutability →Hooks let function components hold state, refs, reducer logic, memoization, and external synchronization. For useEffect, explain dependencies, cleanup, stale closures, and when derived values should stay in render instead.
Practice useEffect timing and cleanup →The React Context API shares values below a provider, but provider updates can fan out to many consumers. Use it for cross-tree state like auth or theme, split providers, memoize values, and choose local state or a store when updates are frequent.
Debug Context performance →React form answers should explain controlled values, validation timing, defaultValue, refs, file input limits, loading and error states, and the warning that appears when field ownership switches.
Compare controlled and uncontrolled inputs →Function components use hooks for state, effects, refs, memoization, and cleanup. Class components use this.state and lifecycle methods, so interviews often ask how mount, update, and unmount behavior maps to useEffect.
Compare functions, classes, and lifecycle →Start with profiling, then target real waste: unstable props, broad context updates, expensive derived work, list rendering, unnecessary effects, and memoization that adds complexity without reducing work.
Prevent unnecessary rerenders →Debug React by separating render, commit, effects, and event handlers. Use React DevTools, StrictMode signals, console traces, and small reproduction cases before guessing at memoization or state fixes.
Debug double renders →Good tests cover user-visible behavior: initial state, interactions, validation, async loading and error paths, cleanup, and rerender edge cases. Prefer Testing Library style assertions over implementation details.
Open the React prep path →Treat libraries as trade-off examples: name the problem they solve, the cost they add, and when local React primitives are still enough.
Interview prep context
React prompts are prioritized by FrontendAtlas importance signals and reviewed for concrete interview follow-ups.
Quick answers
Yes. The page starts with beginner React fundamentals, then moves into experienced-developer topics such as hooks, effects, rendering internals, React 19, server/client boundaries, testing, Context performance, hydration, and server-state trade-offs.
Yes. The rendering internals section covers Virtual DOM, render and commit phases, reconciliation, diffing assumptions, Fiber, keys, fragments, and useLayoutEffect timing.
Yes. The React 19 section covers Actions, useActionState, useOptimistic, useFormStatus, use(), Server Components, Next.js App Router boundaries, streaming, Suspense, and hydration mismatches.
Yes. The testing section covers React Testing Library, Jest, Vitest, act, async loading and error UI, mocked API boundaries, hook testing, StrictMode effects, and brittle test mistakes.
Use this hub to find gaps, then move to the React interview preparation path for a 7, 14, or 30-day plan. The prep path owns the study-plan intent; this page owns the question-and-answer review intent.
Start with one route first. Then expand into Question Library, Study Plans, and Company Prep only when you need them.
Recommended preparation
Start with the interview preparation guide and shared baseline, then tighten React coding, concepts, and follow-up depth.