Debug component API design under interview pressure

The fixed Select<V> exposes value + onValueChange and treats label as presentation only; option.value is the identity field.

// THE BUG: the original Select returned a synthetic event from onChange,
// forcing every caller to write event.target.value. It also accepted
// label as the value when the value prop was omitted, so two options
// with the same label silently shared selection. The fix exposes a
// typed value + onValueChange API and removes the label-as-value
// fallback.

type Option<V extends string> = { value: V; label: string; disabled?: boolean };

type SelectProps<V extends string> = {
  value: V;
  onValueChange: (next: V) => void;
  options: Option<V>[];
  ariaLabel: string;
};

export function Select<V extends string>({
  value,
  onValueChange,
  options,
  ariaLabel,
}: SelectProps<V>) {
  return (
    <select
      aria-label={ariaLabel}
      value={value}
      onChange={(event)=> onValueChange(event.target.value as V)}
    >
      {options.map((option) => (
        <option key={option.value} value={option.value} disabled={option.disabled}>
          {option.label}
        </option>
      ))}
    </select>
  );
}

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, vi } from 'vitest';
import { render, screen, fireEvent } from '@testing-library/react';

describe('Select API regression', () => {
  it('exposes the typed value, not the synthetic event', () => {
    const onValueChange = vi.fn();
    render(
      <Select
        ariaLabel="Status"
        value="open"
        onValueChange={onValueChange}
        options={[
          { value: 'open', label: 'Open' },
          { value: 'closed', label: 'Closed' },
        ]}
      />
    );
    fireEvent.change(screen.getByLabelText('Status'), { target: { value: 'closed' } });
    // Caller receives the typed value directly. The broken API forced
    // every site to dig into event.target.value and re-cast the type.
    expect(onValueChange).toHaveBeenCalledWith('closed');
  });

  it('uses option.value as the source of truth, not option.label', () => {
    const onValueChange = vi.fn();
    render(
      <Select
        ariaLabel="Plan"
        value="enterprise-2024"
        onValueChange={onValueChange}
        options={[
          { value: 'enterprise-2024', label: 'Enterprise' },
          { value: 'enterprise-2025', label: 'Enterprise' },
        ]}
      />
    );
    // Two options with the same label coexist because the value is the
    // identity field. The broken API picked by label and silently routed
    // both options to the same selection.
    fireEvent.change(screen.getByLabelText('Plan'), { target: { value: 'enterprise-2025' } });
    expect(onValueChange).toHaveBeenCalledWith('enterprise-2025');
  });
});

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?