Next.js Interview Questions

This lesson is about Next.js 16 and the App Router. For the React ideas underneath (Server Components, Suspense, streaming, hydration) see Frontend Depth, Lesson 02. For HTTP caching headers see Browser, Lesson 05. For login, sessions and cookies see Backend, Lesson 06. For React questions see Lesson 04. I read the Next.js docs that ship with version 16.3 and ran a small app on version 16.4 (Turbopack, cacheComponents on, output: "standalone"). Where a sentence says "I tested", it is real output from that app.

Words used in this lesson

• The App Router is the routing system in the app/ folder, built on React Server Components. The Pages Router is the older system in the pages/ folder (getServerSideProps, getStaticProps).
• A Server Component is a React component that runs only on the server and sends its result, not its code, to the browser. A Client Component is a component marked with "use client" that also runs in the browser, so it can use state, effects and browser APIs.
• The RSC payload is the compact description of the rendered Server Component tree that Next.js sends so React can update the page.
• Prerendering is making HTML ahead of the request (at build time). The static shell is the part of a page that is known at build time, such as the layout and the fallbacks of <Suspense>.
• Partial Prerendering (PPR) is the default way Next.js renders a page when cacheComponents is on: a static shell is served at once, and the dynamic parts stream in afterwards.
• Cache Components is the Next.js 16 caching model, turned on with cacheComponents: true. Its main tool is the use cache directive.
• A cache tag is a label you attach to cached data so that you can throw that data away later.
• Stale-while-revalidate means: serve the old copy now, and fetch a fresh copy in the background.
• A Server Action is an async function marked "use server" that the browser can call, usually from a form. Next.js turns it into a POST request.
• Proxy (file proxy.ts) is code that runs before a request reaches your routes. It was called "middleware" before version 16.
• ISR (Incremental Static Regeneration) is rebuilding a static page in the background after it was first built.

App Router vs Pages Router

The Pages Router is still supported, and an app can use both while it migrates. New code should use the App Router. A strong answer says: "Layouts in the App Router stay mounted when you navigate, so they are not a safe place for per-request checks."

Server Components and Client Components

Rules to say out loud:

• Layouts and pages are Server Components by default. You add "use client" at the top of a file to start a client boundary: that file and everything it imports go into the browser bundle.
• Use a Client Component when you need state, effects, event handlers or browser APIs. Otherwise stay on the server: smaller JavaScript, direct access to databases and secrets.
• Props from server to client must be serializable (plain objects, arrays, strings, numbers, dates, Maps, Sets, promises, Server Actions). Functions and class instances are not.
• A Client Component can render Server Components passed as children. This keeps the heavy part on the server:

// app/page.tsx (Server Component)import Modal from "./ui/modal";   // "use client"import Cart from "./ui/cart";     // Server Component that reads the databaseexport default function Page() {  return <Modal><Cart /></Modal>;   // Cart is rendered on the server, Modal only opens and closes it}

• Context does not work in Server Components. Put the provider in a small Client Component that takes children.

import "server-only" at the top of a module makes the build fail if a Client Component imports it. It is a cheap safety net for data-access code.

Rendering modes in Next.js 16

Before version 16 you picked per route: static (SSG), dynamic (SSR), or ISR. With cacheComponents: true you stop picking per route. Next.js prerenders every route as far as it can, and each part of the page falls into one of three groups:

The result is called Partial Prerendering. In the build output, ○ means fully static, ◐ means static shell plus streaming parts, and ƒ means rendered on demand. My test page (one cached product list and one cookies() greeting inside <Suspense>) showed up as ◐ /, with Revalidate 1h and Expire 1d.

// app/page.tsxexport default function Page() {  return (    <main>      <h1>Shop</h1>                     {/* static */}      <Products />                       {/* cached with "use cache" */}      <Suspense fallback={<p>loading user</p>}>        <Greeting />                     {/* reads cookies(): dynamic, streams in */}      </Suspense>    </main>  );}

If you forget the <Suspense>, the build tells you. I read cookies() in a page without a boundary and got:

Error: Route "/bad": Next.js encountered uncached or runtime data during prerendering.Ways to fix this:  - [stream] Provide a placeholder with <Suspense fallback={...}> around the data access  - [cache] For uncached data (fetch, database calls): cache the access with "use cache"  - [block] Set `export const instant = false` to allow a blocking route

export const instant = false lets one route block on the server instead (it then shows as ƒ). Use it while you migrate, not as a habit.

Dynamic values need a decision

