Practice free

React Interview Questions for Freshers (2026) — with Answers

Updated August 2026

Nearly every React question a fresher gets is a rendering question in disguise. Why did this component re-render, why did it not update, why does this effect run twice, why does this list behave strangely when reordered — all four have the same underlying answer, which is what React does when state changes. Understand that sequence and the subject collapses into something small.

The sequence is worth memorising as a shape rather than as words: state changes, React re-runs your component function to produce a description of the UI, compares that description with the previous one, and applies only the differences to the real DOM. You describe what the UI should look like for a given state; React works out the DOM operations. Every classic fresher mistake — mutating state directly, reaching for the DOM manually, using an array index as a key on a reorderable list — comes from thinking imperatively inside a declarative system.

This page assumes the JavaScript underneath. Closures, `this`, promises and the event loop come up constantly in React interviews because hooks are built on closures and effects are asynchronous, so prepare our JavaScript set alongside this one — a candidate who cannot explain a closure will struggle to explain why a stale value appeared inside an effect. Answer each question in 30–60 seconds and finish with why the behaviour exists.

Frequently asked questions

What happens when state changes in React?

React schedules a re-render of that component. It re-runs the component function, which returns a new description of the UI, then compares that description against the previous one — reconciliation — and applies only the differences to the real DOM in a commit phase. Two consequences interviewers probe: the component function runs again in full, so anything expensive inside it runs again; and re-rendering a component re-renders its children by default, whether or not their props changed. This is the answer most other React questions reduce to, so rehearse it until it is fluent.

What is the virtual DOM, and is it actually faster?

It is a lightweight JavaScript representation of the UI that React diffs between renders to work out the minimum set of real DOM updates. On whether it is faster — be careful here, because the confident wrong answer is common. Hand-written, perfectly targeted DOM updates can beat it; the virtual DOM is not magic. What it reliably buys is a programming model where you describe the end state instead of the transitions, plus batching so many state changes become one DOM update, which in practice outperforms the manual DOM code most people actually write. Saying that distinction out loud marks you as someone who understands the trade rather than repeating a slogan.

What is JSX, and what does it compile to?

JSX is syntax that looks like HTML inside JavaScript, and it is not understood by browsers — a build step compiles it into ordinary function calls that create element objects. That is why you write className rather than class and htmlFor rather than for, since the attributes become JavaScript object properties and those words are reserved. It also explains why you can put any JavaScript expression inside braces and why a component must return a single root element or a fragment: the call has to produce one value.

Props versus state — what is the difference?

Props are inputs passed into a component by its parent and are read-only from the receiving component's point of view. State is data the component owns and can change, and changing it triggers a re-render. The rule that follows and that interviewers like: if a value can be computed from props or existing state, do not put it in state — derive it during render. Duplicating derived data in state is the source of a whole family of bugs where two pieces of state disagree with each other.

Why must you not mutate state directly?

React decides whether to re-render by comparing the previous value with the new one, and for objects and arrays that comparison is by reference. Mutating an array with push or changing an object property keeps the same reference, so React sees no change and skips the render — the data updated but the screen did not. The fix is to create a new object or array: spread into a new one, or use map and filter which return new arrays. This is a very common interview question precisely because it is such a common beginner bug.

Why does state not seem to update immediately after setState?

Because state updates are queued rather than applied synchronously. Within the same event handler the state variable you already have is a value captured for that render, so reading it after calling the setter still gives the old value — React will re-run the component with the new value afterwards. If your next value depends on the previous one, use the functional form, passing a function that receives the latest state, which is also what makes multiple updates in one handler compose correctly instead of overwriting each other.

Explain useEffect and its dependency array.

useEffect runs code after render, for things outside React's rendering — fetching data, subscriptions, timers, manual DOM work. The dependency array controls when it re-runs: omit it and it runs after every render; pass an empty array and it runs once after the first render; list values and it re-runs whenever one of them changes. The return value is a cleanup function, which React calls before the next run and when the component unmounts — that is where you cancel timers and unsubscribe. Most effect bugs are one of three things: a missing dependency causing stale values, an object or function dependency recreated every render causing an infinite loop, or missing cleanup causing a leak.

Why do effects sometimes run twice on mount in development?

React's development-mode strict checks intentionally mount, unmount and remount components to surface effects that are not resilient to being run more than once. It is a diagnostic, not a bug, and it does not happen in production builds. The right response is not to suppress it but to treat it as the signal it is: an effect that breaks when run twice usually lacks cleanup, or is doing something during render that should not be there. Saying that shows you understand the intent rather than treating it as an annoyance.

Why do lists need keys, and why is the array index a bad key?

Keys let React match elements between renders so it can tell what moved, what was added and what was removed, rather than rebuilding the list. With an index as key, the key describes a position rather than an item, so if the list is reordered, filtered or has items inserted, React associates the wrong existing element with an item — which most visibly corrupts internal state like the text typed into an input, or checkbox states. The precise answer, which is better than the dogmatic one: an index is acceptable for a static list that never reorders and has no per-item state, and is a genuine bug for anything else. Use a stable id from your data.

