Debug external store subscription under interview pressure

The fixed counter store returns the same snapshot reference until value actually changes; consumers go through useSyncExternalStore.

// THE BUG: the original code used useState + useEffect to mirror the
// external store, which is unsafe under concurrent rendering: two
// consumers in the same tree could land in different commits and render
// with different values (tearing). It also created a new snapshot object
// every getSnapshot call, which forced infinite re-renders. The fix uses
// useSyncExternalStore with a getSnapshot that returns referentially
// stable values.

type Counter = { value: number };

function createCounterStore() {
  let snapshot: Counter = { value: 0 };
  const listeners = new Set<() => void>();

  return {
    subscribe(listener: () => void) {
      listeners.add(listener);
      return () => listeners.delete(listener);
    },
    // Returning the same reference when value is unchanged is the
    // contract; React calls Object.is on consecutive snapshots.
    getSnapshot() {
      return snapshot;
    },
    getServerSnapshot(): Counter {
      return { value: 0 };
    },
    increment() {
      snapshot = { value: snapshot.value + 1 };
      listeners.forEach((listener) => listener());
    },
  };
}

export const counterStore = createCounterStore();

export function useCounter() {
  return React.useSyncExternalStore(
    counterStore.subscribe,
    counterStore.getSnapshot,
    counterStore.getServerSnapshot
  );
}

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

describe('useCounter regression', () => {
  it('two consumers in the same tree see the same value (no tearing)', () => {
    function Twin() {
      const a = useCounter();
      const b = useCounter();
      return (
        <span data-testid="twin">
          {a.value === b.value ? 'sync' : 'torn:' + a.value + ':' + b.value}
        </span>
      );
    }
    render(<Twin />);
    act(() => {
      counterStore.increment();
      counterStore.increment();
    });
    // The broken useState+useEffect implementation could land the two
    // consumers in different commits when paired with startTransition,
    // producing a torn render. useSyncExternalStore prevents that.
    expect(screen.getByTestId('twin')).toHaveTextContent('sync');
  });

  it('does not infinite-loop when getSnapshot returns the same reference', () => {
    let renders = 0;
    function Probe() {
      renders++;
      useCounter();
      return null;
    }
    render(<Probe />);
    expect(renders).toBeLessThan(5);
  });
});

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?