React Components and Props Interview Questions and Answers

Components and props are the first thing any React interview checks, because everything else is built on them. The questions below are the ones that appear at the start of almost every loop — what a component is, how props differ from state, why data flows one way, and how composition beats configuration. Get these crisp and the rest of the interview flows from a shared foundation.

How to answer components-and-props questions

Answer from one idea: React is a one-way data flow of read-only props down a tree of composable components. Almost every question here is a corollary of that sentence — props are immutable because the flow is one-way; children exists because components compose; callbacks flow up because children cannot mutate props. Tie your answers back to that principle and they stay consistent under follow-ups.

Q1. What is a React component?

A component is a reusable, self-contained piece of UI — a JavaScript function that takes props and returns React elements (JSX) describing what should appear on screen. Components compose into a tree, and React re-renders them when their inputs change.

A component is the unit of reuse and the unit of re-render. The modern form is a function that receives a props object and returns JSX; React calls it to produce elements, diffs the result against the previous output, and updates only what changed.

function Greeting({ name }) {
  return <h2>Hello, {name}</h2>;
}

Interview note: Follow-up: "component vs element vs instance?" A component is the function; an element is the lightweight object it returns describing UI; React manages instances internally. Confusing element with DOM node is a common slip.

Q2. Function components vs class components — which and why?

Function components with hooks are the default for all new code: less boilerplate, no this confusion, and reusable logic through custom hooks. Class components use lifecycle methods and this.state; they still exist in older code and remain the only way to write an error boundary, but you should not reach for them by default.

The substance behind the preference is that hooks let you share stateful logic without the wrapper-hell that patterns like higher-order components and render props caused in the class era.

Interview note: Trap: "name something only a class can still do." Catch render errors via componentDidCatch / getDerivedStateFromError — there is still no hook equivalent for error boundaries.

Q3. Props vs state — draw the line.

Props are inputs handed down by a parent and are read-only inside the receiving component. State is data a component owns and mutates over time with a setter. Props come from outside and cannot be changed by the child; state is internal and changing it triggers a re-render.

The clean test: if a value comes from a parent and this component only displays or forwards it, it is a prop; if this component is the one that changes it in response to user action, it is state. Duplicating a prop into state "to edit it" is a classic bug that causes the copy to drift from the source.

Interview note: Follow-up: "can a prop become state?" You can initialise state from a prop, but then later prop changes are ignored — usually a smell. Prefer deriving during render or resetting via a key.

Q4. Why are props read-only, and how does a child update the parent?

One-way data flow requires that a child never mutate the props it receives — otherwise the parent's data changes invisibly and state becomes untraceable. A child that needs to change parent-owned data calls a function the parent passed down as a prop, keeping the parent as the single source of truth.

function Parent() {
  const [count, setCount] = useState(0);
  return <Child count={count} onIncrement={() => setCount(c => c + 1)} />;
}
function Child({ count, onIncrement }) {
  return <button onClick={onIncrement}>{count}</button>;
}

Interview note: Trap: "what if you mutate a prop object directly?" You break the flow and often mutate the parent's state object too, causing bugs React cannot help you trace. Treat props as frozen.

Q5. What is the children prop and why does it matter?

children is a built-in prop containing the JSX nested between a component's opening and closing tags. It enables composition: a component can wrap and render content it knows nothing about, which is how layouts, cards, modals and providers are built.

function Card({ title, children }) {
  return (
    <section className="card">
      <h3>{title}</h3>
      <div>{children}</div>
    </section>
  );
}
// <Card title="Profile"><Avatar /><Bio /></Card>

Interview note: Follow-up: "composition vs a content prop?" Composition via children keeps the parent generic and the markup declarative; passing rendered content as a regular prop is fine too, and multiple named slots are just multiple props.

Q6. What is prop drilling, and what are the fixes?

Prop drilling is threading a prop through several intermediate components that do not use it, only to reach a deep descendant. The fixes, in order of scope: restructure with composition so the data-owner renders the consumer directly; use Context for genuinely global data like theme or auth; use a state store for large, frequently-changing shared state.

Reach for the smallest fix that works. Composition solves more drilling than people expect, because passing the rendered child down avoids passing its data down. The Context API and state management questions cover the heavier tools and their costs.

Interview note: Trap: "is Context always better than drilling?" No — Context re-renders all consumers on value change and hides data flow; a little drilling is often clearer than a Context you added too early.

Q7. What are default props and how do you set them now?

In function components you set defaults with JavaScript default parameters when destructuring props. The old Component.defaultProps still works for class components but is discouraged for function components.

function Button({ variant = "primary", disabled = false, children }) {
  return <button className={variant} disabled={disabled}>{children}</button>;
}

Interview note: Follow-up: "how do you validate prop types today?" TypeScript is the standard; PropTypes is a lightweight runtime option for plain-JS projects but is no longer bundled with React.

Q8. Why do lists of components need a key, and what makes a good key?

Keys let React identify which items changed, moved or were removed so it can update the list efficiently and preserve each item's state. A good key is stable and unique among siblings — typically a domain id. The array index is a poor key for any list that can reorder or filter, because it ties state to position instead of identity.

Interview note: Trap: "keys are props, right? Can I read this.props.key?" No — key is consumed by React and is not passed into the component. Pass the id separately if the child needs it.

Q9. What is a pure component, and why prefer keeping components pure?

A pure component renders the same output for the same props and state and causes no side effects during render. Keeping render pure lets React re-render safely, skip work, and run features like Strict Mode's double-invocation and concurrent rendering without breaking your app. Side effects belong in event handlers or effects, never in the render body.

React.memo wraps a function component to skip re-rendering when props are shallow-equal — a performance tool that only pays off when the component is expensive and its props are stable.

Interview note: Follow-up: "why does React call my component twice in development?" Strict Mode intentionally double-invokes render and some effects to surface impure code and missing cleanup; production runs once.

How to prepare

Build a small component tree from scratch — a parent owning state, children receiving props, a callback flowing back up, and a wrapper using children — and narrate the data flow out loud. That one exercise answers most of the questions here. Then practise the boundary calls: prop vs state, drilling vs Context, function vs class, until each has a one-line justification. When these feel automatic, move on to the state management questions where props hand off to shared state, and reinforce the fundamentals through the React learning path. A quick mock interview on the basics is the fastest way to catch vague spots before they cost you the opening minutes of a loop.