Q072: Designing Scalable Tables and Data Grids

What Interviewers Want To Evaluate

This question tests whether you can design dense data interfaces without melting the browser. Interviewers want virtualization, pagination, sorting, filtering, column resizing, sticky headers, keyboard access, selection, server/client trade-offs, and accessibility.

For senior roles, the strongest answer treats the grid as a product workflow and performance system.

Short Interview Answer

Scalable data grids need clear data ownership, server/client sorting and filtering decisions, virtualization for large row counts, accessible keyboard navigation, stable column definitions, selection model, loading and empty states, and measured rendering performance. The key trade-off is between rich spreadsheet-like interaction and browser cost. For large datasets, avoid rendering every row and push expensive operations to the server or a worker when appropriate.

Detailed Interview Answer

Tables look simple until users ask for sticky columns, 100,000 rows, column resizing, nested rows, bulk selection, exports, permissions, saved views, and keyboard navigation.

Before choosing a grid library, define:

row count
column count
data freshness
sort/filter location
selection behavior
accessibility requirements
export behavior
custom cell complexity

Virtualization

Virtualization renders only the visible rows and a buffer. This reduces DOM size and improves scroll performance. It adds complexity around row height, keyboard navigation, screen-reader behavior, sticky headers, and scroll restoration.

Virtualization is not always needed. For small tables, native semantic tables may be simpler and more accessible.

Server vs Client Operations

Client sorting and filtering are fast for small datasets and support instant interaction. Server operations are better for large datasets, permissioned data, and authoritative business rules.

The URL should often store sort, page, filters, and saved view identifiers.

Code or Design Example

type GridQuery = {
  page: number;
  pageSize: number;
  sort: "name" | "createdAt";
  direction: "asc" | "desc";
  filters: Record<string, string>;
};

The query contract keeps UI, URL state, and backend API aligned.

Accessibility Discussion

Native tables are accessible for simple tabular data. Highly interactive grids may need ARIA grid patterns, roving tabindex, keyboard shortcuts, focus restoration, and screen-reader testing.

Do not sacrifice accessibility just to get spreadsheet-like behavior.

Common Mistakes

A common mistake is rendering all rows and then trying to memoize out of the problem. Another is using a div-based grid without keyboard or screen-reader support.

Performance Discussion

Measure DOM node count, scroll FPS, filter latency, React commit time, layout cost, and memory usage. Watch custom cell renderers; one expensive cell multiplied by thousands of rows becomes a product problem.

Real Production Story

A table may work with 500 rows in development and fail with 80,000 customer records in production. The fix may require server pagination, virtualization, query debouncing, and export as an async job.

Senior Engineer Perspective

A senior engineer should describe data scale, operation ownership, interaction model, accessibility, and measurement before choosing a grid library.

Code or Design Example

For a senior interview, a data-grid answer becomes stronger when you model row identity and query behavior explicitly.

type RowId = string;

type SelectionState = {
  mode: "page" | "allMatchingQuery";
  selectedIds: Set<RowId>;
  excludedIds: Set<RowId>;
};

type GridColumn = {
  id: string;
  label: string;
  sortable: boolean;
  width?: number;
};

This prevents vague answers around bulk selection. Selecting all rows on the current page is not the same as selecting all rows matching the server query.

Lead Engineer Perspective

A lead should define grid standards: when to use native table, when to use the grid component, virtualization rules, query contracts, accessibility checklist, and export strategy.

Revision Notes

Scalable grids are not only UI components. They are data, interaction, accessibility, and performance systems.

Key Takeaways

For large tables, reduce DOM work, move authoritative operations to the server, and keep keyboard and screen-reader behavior intentional.

Follow-Up Questions

1. When should you virtualize?
2. When should sorting happen on the server?
3. How do filters map to URL state?
4. Why can custom cells hurt performance?
5. How do sticky columns affect layout?
6. How do you support keyboard navigation?
7. What is roving tabindex?
8. How should bulk selection work with pagination?
9. How do you export large data?
10. How would you debug slow table scrolling?

How I Would Answer This In A Real Interview

I would start with row count, column count, interactions, and data ownership. Then I would discuss server/client operations, virtualization, accessibility, URL state, custom cell cost, and measurement.