What is the Virtual DOM and why does React use it?

WHAT THIS TESTS: Whether you understand the virtual DOM as a programming pattern that enables React's declarative API, not merely as a performance optimization. Interviewers want to see that you know reconciliation is the process of syncing an in-memory ideal representation with the actual DOM, and that you can distinguish this abstraction from direct imperative manipulation. They also want to know if you understand that React elements and internal fiber objects work together in this architecture.

A GOOD ANSWER COVERS: First, define the virtual DOM as an ideal or virtual representation of the UI kept in memory, synced to the real DOM by ReactDOM through a process called reconciliation. Second, explain that this enables a declarative API where you tell React what state you want the UI to be in, and React ensures the DOM matches that state, abstracting away manual attribute manipulation and event handling. Third, clarify that in React the term virtual DOM is usually associated with React elements, but internal objects called fibers also hold additional information about the component tree and enable incremental rendering. Fourth, contrast this with direct DOM manipulation where you imperatively mutate nodes yourself, which becomes error-prone and hard to synchronize as the application grows. Fifth, explain the performance angle correctly: React batches updates and computes the minimal set of DOM mutations, reducing layout thrashing and redundant reflows rather than making every individual DOM operation magically faster.

COMMON WRONG ANSWERS: Claiming the virtual DOM is faster because the real DOM is inherently slow or written in C++; the DOM is not the bottleneck in most cases, and the virtual DOM adds overhead of its own. Saying the shadow DOM and virtual DOM are the same thing; they are completely different technologies. Describing the virtual DOM as a single lightweight copy of the entire DOM without mentioning reconciliation or fibers. Asserting that React avoids the DOM entirely; React ultimately touches the real DOM, it just tries to do so minimally and efficiently.

LIKELY FOLLOW-UPS: How does React's diffing algorithm decide what to update? What are the trade-offs of the virtual DOM approach versus fine-grained reactivity in frameworks like Svelte? Can you explain how concurrent features in React 18 leverage the fiber architecture? When would direct DOM manipulation still be appropriate in a React app?

ONE CONCRETE EXAMPLE: Imagine a list of one thousand items where a single item changes. With direct DOM manipulation you might rewrite the entire list or manually track which node changed. React compares the new virtual DOM tree against the previous one, identifies exactly one changed item, and issues a single targeted update to the real DOM. If five items change in one event loop, React can batch those changes and apply them together in one pass rather than triggering five separate reflows.