What is the purpose of React's key prop and index key risks?

WHAT THIS TESTS: This question probes your mental model of React's reconciliation algorithm, specifically how React distinguishes one component instance from another across renders. Interviewers want to know if you understand that keys are about identity and correctness first, with performance being a secondary benefit. They are checking whether you can predict state-related bugs caused by unstable identifiers.

A GOOD ANSWER COVERS: First, the purpose: keys give React a stable identity for each element in a list so it can track which items changed, were added, or were removed between renders. Second, state preservation: when a component has local state or DOM state like focus and input values, a stable key ensures React keeps that state attached to the correct data item rather than the position in the array. Third, the index problem: using the array index as a key is dangerous because the index is tied to position, not to the data item itself; if the list reorders, inserts, or deletes items, the same index now refers to different data, causing React to reuse the wrong component instance and its associated state. Fourth, the exception: indices are only acceptable when the list is static, never reorders, and items have no local state, though even then a stable ID is preferred.

COMMON WRONG ANSWERS: A major red flag is saying keys exist solely to improve rendering performance. Another is claiming array indices are fine for all lists without mentioning the reordering and state-corruption risks. Some candidates describe keys as unique IDs for CSS or accessibility, which confuses the key prop with HTML id attributes. Saying you do not need keys for small lists also signals a misunderstanding because the reconciliation behavior is the same regardless of list size.

LIKELY FOLLOW-UPS: An interviewer might ask what happens to uncontrolled inputs or useRef values when indices are used and the list reorders. They could ask how to choose a key when your data lacks a natural ID, such as generating one on creation or using a library like uuid. Another follow-up is whether keys should be globally unique or only unique within the list, where the correct answer is unique among siblings. You might also be asked how key changes can be used intentionally to force a component to reset its state.

ONE CONCRETE EXAMPLE: Imagine a todo list where each row is an input field with local state managed by useState. If you use the array index as the key and delete the first item, React sees that index zero still exists and reuses the component instance that was previously at index zero, now pairing it with the data from the former index one. The input value and any refs from the deleted first item survive on the wrong row, while the last item is destroyed and recreated. If each row instead uses the todo's stable database ID as the key, deleting the first item correctly destroys its component and shifts the others without state corruption.

Source: react.dev