Debug React key stability under interview pressure

The fixed EditableList keys each row by item.id; uncontrolled input state and focus follow the row through reorders.

// THE BUG: the original list used the array index as the React key. After
// reordering, React kept the input nodes in their original positions and
// reused them for whichever row landed at that index — the user's typing
// snapped to the wrong row, and focus moved with the index, not the
// logical row. The fix uses the row id as the key.

type Item = { id: string; text: string };

export function EditableList({
  items,
  onMoveUp,
}: {
  items: Item[];
  onMoveUp: (id: string) => void;
}) {
  return (
    <ul aria-label="Editable list">
      {items.map((item) => (
        // Stable id — React preserves the input node, defaultValue, and
        // focus across reorders. Index would have been the bug.
        <li key={item.id}>
          <input defaultValue={item.text} aria-label={'row-' + item.id} />
          <button onClick={()=> onMoveUp(item.id)}>Up</button>
        </li>
      ))}
    </ul>
  );
}

Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.

import { describe, it, expect } from 'vitest';
import { render, screen, fireEvent } from '@testing-library/react';

describe('EditableList key regression', () => {
  it('uncontrolled input value follows the row through reorder', () => {
    const initial = [
      { id: 'a', text: 'Alpha' },
      { id: 'b', text: 'Beta' },
    ];
    let current = initial;
    let result: ReturnType<typeof render>;
    const onMoveUp = (id: string) => {
      const index = current.findIndex((row) => row.id === id);
      if (index <= 0) return;
      const next= [...current];
      [next[index - 1], next[index]]= [next[index], next[index - 1]];
      current= next;
      result.rerender(<EditableList items={current} onMoveUp={onMoveUp} />);
    };
    result = render(<EditableList items={current} onMoveUp={onMoveUp} />);

    const inputB = screen.getByLabelText('row-b') as HTMLInputElement;
    fireEvent.change(inputB, { target: { value: 'Beta-edited' } });
    fireEvent.click(screen.getAllByText('Up')[1]);

    // After reorder, "row-b" is now first; React preserved the input
    // node so the typed value is still on the same logical row.
    const stillB = screen.getByLabelText('row-b') as HTMLInputElement;
    expect(stillB.value).toBe('Beta-edited');
  });
});

Tests whether you debug from ownership and lifecycle instead of random dependency-array edits.

• State a hypothesis before changing code.
• Name what evidence would confirm the bug.
• Avoid broad rewrites unless the current API cannot express the behavior.

• Reproduce the failing sequence first.
• Inspect ownership boundaries: local state, props, effects, subscriptions, and server data.
• Patch the minimal broken boundary and add a regression test.

• A minimal patch reduces risk, but repeated lifecycle bugs often justify a small reducer or custom hook.
• Adding dependencies can silence lint warnings while still preserving the wrong ownership model.

• Double clicks and repeated submissions.
• Slow network responses arriving out of order.
• Component remount with stale persisted state.

• Failing interaction sequence.
• Out-of-order async response.
• Unmount cleanup.

• What would the code review comment say?
• What metric or log would show this in production?