Build a virtualized feed

A small VirtualFeed component plus a pure getVisibleRange function that decides what to mount based on scrollTop, viewportHeight, and overscan.

type FeedItem = { id: string; height: number };

// Pure logic that the React component (and tests) call. Decoupling math
// from DOM is what lets you assert correctness without rendering.
function getVisibleRange(
  items: FeedItem[],
  scrollTop: number,
  viewportHeight: number,
  overscan: number
): { startIndex: number; endIndex: number; offsetTop: number } {
  let runningTop = 0;
  let startIndex = 0;
  let offsetTop = 0;

  for (let index = 0; index < items.length; index += 1) {
    if (runningTop + items[index].height >= scrollTop) {
      startIndex = Math.max(0, index - overscan);
      offsetTop = runningTop - (index - startIndex) * (items[index].height || 0);
      break;
    }
    runningTop += items[index].height;
  }

  let visible = 0;
  let endIndex = startIndex;
  for (let index = startIndex; index < items.length; index += 1) {
    visible += items[index].height;
    endIndex = index + 1;
    if (visible >= viewportHeight + overscan * (items[index].height || 0)) break;
  }

  return { startIndex, endIndex, offsetTop };
}

type VirtualFeedProps<T extends FeedItem> = {
  items: T[];
  viewportHeight: number;
  overscan?: number;
  renderItem: (item: T) => React.ReactNode;
};

export function VirtualFeed<T extends FeedItem>({
  items,
  viewportHeight,
  overscan = 4,
  renderItem,
}: VirtualFeedProps<T>) {
  const [scrollTop, setScrollTop] = React.useState(0);
  const totalHeight = React.useMemo(
    () => items.reduce((sum, item) => sum + item.height, 0),
    [items]
  );
  const { startIndex, endIndex, offsetTop } = React.useMemo(
    () => getVisibleRange(items, scrollTop, viewportHeight, overscan),
    [items, scrollTop, viewportHeight, overscan]
  );

  return (
    <div
      // role=feed makes the live region semantics explicit. Each item is a
      // grouped article. Without these, screen readers cannot identify the
      // virtualized list as a feed of separate posts.
      role="feed"
      aria-busy={false}
      style={{ height: viewportHeight, overflow: 'auto' }}
      onScroll={(event)=> setScrollTop(event.currentTarget.scrollTop)}
    >
      <div style={{ height: totalHeight, position: 'relative' }}>
        <div style={{ transform: 'translateY(' + offsetTop + 'px)' }}>
          {items.slice(startIndex, endIndex).map((item, index) => (
            <article
              key={item.id}
              role="article"
              aria-posinset={startIndex + index + 1}
              aria-setsize={items.length}
              style={{ height: item.height }}
            >
              {renderItem(item)}
            </article>
          ))}
        </div>
      </div>
    </div>
  );
}

UI interview practice should behave like component documentation, not a static snippet. This uses the same isolation pattern as Storybook, Sandpack, CodeSandbox, and StackBlitz: editable source on one side, a sandboxed browser preview on the other. Edit the DOM code, run it, and verify focus, keyboard, pointer, and state behavior in the preview.

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

describe('getVisibleRange', () => {
  const items = Array.from({ length: 1000 }, (_, index) => ({
    id: 'item-' + index,
    height: 80,
  }));

  it('returns the correct slice for the top of the list', () => {
    const range = getVisibleRange(items, 0, 320, 2);
    expect(range.startIndex).toBe(0);
    expect(range.endIndex).toBeGreaterThanOrEqual(4);
    expect(range.offsetTop).toBe(0);
  });

  it('shifts the window when scrolled mid-list', () => {
    const range = getVisibleRange(items, 8000, 320, 2);
    expect(range.startIndex).toBeGreaterThan(95);
    expect(range.startIndex).toBeLessThan(105);
  });

  it('clamps overscan at the start', () => {
    const range = getVisibleRange(items, 100, 320, 50);
    expect(range.startIndex).toBe(0);
  });
});

Shows whether you can build components as interaction systems rather than visual boxes.

• Name the controlled and uncontrolled state.
• Define keyboard and focus behavior.
• Include loading, empty, disabled, and error states.

• Start with the accessibility role and interaction contract.
• Separate rendering slots from state management.
• Expose callbacks that describe user intent, not internal implementation details.

• A headless primitive is reusable but slower to consume.
• A product-specific component ships faster but can trap behavior in one use case.

• Focus after close, selection, deletion, or route change.
• Large datasets and slow network responses.
• Screen reader labels and live updates.

• Keyboard path through the primary workflow.
• A11y names, descriptions, and roles.
• State transition after slow or failed data load.

• How would this component be documented in a design system?
• What props would you refuse to expose?