React interviews mix framework specifics — hooks, rendering, state — with JavaScript fundamentals that decide whether you actually understand what React is doing. Below are the most common questions with model answers. Senior: architecture, trade-offs, mentoring, and decision-making.
It runs only on the server, so it never ships JavaScript to the browser and can talk to a database directly, but it cannot hold state, use effects, or attach handlers. The real design work is drawing the boundary: interactive leaves stay client components, and everything above them can be server. Marking a component "use client" makes everything it imports client too, which is how bundles quietly stop shrinking.
INP measures the delay between an interaction and the visual response, so you look for long tasks on the main thread during interaction. The usual causes are a state update that re-renders a large tree, an expensive synchronous handler, and hydration still running. Tools are the Profiler and long-task entries; fixes are narrowing what re-renders, useTransition for non-urgent updates, and shipping less JavaScript.
A design system component owns appearance and interaction that must be consistent everywhere, and nothing about a specific feature. The moment it grows a prop named after a screen, the boundary has been crossed. The test is whether a second team could use it without reading the first team's code, and whether changing it is a coordinated release rather than a local edit.
It means the server HTML and the first client render disagree, and the causes are a short list: Date.now or Math.random during render, reading localStorage or window in the render path, locale or timezone formatting, and browser extensions rewriting the DOM. Reproduce with production rendering locally, then bisect by suspending parts of the tree. Suppressing the warning is the wrong fix — it leaves the two trees actually different.
It is right when several apps share components and you want one change reviewed and released across them, with the tooling — Turborepo or Nx — to keep builds incremental. It is overhead for one app with a couple of libraries, where you pay for cache configuration and CI complexity you do not need. The deciding question is whether cross-package changes happen weekly or twice a year.
Not as a project with its own deadline. Convert on touch: any component being changed for a feature gets rewritten, so the migration rides along with work that was happening anyway. Start with leaves rather than containers, since they have the least surrounding logic. Keep both styles working indefinitely and accept that some components never convert — the goal is a codebase that is easier to change, not a completed checklist.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior React Frontend interview →