Explain list virtualization and when it beats React.memo

WHAT THIS TESTS: This question probes your understanding of the difference between render optimization and DOM footprint reduction. React.memo is a render-phase optimization that avoids reconciling unchanged components, but it does nothing to shrink the actual number of nodes in the document. Virtualization is a structural optimization that limits the number of mounted DOM nodes to a small sliding window. Interviewers want to see that you recognize when a problem is caused by excessive DOM size rather than excessive re-renders.

A GOOD ANSWER COVERS: First, explain the mechanism of virtualization. The list container has a fixed height and overflow handling. The library calculates which item indices fall inside the visible viewport based on scrollTop and the fixed or measured row height. It then renders only those items plus a small overscan buffer, say five rows above and below, to prevent blank flashes during fast scrolling. As the user scrolls, the component unmounts rows that leave the window and mounts new ones, often recycling the same component instances and DOM nodes to preserve identity and reduce garbage collection. Second, contrast this with React.memo. Memoization is valuable when a parent re-renders frequently and you want to avoid re-rendering every row, but every row still exists in the DOM. Third, describe the scenario where virtualization wins. When you have thousands or tens of thousands of rows, the browser must keep all of those nodes in memory, perform layout calculations across the entire subtree, and paint them even if they are off-screen. Virtualization caps these costs at the viewport size, so memory stays flat regardless of total list length.

COMMON WRONG ANSWERS: Claiming that React.memo reduces memory usage or improves scroll performance for huge lists. Memoized rows still consume memory and still participate in layout. Another red flag is describing virtualization as lazy loading or pagination. Lazy loading fetches data incrementally; virtualization assumes all data is already available and simply avoids rendering it. A third mistake is ignoring the trade-offs. A good candidate mentions that virtualization breaks native find-in-page, can cause focus issues, and requires fixed or measurable row heights for best performance.

LIKELY FOLLOW-UPS: The interviewer might ask how you handle dynamic row heights. You would answer that you can use a resize observer or measure rows after mount and cache the offsets. They might ask about accessibility and how you preserve keyboard navigation across a virtualized list. You could mention programmatic focus management and aria properties that communicate list size to screen readers. They might also ask how you would implement a virtualized grid instead of a list, which adds horizontal scroll position tracking and two-dimensional viewport culling.

ONE CONCRETE EXAMPLE: Imagine a trading dashboard showing 20,000 real-time market events. Wrapping each row in React.memo avoids re-rendering unchanged rows when new events append, but the browser still holds 20,000 DOM nodes. Scrolling becomes sluggish because the main thread spends milliseconds on layout and paint for the hidden subtree. Switching to react-window renders perhaps twenty-five rows at any moment. Scroll stays smooth at sixty frames per second, memory drops from hundreds of megabytes to a few megabytes, and the browser no longer throttles layout recalculations.