Math.random(), Date.now() and crypto.randomUUID() give a different value each time, so the build refuses to bake them into HTML. I wrote <p>{Math.random()}</p> and the build failed with "Next.js encountered the unstable value Math.random() while prerendering". The fixes: call await connection() first (render at request time, inside <Suspense>), cache the value with use cache, or render it in a Client Component.

Caching in Next.js 16

The layers

I proved the memoization row. A function wrapped in React.cache was used by both generateMetadata and the page. It ran once per request.

All server-side entries belong to one deployment. The cache key contains the build ID (or deploymentId), the function ID and the arguments. A new deploy starts with an empty cache.

use cache

use cache is a directive (a string at the top of a function or file) that tells Next.js to cache the return value of an async function or component. The arguments and any variables it closes over become the cache key. They must be serializable.

// lib/data.tsimport { cacheLife, cacheTag } from "next/cache";export async function getProducts() {  "use cache";  cacheLife("hours");        // always set a lifetime; the default is 5 min stale / 15 min revalidate  cacheTag("products");      // a label for on-demand invalidation  return db.product.findMany();}

cacheLife takes a profile name. These are the built-in profiles (from the docs):

A very short lifetime (the seconds profile, revalidate: 0, or expire under 5 minutes) keeps the entry out of the static shell, so it becomes a dynamic hole.

Rules that cause real bugs:

• Cached code cannot read cookies() or headers(). I tried and got: "cookies() can't be read inside "use cache". Read it outside the cached function and pass what you need as an argument." Read the value outside and pass it in. The value then becomes part of the key. For the rare case where you cannot, use cache: private lets you read request data and keeps the result only in the browser.
• Data for one user must never go into a shared cache without that user's id in the key.
• React.cache values set outside a use cache function are not visible inside it.

Invalidating: four functions

What I tested: after revalidateTag("products", "max") from a Route Handler, the next request still returned the old value, and the one after it returned the new value. After updateTag("products") in a Server Action, the very next read was fresh. Calling updateTag in a Route Handler returned HTTP 500: "updateTag can only be called from within a Server Action. To invalidate cache tags in Route Handlers or other contexts, use revalidateTag instead."

// app/actions.ts"use server";import { updateTag } from "next/cache";import { redirect } from "next/navigation";export async function createPost(formData: FormData) {  const post = await db.post.create({ data: { title: String(formData.get("title")) } });  updateTag("posts");              // the list page shows the new post right away  redirect(`/posts/${post.id}`);   // redirect throws, so call updateTag BEFORE it}

What stopped working with cacheComponents

The old route settings are replaced by use cache. I added export const dynamic = "force-dynamic" and the build said: "Route segment config "dynamic" is not compatible with nextConfig.cacheComponents. Please remove it." The same family (revalidate, fetchCache, dynamicParams) is not supported either. generateStaticParams must return at least one item (an empty array fails with "all generateStaticParams functions must return at least one result").

Dynamic params are Promises

Since version 15 (and with sync access removed in 16), params, searchParams, cookies(), headers() and draftMode() are asynchronous.

// app/blog/[slug]/page.tsxexport default async function Page(props: PageProps<"/blog/[slug]">) {  const { slug } = await props.params;  const { q } = await props.searchParams;  return <h1>{slug} {q}</h1>;}

PageProps, LayoutProps and RouteContext are global types created by next typegen (and by next dev and next build). The codemod npx @next/codemod@canary next-async-request-api . converts old code.

With Cache Components there is one more habit. If you await params at the top of a layout, the layout cannot be prerendered for unknown values. Pass the promise down and await it inside a <Suspense> boundary, so the rest of the layout stays in the static shell.

Route Handlers or Server Actions?

Notes: a route.ts cannot sit in the same folder as a page.tsx. GET handlers are not cached unless you opt in. With Cache Components a GET that uses no request data is prerendered, and you put use cache in a helper function, not in the handler body. Do not call your own Route Handler from a Server Component. Call the shared function directly.

Server Actions and security

A Server Action is a public POST endpoint. The directive hides the code from the browser, but anyone who can send the right POST can call it. What Next.js does for you: it compares the Origin header with the host (CSRF check, configurable with serverActions.allowedOrigins), caps the body at 1 MB by default, encrypts action IDs, removes unused actions from the client bundle, and encrypts closed-over variables. What it does not do: decide who the user is, or what they may do.

