When you render a list of items in React, why does each one need a key prop, and what can go wrong if you use the array index as the key?

technical-conceptual · Junior level · software-engineering

What the interviewer is really asking

Checks whether the candidate understands React reconciliation at a working level — that keys identify elements across renders — rather than treating the key warning as noise to silence.

What to say

• Explain that React uses keys to match elements between the old and new render so it can update, move, or remove the minimum number of DOM nodes instead of rebuilding the list.
• Say the key should be a stable, unique ID from the data (like a database id), unique among siblings — not necessarily globally.
• Describe the concrete bug with index keys: when items are reordered, inserted, or deleted, indices shift, so React reuses the wrong element and component state like an input's text or a checkbox can attach to the wrong row.

What to avoid

• Don't say keys are just there to make the console warning go away.
• Don't claim Math.random() is a fine key — a new key every render forces React to throw away and recreate the element each time, killing performance and state.
• Don't insist the index is always wrong; for a static list that never reorders it's acceptable, so show you know the actual condition.

Example answers

Strong: Keys let React's reconciliation tell which item is which between renders, so it only touches what changed. I use the record's id as the key. Index keys break when the list reorders — I've seen a typed-in form value jump to the wrong row after a sort, because React reused the element by position instead of by identity.

Weak: You add a key so React stops warning you in the console. I usually just put the index there since it's unique, and it works fine.