Next.js Interview Questions With Model Answers

Routing is based on folders in app/. A folder is a URL segment, and it becomes public only when it has a page file or a route file. Dynamic segments use brackets, like [slug]. The files I use most are layout (shared UI that stays mounted), page, loading (a Suspense fallback), error (an error boundary that must be a Client Component), not-found, and route (an HTTP endpoint). I read the route table after next build to see what each route became.

In Next.js 15 and 16, params and searchParams are Promises, because their values may only be known when a request arrives. If I write params.slug without await, TypeScript reports that slug does not exist on type Promise<...>, and the build fails. I tested that. The PageProps<'/blog/[slug]'> helper gives the right type. Also, reading searchParams makes the page dynamic. A tutorial that uses params.slug directly is for an older version.

A layout wraps its pages and stays mounted when you navigate between them, so its state is kept and it does not re-render. A template looks the same, but it creates a new instance on each navigation. I proved the layout part with a counter button in the root layout: three clicks, a <Link> to another page, and the counter was still 3 with no new document request. A plain <a> caused a full reload and the counter went to 0. The cost is that a layout cannot react to navigation, which is why auth checks should not live there.

I start with a Server Component, since it is the default and sends no JavaScript for itself. It can read a database or a secret directly. I add 'use client' only for what needs state, effects, event handlers or browser APIs, and I make that part as small and as low in the tree as I can, so the rest stays on the server. The 'use client' line marks a boundary: everything that file imports also becomes client code. I pass data down as props, and I make sure the props are small and not secret.

No. A Client Component is also rendered on the server, to make the first HTML, and then hydrated in the browser. I checked: a Client Component printed a marker text, and curl showed that marker in the server HTML. So window and document cannot be used during the first render, even in a Client Component. The right names are "server" and "client" components, not "server-only" and "browser-only". Code that must run only in the browser goes in useEffect.

Props that cross from server to client must be serializable (plain data). A function is not. My test passed onClick={() => ...} from a page to a 'use client' button, and the build stopped with:

Error: Event handlers cannot be passed to Client Component props.  {onClick: function onClick}            ^^^^^^^^^^^^^^^^If you need interactivity, consider converting part of this to a Client Component.

The fix is to define the handler inside the Client Component, or to pass a Server Action (an async function with 'use server'), which is allowed because the framework turns it into a reference to an endpoint.

The build fails with a clear message. When I imported useState into a page with no 'use client', the output said: "You're importing a module that depends on useState into a React Server Component module. This API is only available in Client Components. To fix, mark the file (or its parent) with the "use client" directive." The fix is to move the stateful part into its own small Client Component. A Server Component cannot use state, effects or event handlers.

No. fetch is not cached by default. I tested with a counter route: I called the same route with a default fetch and with cache: 'force-cache' (a different query string for the second one, so request memoization could not hide the result). Over three page requests the counter showed:

default fetch n=1 | force-cache fetch n=2default fetch n=3 | force-cache fetch n=2default fetch n=4 | force-cache fetch n=2

The default fetch hit the API each time. The force-cache one stayed at 2. But a page that uses no request data is prerendered at build time, and then the plain fetch runs once and is frozen into the page (lesson 2). So "not cached" does not mean "runs for every visitor". Answers from the Next.js 13 and 14 days, where fetch was cached by default, are out of date.

If the same fetch (same URL and options) is called several times while one page renders, Next.js sends one real request. That is memoization, and it only lasts for that one render. It works for fetch. For a database call or any other function, I wrap it in React's cache() to get the same effect. I use it for the user lookup in a Data Access Layer (I counted one run for four calls) and for the post in generateMetadata and the page together (6 database calls became 3). It is per request, so it is not a cache shared between users.

In the default model, a route is static unless it uses request data (cookies(), headers(), searchParams, connection()), fetch is not cached unless I ask, and I control freshness with fetch options, unstable_cache and route settings such as revalidate and dynamic. With cacheComponents: true, the default flips: everything is dynamic unless I cache it with use cache and cacheLife. A page can have a static shell, cached parts and streaming parts (◐ in the build table). The build forces me to handle runtime data with Suspense. It also rejects the old dynamic export, which I confirmed. I would not flip the flag on an old project without reading the migration guide.

In dev, every page is rendered on demand. In production, a page that uses no request data is built once at build time, so new Date() or a plain fetch ran once and is frozen. I proved it: the same timestamp came back two seconds apart, while a force-dynamic page changed every time. The fix depends on what I want. I can make it dynamic (connection(), a request API, or no-store), give it a revalidate time, or move the changing part into a Suspense boundary. And I always test with next build and next start.

