Frequently asked React interview questions for front-end developers on JSX, components, props and state, hooks, effects, context, performance, rendering and testing, with hints and answers.
15 questions · Updated
Who owns the value?
Props are passed into a component by its parent and are read-only for that component. State is owned by the component itself and changed with its setter, which triggers a re-render. Data typically lives in a parent's state and flows down to children as props.
It is not HTML.
JSX is HTML-like syntax inside JavaScript. A build tool compiles each element into a function call that creates a React element, such as React.createElement("h1", { className: "t" }, "Hi") (or the automatic JSX runtime's equivalent). Expressions go in { }, attributes are camelCase, and class becomes className.
What happens when an item is inserted at the top?
Keys identify which item is which between renders, so React can move, insert and remove the right elements and keep each item's state with it. If you use the index and insert an item at the top, every item's index changes, so state (such as text typed into an input) stays at the old positions and ends up next to the wrong items. Use stable ids from the data.
Where does the value live?
An input whose value comes from React state and whose onChange updates that state, so React is the single source of truth. This makes validation while typing, formatting and dependent fields easy. Uncontrolled inputs keep their value in the DOM (defaultValue) and are read on submit with a ref or FormData.
When does handleDelete run?
handleDelete(id) is called immediately during rendering, and its return value is passed as the handler. If it updates state, it causes an infinite render loop ("Too many re-renders"). Pass a function instead: onClick={() => handleDelete(id)}.
What is count inside this render?
State is a snapshot for each render. All three calls compute count + 1 from the same value, so they all set the same number, and React batches them into one re-render. Use the updater form, setCount((c) => c + 1), which receives the latest pending value each time.
No array, empty array, values.
Without an array the effect runs after every render; with [] it runs once after mounting; with values it runs after mounting and whenever one of them changes. The function the effect returns is the cleanup: React calls it before re-running the effect and when the component unmounts, which is where you clear timers, remove listeners and cancel subscriptions.
Which render's count does the interval callback see?
The callback was created in the first render, so it captured count = 0 and keeps setting 0 + 1. This is a stale closure. Use the updater form setCount((c) => c + 1), which does not depend on the captured value, or include count in the dependencies (re-creating the interval each time).
Closest common...
In their closest common parent: it holds the state and passes the value down as props, plus callbacks so the children can request changes. If the data is needed by many distant components, use context (often with a reducer) or a state library.
Who re-renders when the value changes?
Every component that reads the context re-renders when its value changes, so a large, frequently changing context can slow an app down. It also makes data flow less explicit than props. Split contexts by concern, keep fast-changing values elsewhere, and prefer props or composition for shallow data.
Expensive work, or stable identities.
Use useMemo to cache an expensive calculation, and useMemo/useCallback to keep object and function identities stable when they are passed to memo components or used as effect dependencies. Don't wrap everything: memoisation has its own cost and adds dependency arrays to maintain. Measure with the Profiler first; the React Compiler can add memoisation automatically.
Is it the same component type on the next render?
Each render creates a brand-new function, which React treats as a different component type. On reconciliation, a different type at the same position means unmount the old subtree and mount a new one, so its state and DOM are thrown away. Define components at the top level of the module.
Server HTML vs first client render.
The HTML rendered on the server differs from the client's first render, for example because of Date.now(), random values, window or locale-specific formatting during rendering. Render the same output on both sides and move browser-only values into an effect (which runs only on the client), or mark intentionally different content explicitly.
Where does the code run, and does it ship JavaScript?
Server Components run only on the server or at build time; they can be async, access databases and secrets, and add no JavaScript to the browser bundle, but cannot use state, effects or event handlers. Client Components ("use client") run in the browser too and handle interactivity. Server Components can render Client Components and pass them serialisable props.
Don't call the real API.
Render it with React Testing Library, mock the network (with MSW or by stubbing fetch), assert the loading state, then use findBy... queries to wait for the data or error message. Test what the user sees, not internal state, and also cover the error path.