Debug custom useQuery hook under interview pressure

The fixed useQuery aborts the previous request and ignores stale resolutions when the dependency array changes.

// THE BUG: the original hook had no AbortController and no active flag.
// When the user changed search query rapidly, an older request resolved
// after a newer one and overwrote the state with stale data. The fix is
// per-effect cancellation plus an active flag that ignores resolutions
// from any outdated effect.

type Result<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: Error };

export function useQuery<T>(
  key: string,
  fetcher: (signal: AbortSignal) => Promise<T>
): Result<T> {
  const [state, setState] = React.useState<Result<T>>({ status: 'idle' });

  React.useEffect(() => {
    const controller = new AbortController();
    let active = true;
    setState({ status: 'loading' });

    fetcher(controller.signal)
      .then((data) => {
        if (!active) return;
        setState({ status: 'success', data });
      })
      .catch((error: Error) => {
        if (!active || controller.signal.aborted) return;
        setState({ status: 'error', error });
      });

    return () => {
      active = false;
      controller.abort();
    };
  }, [key, fetcher]);

  return state;
}

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 { renderHook, waitFor } from '@testing-library/react';

describe('useQuery regression', () => {
  it('older request that resolves after a newer one cannot overwrite state', async () => {
    const calls: string[] = [];
    const fetcher = vi.fn(async (key: string, signal: AbortSignal) => {
      calls.push(key);
      // First call resolves slowly; second call resolves fast.
      const delay = key === 'a' ? 30 : 5;
      await new Promise((resolve) => setTimeout(resolve, delay));
      if (signal.aborted) throw new DOMException('aborted', 'AbortError');
      return { key };
    });

    const { result, rerender } = renderHook(
      ({ key }) => useQuery(key, (signal) => fetcher(key, signal)),
      { initialProps: { key: 'a' } }
    );

    rerender({ key: 'b' });
    await waitFor(() =>
      // The active flag and abort guarantee we land on the latest key,
      // not whichever finishes last.
      expect(result.current.status === 'success' && (result.current.data as any).key).toBe('b')
    );
    // Both fetches were initiated; the slow one was aborted before it
    // could write to state.
    expect(calls).toEqual(['a', 'b']);
  });
});

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?