Debug transition-driven filtering under interview pressure

The fixed FilteredList reads useDeferredValue on the filter side; the input stays controlled by the urgent state.

// THE BUG: an expensive filter re-ran on every keystroke against the
// urgent input value, blocking the input from rendering until the filter
// completed. The fix moves the filter behind useDeferredValue so the
// input is always responsive and the filtered list catches up under
// transition priority.

type Row = { id: string; label: string };

export function FilteredList({ rows }: { rows: Row[] }) {
  const [query, setQuery] = React.useState('');
  // Reading deferredQuery here means the filter never runs against the
  // most recent keystroke — it always uses the value from one stable
  // render ago. The input itself stays on urgent priority.
  const deferredQuery = React.useDeferredValue(query);
  const isStale = query !== deferredQuery;

  const filtered = React.useMemo(
    () =>
      rows.filter((row) => row.label.toLowerCase().includes(deferredQuery.toLowerCase())),
    [rows, deferredQuery]
  );

  return (
    <div>
      <input
        aria-label="Filter"
        value={query}
        onChange={(event)=> setQuery(event.target.value)}
      />
      {isStale && <span aria-live="polite">Updating…</span>}
      <ul style={{ opacity: isStale ? 0.6 : 1 }}>
        {filtered.map((row) => (
          <li key={row.id}>{row.label}</li>
        ))}
      </ul>
    </div>
  );
}

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';

const rows = Array.from({ length: 30 }, (_, index) => ({
  id: String(index),
  label: 'item-' + index,
}));

describe('FilteredList regression', () => {
  it('input value updates synchronously even while filter catches up', () => {
    render(<FilteredList rows={rows} />);
    const input = screen.getByLabelText('Filter') as HTMLInputElement;
    fireEvent.change(input, { target: { value: 'item-1' } });
    // Input reflects the new value in the same commit; the filter
    // catches up via useDeferredValue without blocking input render.
    expect(input.value).toBe('item-1');
  });
});

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?