Controlled versus uncontrolled components?

A controlled input has its value driven by React state, with an onChange handler updating that state on every keystroke — React is the single source of truth. An uncontrolled input keeps its own value in the DOM and you read it when needed, usually through a ref. Controlled is the default recommendation because validation, conditional disabling and formatting all become straightforward when the value lives in state. Uncontrolled is reasonable for simple forms or when integrating with non-React code, and mentioning that trade-off is better than declaring one always correct.

What are the rules of hooks, and why do they exist?

Call hooks only at the top level of a component or another hook, never inside conditions, loops or nested functions; and call them only from React function components or custom hooks. The reason is the mechanism: React tracks hooks by call order, not by name, so the first useState is matched to the first slot on every render. Calling one conditionally changes the order between renders, and React would associate the wrong state with the wrong hook. Explaining the why rather than reciting the rule is what distinguishes a good answer here.

What is useRef used for?

Two distinct things. First, a reference to a DOM element, which is how you focus an input or measure something. Second, a mutable value that persists across renders without triggering one when it changes — useful for timer ids, previous values or any bookkeeping the UI does not depend on. The contrast with state is the point of the question: changing state re-renders, changing a ref does not, so anything the rendered output depends on belongs in state rather than a ref.

When should you use useMemo and useCallback?

useMemo caches a computed value between renders; useCallback caches a function identity. Both exist for the same underlying reason — to keep a reference stable so that expensive work is skipped or a child that compares props is not re-rendered unnecessarily. The honest answer, and the one interviewers are usually fishing for, is that freshers over-apply them: they are not free, since React stores the value and compares dependencies on every render, and wrapping everything makes code harder to read for no measurable gain. Reach for them when there is a genuinely expensive computation or a measured re-render problem, not by default.

What is prop drilling, and how does useContext help?

Prop drilling is passing data down through several layers of components that do not use it themselves, purely to reach a descendant that does — verbose and awkward to change. Context lets a provider supply a value that any descendant can read directly with useContext, which suits genuinely global things like the current user, theme or language. The caveat worth adding unprompted: every consumer re-renders when the context value changes, so putting frequently-changing state in one big context causes broad re-renders, and context is not a substitute for a state management library in complex applications.

What is a custom hook?

A function whose name begins with "use" and that calls other hooks, used to extract stateful logic so it can be reused across components. The important clarification is what is shared and what is not: each component calling a custom hook gets its own independent state, because the hook is just a function running inside that component. It shares the logic, not the data. Being able to describe a real one you wrote — a data-fetching hook, a form hook, a debounced-value hook — is far stronger than defining the term.

How do you handle side effects like fetching data?

In an effect, or through a data-fetching library that handles the surrounding concerns for you. The parts an interviewer wants to hear about are the ones freshers omit: handling loading and error states rather than just the success path, cleaning up so a response arriving after the component unmounted does not attempt a state update, and avoiding the infinite loop that comes from an effect setting state that is also in its dependency array. Mentioning that production applications usually reach for a library here, because caching and request deduplication are genuinely hard, shows awareness beyond a tutorial.

Class components or function components — which should you know?

Function components with hooks are the modern standard and what you should write. Know enough about class components to read older code and to answer the lifecycle question, because plenty of existing codebases still contain them. The mapping worth having ready: componentDidMount corresponds to an effect with an empty dependency array, componentDidUpdate to an effect with dependencies, and componentWillUnmount to the cleanup function returned from an effect. Framing it as one mechanism replacing three lifecycle methods is a cleaner answer than listing equivalences.

When do you actually need Redux or another state library?

Later than most tutorials imply, which is the point of the question. Local state plus a little context handles a surprising amount, and reaching for a global store early adds indirection that a fresher project rarely earns. The genuine signals are many components across unrelated branches needing the same frequently-changing data, complex update logic worth centralising and testing, or a need to trace how state changed over time. Saying "it depends on whether the state is genuinely global" with an example is stronger than naming libraries.

What is the difference between React and a framework like Next.js?

React is a library for building user interfaces — it handles components and rendering and deliberately leaves routing, data fetching and build configuration to you. Next.js is a framework built on React that supplies those decisions, including file-based routing and server rendering. The distinction matters in interviews because candidates frequently describe framework features as React features, so being clear about which layer does what signals that you understand what you are using rather than having followed a template.

Is React worth learning for 2027-batch placements?

Yes for front-end, full-stack and product-company roles, where it is the most commonly required UI library and a React project is the most legible thing you can show. Sequence it sensibly though: for mass service recruiters, aptitude, one strong language for coding rounds, SQL and core CS come first, and React adds most value once those are solid. And prepare the JavaScript underneath rather than only the library — hooks are built on closures, effects are asynchronous, and interviewers who go one question deeper than the framework find out quickly which candidates learned React without learning JavaScript.

Don't just read React questions — get asked them

Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.

Start a free AI mock interview

How to prepare

Where these questions get asked

Related guides