Their stack: Nx, AG Grid, TanStack

The three named tools in the JD where you don't have deep production experience. Over-prepare here. The bar isn't expert — it's "vocabulary fluent and ramps quickly." That's a few hours of reading away.

01Nx — monorepo & micro-frontend tooling

What Nx is, in one minute

Nx is a build system and dev toolchain for monorepos. It does three big things:

1. Project graph — analyzes your code to know which projects depend on which.
2. Affected commands — runs lint/test/build only on what changed since main, dramatically speeding CI.
3. Computation caching — caches the results of any task locally and (optionally) remotely so you never recompute the same work twice.

Vocabulary you must know

Common Nx commands

nx build my-app                    # build a project
nx test my-app                     # test a project
nx lint my-app

nx affected -t test                # run tests on affected projects
nx affected -t build --parallel=3

nx graph                           # visualize the project graph
nx g @nx/react:app web-frontend    # generate an app
nx g @nx/react:lib feature-orders  # generate a lib

Library types (a useful Nx convention)

Standard taxonomy you'll see in Nx workspaces:

• feature — smart components for a domain (orders, inventory)
• ui — dumb presentational components
• data-access — API calls, TanStack Query hooks, types
• util — pure utilities, no React

Module-boundary rules typically: feature can use anything, ui can use util only, data-access can use util, util imports nothing.

Likely questions

02AG Grid — enterprise data grid

What AG Grid is, in one minute

AG Grid is the de facto enterprise React data grid. It's built for scale: tens of thousands of rows with virtualization, complex column definitions, sorting/filtering/grouping, inline editing, and customization at every level. Comes in Community (free, MIT-ish) and Enterprise (paid, with extra features like row grouping, pivoting, master/detail).

Core mental model

Three things you give AG Grid:

1. Row data — the array of objects to display
2. Column definitions — how to render each column
3. Grid options — overall behavior (row models, selection, etc.)

Vocabulary

Tiny example

import { AgGridReact } from 'ag-grid-react';

const columnDefs = [
  { field: 'sku', headerName: 'SKU', sortable: true, filter: true },
  { field: 'name', headerName: 'Product', flex: 1 },
  { field: 'qty', headerName: 'Qty', editable: true },
  {
    field: 'status',
    headerName: 'Status',
    cellRenderer: StatusBadge, // custom React component
  },
];

<AgGridReact
  rowData={items}
  columnDefs={columnDefs}
  defaultColDef={{ resizable: true }}
  rowSelection="multiple"
  pagination
  paginationPageSize={50}
/>

The four things to know cold

1. Virtualization (default on)

AG Grid only renders rows visible in the viewport plus a buffer. That's why it can handle 100k rows. The cost: you can't rely on every row's DOM existing — measuring positions, attaching observers per row, etc. needs the grid API.

2. Row models

• Client-side — all rows loaded in memory. Simple, fast, only suitable up to ~50k rows depending on payload.
• Infinite — fetch chunks as you scroll. Good for large datasets where you don't need grouping/pivoting.
• Server-side (Enterprise) — fetch chunks, but supports grouping/pivoting/aggregation server-side. The right choice for very large ERP datasets.

3. Cell renderers and editors

Common pattern: build a small component for any cell that's more than text. Status pills, dropdowns, action buttons. Use React components via the grid's React adapter.

function StatusBadge({ value }) {
  const color = value === 'active' ? 'green' : 'gray';
  return <span className={`badge bg-${color}-200`}>{value}</span>;
}

4. Grid API for imperative actions

const onGridReady = (params) => {
  gridApiRef.current = params.api;
};

// Later:
gridApiRef.current.exportDataAsCsv();
gridApiRef.current.getSelectedRows();
gridApiRef.current.refreshCells({ force: true });

Likely questions

03TanStack Query — server state

What it solves

"Server state" is fundamentally different from client state — async, cached, can become stale, can fail, lives on the server. Treating it like client state (Redux store, useState) means you reinvent caching, deduplication, refetching, and stale handling badly. TanStack Query (formerly React Query) handles all of that.

Mental model