It makes the route static with Incremental Static Regeneration. After 60 seconds, the next request still gets the old copy and starts a rebuild in the background. The request after that gets the new copy. This is stale-while-revalidate. In my test with 5 seconds, I saw x-nextjs-cache go STALE, HIT, STALE, HIT, and the header Cache-Control: s-maxage=5, stale-while-revalidate=.... It is not a timer that rebuilds every 60 seconds. If nobody visits, nothing is rebuilt. For an instant refresh after a change, I use on-demand revalidation (revalidateTag).

redirect() works by throwing a special error. If I catch it, the redirect is swallowed. I tested a page like this:

try {  redirect('/somewhere-else')} catch (e) {  msg = 'caught: ' + (e as Error).message}

The page returned 200 and showed caught: NEXT_REDIRECT. No redirect happened. The same holds for notFound(), which also throws. The fix: call them outside the try, or rethrow the error (the docs have unstable_rethrow for this), or only catch what I expect. A related habit: call redirect() after the work that must happen first, because nothing after it runs.

A Client Component that reads useSearchParams() needs the query string, which does not exist at build time. If the page is prerendered and the component is not inside a <Suspense> boundary, the build fails. My real error was: useSearchParams() should be wrapped in a suspense boundary at page "/sp". The fix is to wrap that component in <Suspense fallback={...}>, so the rest of the page is built statically and only that part waits for the browser. Or, in a Server Component, I read the searchParams prop, which makes the page dynamic.

A Server Action is an async function marked 'use server'. I call it from a form or an event handler, and Next.js turns it into a POST endpoint behind the scenes. It is the best fit for changing data from my own UI: it works with forms and progressive enhancement, and I can revalidate caches right after it. A Route Handler (route.ts) is a real HTTP endpoint with a URL and methods. I use it when something else must call me: a webhook, a mobile app, a third party, or when I need a custom response, such as a file or a stream. Both are public doors, and both need their own auth check.

In Next.js 16, middleware was renamed proxy. The idea is the same: code that runs before a request is handled, so I can redirect, rewrite, change headers or answer directly. The file is proxy.ts at the project root, and it exports a function (default or named proxy) and an optional config.matcher. I tested a file still named middleware.ts. It worked, but the build printed The "middleware" file convention is deprecated. Please use "proxy" instead and suggested a codemod. According to the docs, the proxy uses the Node.js runtime. I keep it small and fast, since it also runs on prefetches.

No. A Server Action is a public POST endpoint. I captured the request from my button, and replayed it with curl and no cookie. The unsafe action deleted a document. The real action ID is visible in the page's network traffic. So inside every action I check login, check ownership, validate the arguments (they come from the browser), and return only what the caller needs. Next.js also checks that Origin matches Host for actions: a call with a fake Origin failed with "Invalid Server Actions request". That helps against CSRF, but it does not replace my checks.

I would use a signed session cookie that the server sets in a login Server Action: HttpOnly, Secure, SameSite=Lax, an expiry. A Data Access Layer (a server-only module) has a verifySession() wrapped in React cache(), and every read goes through it and returns small DTOs, not full rows. A proxy.ts does a fast optimistic redirect for logged-out users, and nothing else. Each Server Action and Route Handler calls the same DAL function. For documents, the DAL checks ownership, not just login. If I could, I would use a maintained auth library for the hard parts and keep these rules.

Layouts do not re-render on client-side navigation, so the check does not run for each page change. I tested it: I logged in, removed the cookie, and clicked a <Link> to a sibling page. The layout did not run again and the page showed its data. A full page load did redirect, which is why the bug is easy to miss. I would move the check into the data access function so it runs wherever the data is read. The docs say the same.

No. It only has the URL and the cookie, so it can only do an optimistic check, and it cannot tell that a document belongs to someone else. Its matcher can also miss routes, and it runs on prefetch requests, so it should not call the database. In my test it did well with bad input: an expired token, a token signed with another secret and an alg: none token were all refused. But I still check again next to the data. If I removed the proxy tomorrow, my data should still be safe.

In server environment variables, with no NEXT_PUBLIC_ prefix. A plain variable is undefined in the browser: I printed it from a Client Component and checked that the build output for the browser held zero copies. I add import 'server-only' to modules that use secrets, so the build fails if a Client Component imports them. I tested that and got an import trace. I keep .env*.local out of git, I never put a secret in a prop to a Client Component, and I do not log them.