"use server";import { z } from "zod";const Input = z.object({ itemId: z.string().min(1) });export async function completeItem(raw: unknown) {  const session = await auth();                       // 1. authenticate  if (!session?.user) throw new Error("Unauthorized");  const { itemId } = Input.parse(raw);                // 2. validate the shape  const item = await db.item.findFirst({              // 3. authorize: own rows only    where: { id: itemId, ownerId: session.user.id },  });  if (!item) return { ok: false as const };  await db.item.update({ where: { id: item.id }, data: { completed: true } });  return { ok: true as const };                       // 4. return a small, safe shape}

Other facts interviewers like:

• The client sends Server Actions one at a time. Promise.all over actions does not run them in parallel.
• After a deploy, an open tab may call an action ID that no longer exists. The error is "Failed to find Server Action". Use rolling deploys and show a retry button.
• On several servers, set the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY on all of them. Otherwise one server cannot decrypt what another encrypted.
• Expected errors (validation) are returned, for example to useActionState. Unexpected errors are thrown and caught by error.tsx.

Proxy (formerly middleware)

middleware.ts is deprecated and renamed proxy.ts, and the exported function is proxy. The codemod is npx @next/codemod@canary middleware-to-proxy .. Proxy runs on the Node.js runtime, and you cannot set runtime in it. (To keep the Edge runtime you must keep the old middleware file.)

// proxy.ts (project root)import { NextResponse } from "next/server";import type { NextRequest } from "next/server";export function proxy(request: NextRequest) {  if (!request.cookies.get("session")?.value) {    return NextResponse.redirect(new URL("/login", request.url));  }  const res = NextResponse.next();  res.headers.set("x-from-proxy", "1");  return res;}export const config = { matcher: ["/dashboard/:path*"] };

I tested this. Without a cookie, /dashboard returned 307 with location: /login. With a cookie it returned 200 and the header x-from-proxy: 1. The build output listed ƒ Proxy (Middleware).

Things to remember:

• Without a matcher, proxy runs on every request, including _next/static and images. Always set one.
• The matcher must be a constant that can be read at build time.
• Proxy also runs on prefetches. Do optimistic checks only (read a cookie, decode a token). Do not query the database here.
• It is not a full security layer. Check again where the data is read (see the auth section).
• You cannot call revalidateTag in proxy.
• Good uses: redirects, locale detection, rewrites, simple header changes. Bad uses: heavy logic, database calls.

Streaming, loading.tsx and status codes

loading.tsx is a shortcut: Next.js wraps the page in a <Suspense> boundary and uses your component as the fallback. For finer control, use your own <Suspense> around the slow part so that the rest of the page is real content.

The status code problem. The HTTP status line is sent with the first byte. Once a fallback has streamed, the server has already said 200. I tested two pages: notFound() called straight in the page (before any await or <Suspense>) returned 404. notFound() called inside a <Suspense> child returned 200, and Next.js added <meta name="robots" content="noindex"> so that search engines do not index it. If you need a true 404 for SEO or monitoring, check that the resource exists before the response starts to stream.

Bots that cannot run JavaScript (for example social preview crawlers) are detected by their user agent. They get a fully rendered page and the metadata in <head>. You can tune this with htmlLimitedBots.

Metadata, images, fonts and scripts

Metadata. Export a metadata object (static) or an async generateMetadata function (dynamic) from a layout or page. Both work only in Server Components. If the page and generateMetadata need the same data, wrap the loader in React.cache so it runs once (my test confirmed this). Other files: sitemap.ts, robots.ts, opengraph-image.tsx. Remember a canonical URL (alternates.canonical) for pages with several URLs.

Images (next/image). It resizes, converts to modern formats, lazy-loads, and reserves space to avoid layout shift. Rules: give width and height (or fill with a positioned parent); set sizes for responsive images (without sizes the browser assumes full viewport width and may download too much); remote hosts must be allowed in images.remotePatterns. For the main image above the fold, use preload (version 16 deprecated priority) or loading="eager" with fetchPriority="high". Version 16 changed defaults: minimumCacheTTL is 4 hours (was 60 seconds), images.qualities is only [75], at most 3 redirects, and local images with query strings need images.localPatterns.

Fonts (next/font). Fonts are downloaded at build time and served from your own domain, with no request to Google at runtime and less layout shift.

Scripts (next/script). Strategies: afterInteractive (default), lazyOnload (idle time), beforeInteractive (only in the root layout, for critical scripts) and worker (experimental). Put analytics on lazyOnload or afterInteractive.

Environment variables

• Variables are server-only by default. A NEXT_PUBLIC_ prefix means "copy this value into the browser JavaScript at build time".
• Frozen at build. I built with NEXT_PUBLIC_API=build-time and started the server with NEXT_PUBLIC_API=run-time. Both the server output and the client showed build-time, and the string run-time was not in the build. To use one Docker image in many environments, do not use NEXT_PUBLIC_ for values that change. Read a normal variable on the server after await connection() (I got the runtime value that way), or fetch config from an API.
• Lookups such as process.env[name] are not inlined.
• .env files are read from the project root, not from src/. Commit .env.example, never .env.local.

Authentication patterns

A safe layering, taken from the Next.js guides:

1. Proxy for fast, optimistic checks (is there a session cookie?).
2. A Data Access Layer (DAL): server-only functions such as getCurrentUser() and getInvoice(id) that check the session and the permission, and return small DTOs (data transfer objects, plain objects with only the needed fields).
3. Checks in each Server Action and Route Handler.

Do not rely on a layout for security. Layouts do not re-render on navigation, and a layout does not stop the page below it from running. With Cache Components, reading the session is a runtime read: wrap session-dependent UI in <Suspense>, and pass a user id to use cache functions to cache data per user. For the token-versus-session decision see Browser, Lesson 02. Libraries such as Auth.js (NextAuth) or a hosted provider save time, but the DAL rule still applies.

ISR with Cache Components

With cacheComponents and partialPrefetching, ISR works like this: generateStaticParams lists the pages to build now. A visit to an unlisted URL gets the app shell at once, then Next.js builds the full page in the background and caches it for the next visitor. Time-based refresh comes from cacheLife, and on-demand refresh from tags. Awaiting params inside <Suspense> is what makes the shell possible.

Edge or Node, and where to deploy

• Version 16 recommends the Node.js runtime for almost everything. The edge runtime has fewer APIs, does not support ISR, and is not supported with Cache Components.
• Vercel gives the whole feature set with no setup (CDN, image optimization, ISR storage, rollbacks). Self-hosting (a Node server, Docker, or a Kubernetes cluster) supports all features too, but you own the cache, the CDN and the deploy process.
• output: "standalone" creates .next/standalone/server.js with only the files needed. Copy public/ and .next/static next to it. I ran next start with standalone on and got the warning: "next start" does not work with "output: standalone" configuration. Use "node .next/standalone/server.js" instead.
• On many servers: share the cache (a custom cacheHandler, or use cache: remote), set the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, set a stable deploymentId or build ID, and put a reverse proxy such as nginx in front.
• output: "export" makes plain static files, but you lose proxy, Server Actions, Route Handlers that need a server, and image optimization without a custom loader.

Bundle size

Run the analyzer: next experimental-analyze (Turbopack, experimental, available from 16.1) or @next/bundle-analyzer for Webpack. Look for large libraries inside Client Components. Fixes: move the code to a Server Component, move the "use client" boundary lower, load heavy widgets with next/dynamic, and import only what you use. Version 16 removed the First Load JS column from the build output because it was inaccurate with Server Components. Use Lighthouse or real-user data instead.

Errors, 404, i18n and testing

• error.tsx is an error boundary for a route segment. It must be a Client Component and receives error and retry. In 16.3 retry became stable: it re-fetches and re-renders the segment (the older reset only clears the error state). global-error.tsx handles errors in the root layout. not-found.tsx is shown by notFound() and for unknown URLs.
• Expected errors (a failed validation, a 404 from an API) are values you return or handle. Unexpected errors are thrown to error.tsx.
• i18n. Put the locale in the URL (app/[lang]/...), detect it from Accept-Language in proxy and redirect, and load a dictionary on the server. Await params to read lang.
• Testing. Unit-test pure functions and synchronous components with Vitest or Jest. These tools do not support async Server Components, so test those with end-to-end tests (Playwright). See Frontend Depth, Lesson 05.

Migration pitfalls (14 or 15 to 16)

Code review table

Interview questions

Key takeaways

• Where and when. Every part of a page is static, cached, or dynamic. <Suspense> marks the dynamic holes.
• Next.js 16 is dynamic by default. You opt in to caching with use cache, cacheLife and cacheTag. dynamic, revalidate and dynamicParams are not allowed with cacheComponents.
• Invalidation: updateTag (actions, immediate), revalidateTag(tag, "max") (stale-while-revalidate), revalidatePath, refresh.
• Request data is async (params, cookies(), headers()), and cached code cannot read it directly.
• Server Actions are public endpoints. Authenticate, validate and authorize inside each one.
• proxy.ts replaces middleware.ts, runs on Node.js, needs a matcher, and does only light checks.
• NEXT_PUBLIC_ is frozen at build. Secrets stay on the server, even out of Client Components.
• Streaming fixes the status line early. A mid-stream notFound() is a 200 with noindex.
• Self-hosting at scale needs a shared cache, a shared encryption key, a stable deployment ID and node server.js for standalone output.

What's next

Lesson 06: Node.js and Express Interview Questions. Next.js runs on Node, so we look at the event loop, streams, Express 5, security and graceful shutdown.