React Interview Questions for Freshers

Your first React interview is checking one core idea in many disguises: do you understand that the UI is a function of state, and that React re-renders when state changes? Freshers who grasp that — and can show it in five lines of a component — usually clear the round. This set walks the thirteen fresher questions asked most often, each with a quick spoken answer, the mechanism underneath, and the follow-up that trips up unprepared candidates.

Why interviewers ask React questions to freshers

Almost every frontend and full-stack fresher role now lists React, so interviewers use it to separate candidates who have copied tutorials from those who understand the render model. The tell is whether you can explain why the screen updated, not just that it did.

The questions stay deliberately foundational but demand precision. They check that you know data flows down through props, that state changes trigger re-renders, and that you never mutate state directly. If you can attach a reason to each of those rules, you are ahead of most applicants. If any concept feels loose, review what React is first.

How to answer in an interview

Answer every question by connecting it back to the render cycle: state changes, React re-renders, the UI reflects the new state. "useState stores a value" is thin; "useState gives a component a value plus a setter, and calling the setter tells React to re-render with the new value" shows understanding.

Keep one small component ready in your head for each concept. Concrete beats abstract — showing a five-line useState counter answers three questions at once. Refresh with the React hooks introduction if hooks feel shaky.

Q1. What is React and what problem does it solve?

React is a JavaScript library for building user interfaces from reusable components. It solves the problem of keeping a complex UI in sync with changing data: you describe what the UI should look like for a given state, and React efficiently updates the DOM when the state changes.

The key idea is declarative rendering — you write what the UI is for each state, not the step-by-step DOM manipulation to get there. React handles the "how" through its diffing.

Interview note: Follow-up: "is React a framework or a library?" A library — it focuses on the view layer. Routing, data fetching and state management come from separate libraries, unlike an all-in-one framework such as Angular.

Q2. What is JSX?

JSX is a syntax extension that lets you write HTML-like markup inside JavaScript. It is not HTML and not understood by the browser directly — a tool like Babel compiles it into React.createElement calls that produce the elements React renders.

const greeting = <h1>Hello, {name}</h1>;
// compiles to React.createElement('h1', null, 'Hello, ', name)

The curly braces embed any JavaScript expression. Knowing JSX is compiled, not run as-is, is the detail that separates understanding from memorising. More in the JSX syntax guide.

Interview note: Trap: "why className instead of class in JSX?" Because class is a reserved word in JavaScript, and JSX is JavaScript. Similarly for becomes htmlFor.

Q3. What is a React component?

A component is a reusable, self-contained piece of UI, written as a JavaScript function that returns JSX. It can accept inputs (props) and manage its own data (state), and you compose components together to build the full interface.

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

Modern React uses function components. The mental model is a function from props (and state) to UI — same inputs, same output. Composition is how small components build large screens.

Interview note: Follow-up: "function vs class components?" Both work, but function components with hooks are the modern standard — less boilerplate, no this, and hooks cover everything classes did.

Q4. What is the difference between props and state?

Props are read-only data passed into a component from its parent — the component cannot change them. State is data the component owns and manages internally, and changing it (via the setter) triggers a re-render.

