React Interview Questions and Answers

React is a JavaScript library for building user interfaces out of components: small, reusable functions that return what the screen should look like for the current data.

Its key ideas:

• Declarative: you describe the UI for a given state ("if loading, show a spinner"), and React updates the DOM to match. You don't write step-by-step DOM manipulation.
• Component-based: UIs are composed from independent pieces like <Header>, <ProductCard> and <CartDrawer>.
• One-way data flow: data goes down from parents to children through props, which makes behaviour predictable.
• Efficient updates: React compares the new UI description with the previous one and changes only what's different in the DOM.

It's popular because of its huge ecosystem (Next.js, React Native, TanStack Query), large job market (most frontend roles in Indian product companies and startups list React), and because the same skills carry to mobile with React Native.

Likely follow-up: What's the difference between a library and a framework, and is React a framework?

JSX is a syntax extension that lets you write HTML-like markup inside JavaScript. Browsers can't run it directly; a compiler (Babel, SWC, esbuild) turns each tag into a function call that creates a plain JavaScript object, a React element.

const element = <h1 className="title">Hello, {name}</h1>;

// compiles (with the modern JSX transform) to roughly:
import { jsx } from "react/jsx-runtime";
const element = jsx("h1", { className: "title", children: ["Hello, ", name] });

Here's the idea in plain JavaScript:

function jsx(type, props) {
  return { type, props };
}

const name = "Ananya";
const element = jsx("h1", { className: "title", children: ["Hello, ", name] });
console.log(element.type);
console.log(element.props.children.join(""));

h1
Hello, Ananya

Key JSX rules: use className (not class) and htmlFor; every tag must close (<img />); return a single root (or a Fragment); and anything inside { } is a JavaScript expression, not a statement.

Likely follow-up: Why can't you write an if statement inside JSX curly braces?

State is data a component owns and can change over time, like the text in a search box, whether a dropdown is open, or the items in a cart. Changing state tells React to re-render the component.

• Props come from the parent and are read-only in the child.
• State is created and managed inside the component (with useState or useReducer).
• A parent's state often becomes a child's props.

function Counter({ step }) {            // step is a prop
  const [count, setCount] = useState(0); // count is state
  return <button onClick={() => setCount(count + step)}>{count}</button>;
}

Regular variables (let count = 0) don't work for this: they reset on every render, and changing them doesn't trigger a re-render.

Likely follow-up: Why doesn't a regular variable work instead of useState?

useState(initialValue) returns a pair: the current value and a setter function.

function SearchBox() {
  const [query, setQuery] = useState("");
  return <input value={query} onChange={(e) => setQuery(e.target.value)} />;
}

What happens:

1. On the first render, query is "" (the initial value is used only once).
2. Typing calls setQuery("r"), which schedules a re-render.
3. React calls SearchBox again; this time useState returns "r".

React knows which state belongs to which useState call by their order within the component, which is why hooks must always be called in the same order (never inside conditions or loops).

Likely follow-up: What happens if you call useState inside an if statement?

A side effect is anything a component does besides calculating its JSX: fetching data, subscribing to events, setting timers, changing document.title, or talking to a non-React widget.

useEffect runs code after React has updated the screen, to synchronise your component with something outside React:

function PageTitle({ count }) {
  useEffect(() => {
    document.title = `Cart (${count})`;
  }, [count]);
  return null;
}

Rendering must stay pure, so side effects go either in event handlers (when caused by a user action, like clicking Pay) or in effects (when caused by the component being shown, like connecting to a chat room while the chat is on screen).

Likely follow-up: Why does useEffect run after paint rather than during render?

useEffect(() => { ... });            // after every render
useEffect(() => { ... }, []);        // once after the first render (mount)
useEffect(() => { ... }, [userId]);  // after mount, and whenever userId changes

React compares each dependency with its previous value using Object.is. If any changed, the effect re-runs (after running the previous cleanup).

The rule: list every prop, state value and function from the component that the effect reads. The react-hooks/exhaustive-deps ESLint rule enforces this. Leaving dependencies out to "run it only once" causes stale-value bugs; instead, restructure the code so the effect genuinely doesn't need the value.

Likely follow-up: Is it safe to leave a setState function out of the dependencies?

Context lets a parent make a value available to every component below it, without passing props through each level. It solves prop drilling for data many components need:

• the logged-in user
• theme (light or dark)
• language or locale
• feature flags
• a shared service, like an analytics client

