Explain the concept of reconciliation in React. | Interview Question

Q: Explain the concept of reconciliation in React.

**Target Audience:** Engineers preparing for React interviews — assumes rendering basics. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every behaviour below was **executed against React 19.2.8**, including the misassigned checkbox in section 5 — raw output included. ## 1. Why This Even Matters — A Story First A theatre reuses its cast between two performances of the same play. The sensible way to decide who plays whom is by **name on the call sheet**: Ada plays the lead in both. The lazy way is by **where they stood last night**: whoever is first in the line is the lead. Both work perfectly, right up until someone new joins at the front of the queue. Then everyone is playing the wrong part — and nobody notices until the wrong actor delivers someone else's line. That is index keys. ## 2. The Core Idea 📌 **Interview term: reconciliation** — the process of comparing the newly r

The problem

Question presented to candidate: "React re-renders and produces a new element tree. How does it decide what to actually change in the DOM — and why does key matter so much?"

What a strong answer should cover:

Reconciliation is React comparing the new element tree against the previous one and applying the minimum set of DOM operations. It is not comparing against the DOM itself.
A general tree diff is O(n³), so React uses two heuristics to make it O(n).
Heuristic 1 — different type means discard. If the element type at a position changed, React unmounts that subtree and mounts a new one. All state is lost.
Heuristic 2 — keys identify siblings across renders. Within a list, the key tells React that "this is the same item as before", even if its position moved.
Position is the default identity. Without keys, React pairs children by index — so inserting at the front makes every subsequent item look "changed".
The practical consequence: index keys are wrong whenever the list can reorder, insert or delete, because component state and DOM state stay bound to the position, not the item.
Same type and same key means React reuses the instance: state survives, only the changed props are applied.
Changing a component's key is the deliberate way to reset its state.

Clarifying questions expected:

"Can this list reorder, or have items inserted anywhere but the end?" — that decides whether index keys are acceptable.
"Do the rows hold their own state — inputs, toggles, animations?"

Code / implementation expected: Optional. Demonstrating a checkbox landing on the wrong row is far more convincing than describing it.

virtual dom
reconciliation
diffing
rendering

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for React interviews — assumes rendering basics. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every behaviour below was executed against React 19.2.8, including the misassigned checkbox in section 5 — raw output included.

1. Why This Even Matters — A Story First

A theatre reuses its cast between two performances of the same play.

The sensible way to decide who plays whom is by name on the call sheet: Ada plays the lead in both. The lazy way is by where they stood last night: whoever is first in the line is the lead.

Both work perfectly, right up until someone new joins at the front of the queue. Then everyone is playing the wrong part — and nobody notices until the wrong actor delivers someone else's line.

That is index keys.

2. The

The solution is hidden so you can try first

7 min read · 9 sections

Try it in the playground

Open any example in the playground to run and change it.

ReactThe same list with index keys and stable keys — prepend a row and watch the tick

Open in playground

import { useState } from "react";

// Each row holds its OWN state that is not derived from props. That is what
// gets misassigned when React matches children by position.
function Row({ item }) {
  const [checked, setChecked] = useState(false);
  return (
    <label style={{ display: "block", fontSize: 13, padding: "2px 0" }}>
      <input type="checkbox" checked={checked} onChange={(e) => setChecked(e.target.checked)} />
      {" "}{item.name}
      {checked && <strong style={{ color: "#4f46e5" }}> ← ticked</strong>}
    </label>
  );
}

function List({ title, items, keyBy }) {
  return (
    <div style={{ border: "1px solid #ddd", borderRadius: 8, padding: 12, flex: 1 }}>
      <strong style={{ fontSize: 13 }}>{title}</strong>
      <div style={{ marginTop: 6 }}>
        {items.map((it, i) => (
          <Row key={keyBy === "index" ? i : it.id} item={it} />
        ))}
      </div>
    </div>
  );
}

const START = [
  { id: "a", name: "Ann" },
  { id: "b", name: "Ben" },
  { id: "c", name: "Cal" },
];

export default function App() {
  const [items, setItems] = useState(START);
  const [n, setN] = useState(0);

  const prepend = () => {
    const names = ["Zoe", "Yan", "Xia"];
    setItems((list) => [{ id: "new" + n, name: names[n % 3] }, ...list]);
    setN((v) => v + 1);
  };

  return (
    <div style={{ padding: 24, fontFamily: "system-ui", lineHeight: 1.6, maxWidth: 560 }}>
      <p style={{ fontSize: 13, margin: "0 0 10px" }}>
        <strong>1.</strong> Tick <em>Ann</em> in both lists. <strong>2.</strong> Press prepend.
      </p>

      <div style={{ display: "flex", gap: 12, marginBottom: 12 }}>
        <List title="❌ key={index}" items={items} keyBy="index" />
        <List title="✅ key={item.id}" items={items} keyBy="id" />
      </div>

      <button onClick={prepend}>prepend a new row</button>{" "}
      <button onClick={() => { setItems(START); setN(0); }}>reset</button>

      <p style={{ fontSize: 13, color: "#666" }}>
        On the left the tick stays at position 0 and is now attached to a row
        the user has never seen. On the right it follows Ann down. Same data,
        same components — only the key differs. Nothing errors and nothing
        warns, which is exactly what makes this dangerous.
      </p>
    </div>
  );
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.