How does React use keys in reconciliation? When do keys cause bugs?

WHAT THIS TESTS: Whether you understand that React keys are not decorative attributes but identity primitives used by the reconciliation diffing algorithm. The interviewer wants to know if you grasp sibling-scoped identity, state preservation versus DOM node reuse, and the difference between a remount and a re-render.

A GOOD ANSWER COVERS: First, that keys are only compared among siblings in the same array and tell React which element corresponds to which across renders. Second, that stable keys allow React to preserve component state and underlying DOM nodes when items move, which is the O(n) diffing optimization. Third, that unstable keys such as array indices or random values destroy this mapping, causing React to treat moved items as deletions and insertions or to incorrectly reuse DOM nodes. Fourth, the distinction between performance degradation from unnecessary remounts and state-related bugs from incorrect node reuse.

COMMON WRONG ANSWERS: Calling keys a performance optimization without mentioning identity or state preservation. Saying keys must be globally unique rather than unique only among siblings. Recommending Math.random as a key source, which guarantees remounting on every render. Claiming array indices are always safe, or conversely claiming they are always wrong, without noting that indices are only problematic when the list order changes or items are inserted and deleted. Describing the virtual DOM diff as operating on the entire tree rather than sibling arrays.

LIKELY FOLLOW-UPS: How would you key a list where items do not have natural unique IDs? What happens to refs and useEffect cleanup when a component is remounted because its key changed? How does React handle keys when fragments are involved? Can two sibling components share the same key if they are in different arrays?

ONE CONCRETE EXAMPLE: Imagine a todo list rendered with map where each row contains a text input and a delete button. If you use the array index as the key and delete the first todo, React sees that index zero now holds different data. Because the key stayed zero at that position, React reuses the existing DOM node and associated component state for the old first item. The second todo inherits the first input's focus, cursor position, and any uncontrolled value, while the deleted todo's state appears to persist in the wrong row. If the rows instead used stable database IDs as keys, React would correctly unmount the deleted row and shift the remaining ones without state pollution.

Source: react.dev