Context is a dependency-injection mechanism, not a full state manager. It passes a value down; you still manage the value with useState or useReducer in the provider.

Likely follow-up: When is Context the wrong tool?

import { createContext, useContext, useMemo, useState } from "react";

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const value = useMemo(() => ({ user, login: setUser, logout: () => setUser(null) }), [user]);
  return <AuthContext value={value}>{children}</AuthContext>;   // React 19; earlier: <AuthContext.Provider value={value}>
}

export function useAuth() {
  const ctx = useContext(AuthContext);
  if (!ctx) throw new Error("useAuth must be used inside <AuthProvider>");
  return ctx;
}

// Anywhere below the provider:
function Navbar() {
  const { user, logout } = useAuth();
  return user ? <button onClick={logout}>Logout {user.name}</button> : <a href="/login">Login</a>;
}

Good practice:

• Export a custom hook (useAuth) instead of the raw context, with a helpful error when it's used outside the provider.
• Memoise the value object so consumers don't re-render on every provider render.
• Components read the value from the nearest provider above them; without one, they get the default from createContext.

Likely follow-up: What value does useContext return if there's no provider above?

• A parent re-renders, so all its children re-render by default, even with identical props.
• State lifted too high: typing in a search box stored in the page component re-renders the whole page.
• Context values that change often, or that are new objects every render.
• New object, array or function props created on every render, which defeat React.memo.
• Components defined inside other components, which remount on every render.

Most re-renders are cheap, so the goal isn't zero re-renders. Focus on renders that are slow (big lists, heavy calculations, charts) or frequent (on every keystroke or scroll event).

Likely follow-up: How do you find out which components re-render and why?

React.memo wraps a component so it skips re-rendering when its props are shallowly equal to the previous props (each prop compared with Object.is).

const BookCard = memo(function BookCard({ book, onAdd }) {
  return (
    <article>
      <h3>{book.title}</h3>
      <button onClick={() => onAdd(book.id)}>Add to cart</button>
    </article>
  );
});

It only helps if the props are actually stable. If the parent passes onAdd={() => addToCart(id)} or book={{ ...book }}, those are new references every render, and memo compares them as changed. That's where useCallback and useMemo come in.

A memoised component still re-renders when its own state or a context it uses changes.

Likely follow-up: When can you pass a custom comparison function to memo?

Machine coding rounds (60 to 90 minutes, building a working mini-app) test whether you can ship clean, working code under time pressure. A reliable approach:

1. Clarify requirements (3 to 5 minutes): which features are must-haves, what happens in edge cases (empty input, API failure), whether styling matters, and whether you can use libraries.
2. Plan the components and state before coding: sketch the component tree and decide where each piece of state lives.
3. Get a working version first, then improve. A complete simple app beats a half-finished perfect one.
4. Handle the states interviewers check: loading, error, empty, disabled buttons, keyboard access.
5. Keep code readable: small components, clear names, no giant files. Extract a custom hook if logic repeats.
6. Talk while you work: explain trade-offs ("I'd debounce this in production").
7. Leave 10 minutes to test edge cases and clean up.

Common evaluation points: correctness, component structure, state management, edge cases, accessibility, and code quality.

Likely follow-up: What would you do if you're running out of time with features unfinished?

function Counter({ min = 0, max = 10 }) {
  const [count, setCount] = useState(0);
  const [step, setStep] = useState(1);

  const clamp = (n) => Math.min(max, Math.max(min, n));

  return (
    <div>
      <p aria-live="polite">Count: {count}</p>
      <button onClick={() => setCount((c) => clamp(c - step))} disabled={count <= min}>−</button>
      <button onClick={() => setCount((c) => clamp(c + step))} disabled={count >= max}>+</button>
      <label>
        Step
        <input type="number" min="1" value={step} onChange={(e) => setStep(Math.max(1, Number(e.target.value) || 1))} />
      </label>
      <button onClick={() => setCount(0)}>Reset</button>
    </div>
  );
}

The core rule is clamping:

const clamp = (n, min, max) => Math.min(max, Math.max(min, n));
console.log(clamp(12, 0, 10), clamp(-3, 0, 10), clamp(7, 0, 10));

10 0 7

Details that score points: the updater form for setting state from the previous value, disabled buttons at the limits, validating the step input, and aria-live so screen readers announce changes.

Likely follow-up: How would you add an "auto increment while holding the button" feature?