function Counter() {
    const [count, setCount] = useState(0);   // state: owned, changeable
    return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

The separation is the single most-asked fresher concept: props flow down and are immutable to the child; state is local and mutable through its setter. Data flows one way — down through props.

Interview note: Trap: "can a child change its props?" No — props are read-only. To change parent data, the parent passes a callback the child calls, keeping data flow one-directional.

Q5. What does the useState hook do?

useState gives a function component a piece of state and a function to update it. It returns a pair: the current value and a setter. Calling the setter schedules a re-render with the new value.

const [name, setName] = useState("");
setName("Asha");   // updates state and re-renders

The crucial rule: never assign to the state variable directly — always use the setter, or React will not know to re-render. State updates may also be batched and are not applied synchronously.

Interview note: Follow-up: "why does count seem one step behind if I call setCount twice?" State updates are asynchronous and batched; use the functional form setCount(c => c + 1) to build on the latest value.

Q6. What does the useEffect hook do?

useEffect runs side effects — data fetching, subscriptions, timers, manual DOM work — after render. Its dependency array controls when it re-runs: empty means once after mount, with values means whenever those values change.

useEffect(() => {
    fetchUser(id);              // runs after render
}, [id]);                       // re-runs only when id changes

The dependency array is where freshers slip. An empty array runs the effect once; omitting the array runs it after every render, which often causes bugs or infinite loops when the effect also sets state.

Interview note: Trap: "what does the function you return from useEffect do?" It is the cleanup — React runs it before the next effect and on unmount, used to clear timers or unsubscribe. Forgetting it causes memory leaks.

Q7. Why do lists need a key prop?

Keys give React a stable identity for each list item so it can tell which items changed, moved or were removed between renders, and update the DOM efficiently. Without stable keys, React may re-render or reorder items incorrectly.

{users.map(u => <li key={u.id}>{u.name}</li>)}   // stable, unique key

The rule: keys should be stable and unique — a database id, not the array index, because indexes shift when items are inserted or removed, causing subtle state bugs.

Interview note: Trap: "why not use the array index as the key?" It breaks when the list reorders or items are inserted/deleted — React associates the wrong state with the wrong item. Use a stable id.

Q8. What is the virtual DOM and how does React use it?

The virtual DOM is a lightweight in-memory representation of the UI. On a state change, React builds a new virtual tree, diffs it against the previous one (reconciliation), and updates only the real DOM nodes that actually changed.

Direct DOM manipulation is slow, so React batches the minimal set of real-DOM updates. This is why you describe the whole UI for a state and let React figure out the efficient patch, instead of mutating nodes yourself.

Interview note: Follow-up: "is the virtual DOM always faster than direct DOM?" Not always — for a tiny change, hand-written DOM code could be faster. The virtual DOM's value is making declarative, whole-UI updates efficient enough at scale.

Q9. What is conditional rendering in React?

Rendering different UI based on state or props, using ordinary JavaScript — a ternary, &&, or an early return. There is no special template syntax; JSX is expressions, so you branch with the language itself.

{isLoading ? <Spinner /> : <UserList users={users} />}
{error && <p className="error">{error}</p>}

The && short-circuit is common but has a trap: a falsy 0 will render as "0" on screen, so guard with an explicit boolean when the left side might be a number.

Interview note: Trap: "why did {count && <List/>} render a 0?" Because count is 0, a falsy number that React still renders as text. Use count > 0 && <List/> instead.

Q10. What are controlled and uncontrolled components?

A controlled input has its value driven by React state and updated through onChange — React is the single source of truth. An uncontrolled input keeps its own value in the DOM, read via a ref. Controlled is the standard for forms.

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

Controlled inputs make validation and conditional logic easy because the value lives in state. The trade-off is a re-render per keystroke, rarely a problem at fresher scale.

Interview note: Follow-up: "when would you use an uncontrolled input?" For simple forms, file inputs, or integrating a non-React library, where reading the value once on submit via a ref is enough.

Q11. Why must you not mutate state directly in React?

Because React detects changes by comparing references, not deep values. Mutating an object or array in place keeps the same reference, so React may not re-render. You create a new object or array instead, and React sees the change.

setItems([...items, newItem]);        // new array — React re-renders
// items.push(newItem); setItems(items);  // WRONG: same reference

This immutability rule is a top fresher trap. It underlies why you spread arrays and objects when updating state rather than modifying them.

Interview note: Trap: "you called setItems but the UI didn't update — why?" You likely mutated the existing array and passed the same reference. React's shallow comparison saw no change. Always pass a new reference.

Q12. How do components communicate with each other?

Parent to child through props. Child to parent by the parent passing a callback function as a prop that the child calls. For distant components, you lift shared state up to a common ancestor or use Context to avoid passing props through many layers.

Data flow is one-directional — down through props. When two sibling components need the same data, you move that state up to their nearest common parent. The state management overview covers when to reach for Context or a library.

Interview note: Follow-up: "what is prop drilling and how do you avoid it?" Passing props through many intermediate components that don't use them. Context or a state library removes the drilling by providing the value where it is needed.

Q13. What are React hooks and what rules do they follow?

Hooks are functions like useState and useEffect that let function components use state and lifecycle features. Two rules: call them only at the top level (never inside loops, conditions or nested functions) and only from React function components or custom hooks.

The top-level rule exists because React tracks hooks by call order — branching would misalign that order between renders. Breaking the rules produces the classic "rendered fewer hooks than expected" error.

Interview note: Trap: "can you call useState inside an if statement?" No — it violates the rules of hooks. Put the condition inside the hook or restructure so the hook always runs. See the React hooks interview questions for depth.

How to prepare

Build one small interactive app — a to-do list or a live search filter — using useState, useEffect, props, callbacks and a keyed list. Then break it on purpose: remove a key and watch the warning, mutate state in place and watch the UI freeze, drop a useEffect dependency and watch it loop. Every warning maps to a question above.

Rehearse the props-vs-state distinction (Q4) and the "why didn't it re-render" immutability answer (Q11) until they are automatic — both are asked in almost every fresher screen. Then go deeper with the React hooks interview questions and the wider React interview questions for 2026. Building real, stateful UIs like this is exactly what our practical, project-based training develops.