Streaming means the server sends the HTML in chunks: first the shell (layout, static content and the <Suspense> fallbacks), then each part as it becomes ready. React sends each boundary's HTML with a small script that swaps out the fallback. I measured it: shell at 25 ms, a fast box at 320 ms, a slow box at 1,520 ms, with no content-length header. loading.tsx wraps the page in a Suspense boundary for me, with the file as the fallback. I prefer my own <Suspense> boundaries near the slow parts, so the fast parts show at once.

If notFound() is called inside a Suspense boundary, the stream has already started, so the 200 status is already sent. I tested two pages: notFound() before the boundary gave 404, and inside the boundary gave 200 plus <meta name="robots" content="noindex">, which Next.js adds to protect SEO. To get a real 404, I check that the resource exists with a fast query before the first Suspense boundary, then call notFound(). I can also reject early in proxy.ts or with config redirects.

No. Streamed content is server-rendered HTML, so crawlers get it. Two details matter. The status code is fixed once streaming starts (see Q23). And metadata: for HTML-limited bots such as Twitterbot, Next.js waits for generateMetadata and puts the <title> in the <head>. I measured it on a slow dynamic page: for Chrome the first byte came at 32 ms and the title came later in the body, and for Twitterbot the first byte came at about 820 ms with the title inside the head. So I keep generateMetadata fast.

I set metadataBase, a title template and defaults in the root layout. In each page I export generateMetadata, which returns the title, description, canonical and openGraph. Traps: without metadataBase, the build only warns and share images point to localhost. A page's openGraph replaces the layout's whole openGraph (shallow merge), so I lost og:site_name. A canonical set in the root layout would apply to every page. I use cache() so the page and generateMetadata share one query. And I add sitemap.ts, robots.ts and an opengraph-image.tsx, and check the real HTML with curl.

next/image serves a size that fits the screen and a smaller format (AVIF or WebP, chosen by the Accept header), lazy-loads, and reserves space with width and height. In my test, a 156 KB PNG came back as 4.5 KB AVIF at 640 px. Remote images need remotePatterns, and the optimizer refused an unknown width, a quality that was not allowed and an unknown host, each with 400. Missing sizes throw in dev but passed in my production build, so I check the dev console. next/font downloads fonts at build time and serves them from my site: the page made no request to Google, and a size-adjusted fallback font reduced layout shift. For the LCP image I use preload or fetchPriority="high". priority is deprecated.

NEXT_PUBLIC_ values are replaced inside the browser JavaScript at build time. If I built with one value and ran with another, the browser still has the build value. I tested it. I built with https://api.prod.example.com, started the server with a different URL, and the browser files still held the build-time one. The same happens with docker run -e. I fix it by passing the right value as a build argument (one image per environment), or by reading the value on the server at run time and passing it to the browser, or by serving it from a small API. I also remember that dynamic lookups like process.env[name] are not inlined (from the docs).

Three ways. next build then next start on any Node server, ideally behind a reverse proxy. The standalone output: a small folder with a server.js that I start with node, and I copy public and .next/static next to it. In my lab it went from a 402 MB node_modules to 67 MB. Or a Docker image, with three stages, a non-root user, HOSTNAME=0.0.0.0 and build args for NEXT_PUBLIC_ values. My image was 332 MB over a 238 MB base. Static export is a fourth way for sites that need no server features. I would set up a health route and error reporting through instrumentation.ts.

Three things, from the docs (I did not run it). The default cache is per instance, so revalidateTag on one does not reach the others unless I configure a shared cache handler. All instances need the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, or an action from one instance fails on another with "Failed to find Server Action". And rolling deploys need a deploymentId for version-skew protection. Also, any proxy or CDN in front must not buffer the response, or streaming looks like it is broken. For nginx, the header X-Accel-Buffering: no fixes that.

I go step by step with tools that Next.js gives me. First next build and the route table: is the route ○, ●, ƒ or ◐? Then curl -i: Cache-Control and x-nextjs-cache (HIT, MISS, STALE) tell me what the server thinks. Then the chunk timing: with curl -N or a short script I see when the shell and each Suspense part arrive, and whether a proxy buffers them. Then I check what is fetched in what order, looking for waterfalls and for the same query twice. For stale data, I ask whether the page is static, whether a revalidate or a tag is set, and whether the cache is per instance. I never test caching in next dev.