The frontend round that is not about React

The answer they want is that z-index is not global. An element only competes with siblings inside its own stacking context, and a parent creates one the moment it gets position with a z-index, or transform, opacity below 1, filter, will-change, or isolation: isolate.

Which is why a modal with z-index: 9999 still renders behind a header: the modal sits inside a parent that has a transform on it, and the whole context is below the header\'s. No z-index inside that context can escape it.

• The fix is to move the element out of the context — a portal to body — or to remove whatever created the context.
• The tell of experience is saying transform creates one. Almost everybody knows about position; the animation-created context is the one that actually costs people an afternoon.

The centring is a warm-up — display: grid; place-items: center, or flex with both axes. What they are actually asking is the second half.

• Flexbox is one dimension. Content decides the sizes; you are distributing space along a row or a column. Reach for it for a toolbar, a list of chips, anything where the number of items varies and they should flow.
• Grid is two dimensions. The container decides the shape; children go into it. Reach for it for page layout, a card grid, or anything where things must line up across both rows and columns.

The sentence that lands: flex sizes from the content out, grid sizes from the container in. Then say where you have used each.

Style → layout → paint → composite. Which stage your change triggers is what decides whether an animation is smooth:

• Layout (also called reflow) — anything geometric: width, height, top, font-size, adding a node. The most expensive, because it can invalidate the whole subtree.
• Paint — color, background, box-shadow, border-radius. Skips layout, still costs.
• Composite only — transform and opacity. Handled on the compositor, off the main thread. This is why every smooth animation on the web is written with those two and not with left and top.

The other half is layout thrashing: reading a geometric property (offsetHeight, getBoundingClientRect) after a write forces the browser to flush layout synchronously. Do it in a loop and you have turned a list render into a freeze. Batch the reads, then the writes.

Four things, in the order they matter, and each one is checkable in a minute:

• Semantics first. A <button> is focusable, activates on space and enter, and announces itself. A <div onClick> does none of that, and no amount of ARIA fully fixes it. The best ARIA is the ARIA you did not need.
• Keyboard. Tab through the whole flow with the mouse untouched. Every interactive thing reachable, focus visible, order matching the visual order, and no trap — except in a modal, where a trap is exactly what you want, plus Escape to close and focus returning to the trigger.
• Names and state. Every control has an accessible name (a label, or aria-label when there is no visible text), and anything that toggles says so: aria-expanded, aria-pressed, aria-current.
• Contrast and motion. 4.5:1 for body text, 3:1 for large text and UI boundaries. Respect prefers-reduced-motion.

Then say how you check: axe or Lighthouse in CI catches the mechanical half, and the other half only shows up when you tab through it yourself.

The answer starts by naming what raw useEffect fetching does not give you, because that list is the reason libraries exist: no caching, no deduplication when three components ask for the same thing, no revalidation, no request cancellation when the inputs change, and race conditions when a slow early response lands after a fast late one.

• TanStack Query or SWR for server state. Key, fetcher, stale time — and the mental split that matters: server state is cached remote data with an owner elsewhere; client state is what the user is doing right now. Most state-management arguments are people using one tool for both.
• Stale-while-revalidate — serve the cached value instantly, refetch in the background, replace if it changed. Instant screens without lying for long.
• Optimistic updates — apply the change locally, keep the previous value, roll back on failure. Say the rollback part; that is what separates having read about it from having shipped it.
• Invalidation — the hard half. Which keys does this mutation invalidate? Getting that wrong is why a list does not refresh after a create.

And in the App Router the question shifts: fetching moves to the server component and the client library handles what stays interactive. Know which half you are talking about — R4 covers the server side.

The line to hold is test behaviour, not implementation. A test that asserts on internal state or a component\'s props breaks on every refactor and protects nothing.

• React Testing Library for components, queried the way a user finds things — role and accessible name first, then text, then data-testid as an admission of defeat. Queries by role also mean a component with no accessible name fails the test, which quietly enforces the previous question.
• MSW to intercept requests at the network layer rather than mocking the fetch call. The component stays untouched, and the same handlers serve the tests and local development.
• Playwright for the few flows that must never break — sign in, checkout, the thing that takes the money. Not for coverage.
• What not to write: snapshot tests of whole trees, which are updated without being read; and unit tests of components that only assert they rendered.

• How do you keep the bundle small? Route-level code splitting first, then measure before you optimise — a bundle analyser, and the one dependency that is a third of the bundle.
• Images. Correct format and size, explicit dimensions so they do not shift layout, lazy below the fold, eager and preloaded for the LCP element.
• What causes a bad CLS? Images without dimensions, fonts swapping, and content injected above what is already on screen.
• Forms. Validate on blur and on submit, not on every keystroke; show the error next to the field; keep the submit button enabled and explain the failure rather than disabling it silently.
• XSS on the frontend. Never build HTML from user input; if you must render HTML, sanitise it. dangerouslySetInnerHTML is named that way deliberately. A CSP is the seatbelt, not the fix.
• Browser support. Know what the product actually supports before you answer — the honest answer is "whatever our analytics say", not a list of browsers.