What is the Virtual DOM in React? | Interview Question

Q: What is the Virtual DOM in React?

**Target Audience:** Anyone preparing for a React interview — assumes basic components. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The reconciliation behaviour in section 5 was produced by actually swapping an element type on React 19.2.8 and observing what happened to the child state. ## 1. Why This Even Matters — A Story First An architect wants three changes to a building. They do not demolish it and rebuild from the new plans. They lay the new drawings over the old ones, find the three differences, and send builders to make exactly those three changes. Drawing a fresh set of plans is cheap. Sending builders is expensive. So you compare on paper and act only where the paper disagrees. That is the entire idea, and it is also why the honest answer to "is it faster?" is more interesting than people expect. ## 2. The Core Idea 📌 **Interview term: Virtual DOM** — a lightweight

The problem

Question presented to candidate: "What is the Virtual DOM, and why does React use one?"

What a strong answer should cover:

A lightweight in-memory representation of the UI, made of plain objects (React elements). It is not a browser feature and not a copy of the DOM.
On each render React builds a new tree, diffs it against the previous one (reconciliation), and applies only the differences to the real DOM.
Why: real DOM operations are expensive relative to object comparison, and touching it triggers layout and paint.
The honest framing: it is not faster than optimal hand-written DOM code. Diffing is extra work vanilla code skips. What it buys is making the declarative model fast enough to be practical.
The diffing heuristics that make it O(n): different element types mean discard and rebuild; keys identify children across renders.
Consequence of the type heuristic: changing an element's type unmounts the subtree and destroys its state.
Fiber is the implementation that made this interruptible; the Virtual DOM is the data model, Fiber is the scheduler.
Related but distinct: the shadow DOM is a browser encapsulation feature with no connection to this.

Clarifying questions expected:

"Do you want the concept, or the diffing heuristics?"

Code / implementation expected: Optional. Showing that an element is a plain object makes the point faster than prose.

virtual dom
performance
reconciliation
dom

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: Anyone preparing for a React interview — assumes basic components. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The reconciliation behaviour in section 5 was produced by actually swapping an element type on React 19.2.8 and observing what happened to the child state.

1. Why This Even Matters — A Story First

An architect wants three changes to a building. They do not demolish it and rebuild from the new plans. They lay the new drawings over the old ones, find the three differences, and send builders to make exactly those three changes.

Drawing a fresh set of plans is cheap. Sending builders is expensive. So you compare on paper and act only where the paper disagrees.

That is the entire idea, and it is also why the honest answer to "is it faster?" is more interesting than p

The solution is hidden so you can try first

6 min read · 9 sections

Try it in the playground

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

ReactElements are plain objects, and a type change destroys the subtree

Open in playground

import { useState } from "react";

function Counter() {
  const [n, setN] = useState(0);
  return (
    <button onClick={() => setN((v) => v + 1)}>
      clicked {n} times
    </button>
  );
}

// Two wrappers that render almost identical output — but they are DIFFERENT
// element types, which is all reconciliation cares about.
function DivWrapper({ children }) {
  return <div style={{ padding: 10, border: "2px solid #4f46e5", borderRadius: 8 }}>{children}</div>;
}
function SectionWrapper({ children }) {
  return <section style={{ padding: 10, border: "2px solid #16a34a", borderRadius: 8 }}>{children}</section>;
}

export default function App() {
  const [asSection, setAsSection] = useState(false);
  const Wrapper = asSection ? SectionWrapper : DivWrapper;

  // The element is just data — inspect it.
  const element = <Counter />;
  const shape = {
    typeofElement: typeof element,
    typeIsTheFunction: element.type === Counter,
    keys: Object.keys(element).join(", "),
    frozen: Object.isFrozen(element),
  };

  return (
    <div style={{ padding: 24, fontFamily: "system-ui", lineHeight: 1.6, maxWidth: 480 }}>
      <h4 style={{ marginTop: 0 }}>An element is a plain object</h4>
      <pre style={{ background: "#f6f6f6", padding: 10, borderRadius: 6, fontSize: 12 }}>
        {JSON.stringify(shape, null, 2)}
      </pre>

      <h4>Changing the wrapper TYPE destroys the child state</h4>
      <Wrapper>
        <Counter />
      </Wrapper>

      <p style={{ marginTop: 10 }}>
        <button onClick={() => setAsSection((s) => !s)}>
          swap wrapper to a &lt;{asSection ? "div" : "section"}&gt;
        </button>
      </p>

      <p style={{ color: "#666", fontSize: 13 }}>
        Click the counter a few times, then swap the wrapper. The count resets to
        zero — React saw a different element type, so it discarded the whole
        subtree and mounted a fresh one rather than trying to match it up.
      </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.