Every server resource has a query key (a serializable array). The library deduplicates fetches with the same key, caches the result, and re-uses it across all components that ask for it.

const { data, isLoading, error } = useQuery({
  queryKey: ['orders', { status: 'open' }],
  queryFn: () => fetchOrders({ status: 'open' }),
});

Key concepts

Mutations + optimistic updates

const queryClient = useQueryClient();

const updateOrder = useMutation({
  mutationFn: patchOrder,
  onMutate: async (newOrder) => {
    // optimistic: cancel in-flight, snapshot, set new
    await queryClient.cancelQueries({ queryKey: ['orders'] });
    const previous = queryClient.getQueryData(['orders']);
    queryClient.setQueryData(['orders'], (old) =>
      old.map(o => o.id === newOrder.id ? newOrder : o)
    );
    return { previous };
  },
  onError: (err, newOrder, context) => {
    queryClient.setQueryData(['orders'], context.previous); // roll back
  },
  onSettled: () => {
    queryClient.invalidateQueries({ queryKey: ['orders'] });
  },
});

Likely questions

const orderKeys = {
  all: ['orders'] as const,
  lists: () => [...orderKeys.all, 'list'] as const,
  list: (filters: Filters) => [...orderKeys.lists(), filters] as const,
  details: () => [...orderKeys.all, 'detail'] as const,
  detail: (id: string) => [...orderKeys.details(), id] as const,
};

retry: (failureCount, error) => {
  if (error.status === 404) return false;
  return failureCount < 3;
}

04Base UI — headless component primitives

The JD mentions "Base UI (where appropriate)". Base UI is the unstyled, accessible primitives library from the MUI team (it grew out of MUI Base / MUI's "headless" layer). Think of it as a competitor to Radix UI or Headless UI: it ships behavior + accessibility + keyboard handling for things like Dialog, Popover, Select, Tabs, Menu, Slider, Tooltip — but no styles. You bring the styles (Tailwind, CSS modules, whatever).

Why teams pick it

• Accessibility done right out of the box — focus trap, ARIA, keyboard nav.
• Total visual freedom — Tailwind users love this because there's nothing to override.
• Smaller surface area than full MUI — you ship only what you use.
• Composable, low-magic API — primitives are {Root, Trigger, Popup, ...} patterns you assemble.

Tiny example (Dialog)

import { Dialog } from '@base-ui-components/react/dialog';

<Dialog.Root>
  <Dialog.Trigger className="btn">Open</Dialog.Trigger>
  <Dialog.Portal>
    <Dialog.Backdrop className="fixed inset-0 bg-black/40" />
    <Dialog.Popup className="fixed top-1/2 left-1/2 -translate-x-1/2 -translate-y-1/2 bg-white p-6 rounded-lg">
      <Dialog.Title>Confirm</Dialog.Title>
      <Dialog.Description>Are you sure?</Dialog.Description>
      <Dialog.Close className="btn">Cancel</Dialog.Close>
    </Dialog.Popup>
  </Dialog.Portal>
</Dialog.Root>

Likely questions

05Routing — likely TanStack Router

The JD says "Modern routing solution" without naming one. Given they're already TanStack-aligned for Query, the most likely answer is TanStack Router. Worth knowing the basics either way; you can ask in stage 3.

Why TanStack Router gets picked

• Type-safe routes, params, and search params — end-to-end TS inference. useParams() and useSearch() return typed objects, not Record<string, string>.
• First-class search-param state — search params are validated, typed, and treated as proper state (not just URL noise). You can use useSearch() like you'd use useState.
• Route loaders — fetch data before a route renders, with built-in integration with TanStack Query (queryClient.ensureQueryData in a loader).
• File-based or code-based routing — pick your preference.
• Pending / error / not-found states are a first-class part of the route definition.

Mental shift from React Router

If you've used React Router v6/v7, the conceptual jump is small — nested routes, outlets, loaders, actions all map. The two big differences: TanStack Router is more aggressive about types (you'll feel it on every Link and navigate call), and search-params-as-state is a much bigger deal than React Router treats it.

Likely questions

06How they fit together at Omnesoft