Next.js Interview Questions and Answers

The Pages Router (pages/) is the original file-based router. The App Router (app/) is the newer one, built on React Server Components. It is the best choice for new projects. Both can coexist during a migration.

Main benefit of the App Router: less JavaScript goes to the browser, because server components never send their code. Each route segment can also stream on its own. A route lives in a folder whose page.tsx makes it public.

What they are checking: Whether you know the mental-model shift to server-first rendering

In the App Router every component is a Server Component unless the file starts with the "use client" directive.

// app/page.tsx (server component)
import Counter from "./Counter";

export default async function Page() {
  const res = await fetch("https://example.com/api/items");
  const items: { id: number; name: string }[] = await res.json();
  return (
    <main>
      <ul>{items.map((i) => <li key={i.id}>{i.name}</li>)}</ul>
      <Counter />
    </main>
  );
}

// app/Counter.tsx
"use client";
import { useState } from "react";

export default function Counter() {
  const [n, setN] = useState(0);
  return <button onClick={() => setN(n + 1)}>{n}</button>;
}

Default to server components and push "use client" down to the small interactive leaves.

What they are checking: Whether you can decide which side a component belongs on

• SSG (static site generation): HTML is built once at build time and served from a CDN. Fastest and cheapest. Use for content that rarely changes (docs, marketing pages).
• SSR (server-side rendering): HTML is generated on every request. Use for per-user or always-fresh data (dashboards, search results).
• ISR (incremental static regeneration): a static page is served, then regenerated in the background after a time window or on demand. Use for large content sites where pages change occasionally (blogs, product pages).

In the App Router you do not choose with special functions. The mode follows what the route uses:

// ISR: regenerate at most every 60 seconds
export const revalidate = 60;

export default async function Page() {
  const res = await fetch("https://example.com/api/posts");
  const posts: { id: number; title: string }[] = await res.json();
  return <ul>{posts.map((p) => <li key={p.id}>{p.title}</li>)}</ul>;
}

Using request-time APIs such as cookies(), headers() or searchParams (or export const dynamic = "force-dynamic") makes the route dynamic (SSR). Static is the default when nothing forces dynamic rendering.

What they are checking: Whether you can map rendering strategies to real content types

In a Server Component you make the component async and fetch directly. No useEffect, no API route needed for your own data.

// app/products/page.tsx
interface Product { id: number; name: string }

async function getProducts(): Promise<Product[]> {
  const res = await fetch("https://example.com/api/products", {
    next: { revalidate: 300 },
  });
  if (!res.ok) throw new Error("Failed to load products");
  return res.json();
}

export default async function Page() {
  const products = await getProducts();
  return <ul>{products.map((p) => <li key={p.id}>{p.name}</li>)}</ul>;
}

• You can also call a database or ORM directly, since this code never reaches the browser.
• Fire independent requests in parallel with Promise.all to avoid waterfalls.
• Throwing triggers the nearest error.tsx; calling notFound() triggers not-found.tsx.
• For needs in the browser (polling, mutations, refetch by the user), use a Client Component with SWR or TanStack Query. For mutations, you can also use a Server Action.

What they are checking: Whether you fetch on the server first and avoid needless client fetching

Route Handlers create HTTP endpoints in the App Router. You use a route.ts file that exports functions named after HTTP methods. They replace Pages Router pages/api.

Wrap a folder name in square brackets to make a URL segment dynamic.

Export a static metadata object or an async generateMetadata function from a layout.tsx or page.tsx. Next renders the tags on the server.

next/image serves resized images in modern formats (WebP or AVIF where supported). It loads them only when needed, and keeps space for them to avoid layout shift (CLS).

They are special files in the App Router. They give each route segment shared UI and states with no extra setup.

Next loads variables from .env, .env.local, .env.development and .env.production (with .env.local for secrets, never committed).

• Vercel: zero-config, supports all features (ISR, middleware, image optimisation, edge).
• Node.js server: next build then next start on a VM, container or PaaS. Supports every feature.
• Docker: build an image, ideally using output: "standalone" for a small runtime image.
• Static export: output: "export"...

Hydration is the step where React attaches event handlers and state to HTML that the server already rendered. The user sees content immediately from the HTML, and the page becomes interactive once the JavaScript loads and hydrates.

In the Pages Router, page-level functions run on the server and pass props to the page component.

A route is static by default. It switches to dynamic rendering (per request) when it uses something only known at request time.

next/font downloads font files at build time and serves them from your own site (Google fonts or local). So there are no extra requests to a font CDN at runtime. It applies size-adjust fallbacks to avoid layout shift.

next/link renders an <a> and does client-side navigation: it fetches only the needed RSC payload and swaps the page without a full reload.

All three are async functions in next.config that return rules.

Common options:

Turbopack is Next.js's Rust-based bundler, designed to be faster than webpack through incremental computation: it recomputes only what changed. In Next 16 it is the default bundler for development and production builds. Webpack is still available with an opt-in flag.

Use a pyramid, adapted to server and client code.

Next 14 cached fetch results and GET route handlers by default, which surprised many teams. Since Next 15, fetch requests and GET route handlers are not cached by default, and you opt in.

The caching layers worth knowing:

• Request memoization: identical fetch calls during one render are de-duplicated.
• Data cache: persisted fetch results (opt in with next: { revalidate: n }, cache: "force-cache" or tags).
• Full route cache: the rendered HTML and RSC payload of static routes.
• Router cache (client): visited segments kept in the browser. In Next 15, page segments are no longer reused by default, so navigations are fresher.

Next 16 adds an opt-in model called Cache Components. You mark code with the "use cache" directive and control how long it lives with cache life profiles, instead of route-level flags. Dynamic data inside static shells is streamed with Suspense.

export default async function Page() {
  const res = await fetch("https://example.com/api/rates", {
    next: { revalidate: 3600, tags: ["rates"] },
  });
  const rates: Record<string, number> = await res.json();
  return <pre>{JSON.stringify(rates)}</pre>;
}

Tags let you clear the cache later with revalidateTag (in Next 16 it also takes a cache life profile as a second argument). Always check the docs for your exact version, since this area changes quickly.

What they are checking: Whether you know caching is opt-in now and understand the layers

Prefer an HttpOnly, Secure, SameSite cookie. Any JavaScript on the page can read localStorage. So one XSS bug (or a bad npm package) lets an attacker steal the token.

// app/api/login/route.ts
import { NextResponse } from "next/server";

export async function POST() {
  const token = "signed.jwt.value"; // issued after verifying credentials
  const res = NextResponse.json({ ok: true });
  res.cookies.set("session", token, {
    httpOnly: true,
    secure: true,
    sameSite: "lax",
    path: "/",
    maxAge: 60 * 60 * 24 * 7,
  });
  return res;
}

Also keep access tokens short-lived and use a refresh token. Check the signature on the server for every request. Set a strict Content Security Policy. For SSR apps, cookies are the natural choice since the server can read them during rendering.

What they are checking: Whether you understand the XSS versus CSRF choice, and pick cookies for SSR

Time-based: the data is considered fresh for N seconds, then refreshed on a later request (stale-while-revalidate).

// route-level
export const revalidate = 60;
// or per fetch
// fetch(url, { next: { revalidate: 60 } })

On-demand: you invalidate immediately when something changes, for example from a Server Action or a webhook route.

// app/actions.ts
"use server";
import { revalidatePath, revalidateTag } from "next/cache";

export async function publishPost() {
  // ... write to the database
  revalidateTag("posts", "max");  // tag-based; Next 16 takes a cache life profile as 2nd argument
  revalidatePath("/blog");       // or a specific route
}

Choose time-based when a delay is fine (price lists, blogs). Choose on-demand when users expect to see their own change at once (admin edits, CMS publish webhooks). Combine both: a long revalidate as a safety net plus on-demand invalidation for freshness. Tags are better than paths when many pages depend on the same data.

What they are checking: Whether you can keep data fresh without turning off caching

Server Actions are async functions that run on the server and can be called from forms or client code. They are marked with "use server". Next creates a POST endpoint for each one automatically.

Middleware runs before a request reaches a route. It can redirect, rewrite, set headers and cookies, or short-circuit with a response. It runs for the paths you match.

generateStaticParams tells Next which dynamic route values to pre-render at build time. It replaces getStaticPaths from the Pages Router.

Streaming sends the page's HTML in chunks as each part becomes ready, instead of waiting for the slowest query. The user sees the shell immediately and slow sections fill in later.

Use the server by default. Fetch on the client when the data depends on the browser or changes while the user is on the page.

They are folder conventions that shape routing without changing URLs in unusual ways.

Create a small Client Component that wraps the provider and shows children. Then use it in the (server) root layout. Server components passed as children stay server components.

You can choose the runtime per route or middleware.

• XSS: React escapes values by default. The risks are dangerouslySetInnerHTML, unsanitised markdown or HTML from users, and unsafe URLs (javascript:). Sanitise with a library such as DOMPurify and set a Content Security Policy.
• CSRF: cookie-based auth is exposed to cross-site requests. Use SameSite=Lax or...

The App Router uses React 19, so these are available:

Prefetch the query in a Server Component, dehydrate the cache, and pass it to a client-side provider with HydrationBoundary. The client component then reads the same query key and gets the data instantly, without a second request.

Find where the time goes before changing anything.

1. Check whether the route is rendered dynamically on every request when it could be static or cached. Look for cookies(), headers(), searchParams or cache: "no-store" forcing dynamic rendering.
2. Measure the server: log timing around each fetch and database call, or use OpenTelemetry. Look for slow queries, missing indexes and N+1 patterns.
3. Remove request waterfalls: start independent fetches together with Promise.all.
4. Cache what can be cached: revalidate, tags, or "use cache" in Next 16; a CDN in front for public pages.
5. Stream: wrap slow, non-critical sections in Suspense so the shell is sent immediately.
6. Reduce work in middleware and avoid heavy computation on the request path.
7. Check geography: server and database should be in the same region, and users far away should hit a CDN.
8. Check cold starts and memory limits on serverless platforms.

const [user, posts] = await Promise.all([getUser(), getPosts()]); // parallel, not sequential

Verify with real field data (Core Web Vitals, server timing headers), not only local runs.

What they are checking: Whether you follow a measurement-driven approach and know Next-specific causes

This is a caching question. Walk the layers from server to browser.

1. Static or ISR page: the page was generated earlier and revalidate has not passed. Fix with on-demand revalidation (revalidatePath or revalidateTag) after writes, or lower the interval.
2. Data cache: a fetch with force-cache or a long revalidate. Use tags and invalidate them, or cache: "no-store" for truly live data.
3. Full route cache and generateStaticParams: new slugs need dynamicParams true or a rebuild.
4. Router cache in the browser: soft navigation may show a previous payload. Call router.refresh() after a mutation, or use Server Actions which refresh automatically.
5. CDN or reverse proxy cache (Cloudflare, nginx): check Cache-Control and purge. Verify with curl -I and the x-nextjs-cache header (HIT, MISS, STALE).
6. Multiple instances with separate in-memory caches: a revalidation reached only one server. Use a shared cache handler.
7. Read-replica lag or a wrong environment variable pointing at old data.

curl -sI https://example.com/blog/post | grep -i -E "cache|age|x-nextjs"

Fix by deciding the freshness requirement per page, then invalidating explicitly on write.

What they are checking: Whether you can systematically debug stale data across caches

Hydration attaches React to server HTML. If the first client render produces different markup than the server did, React reports a mismatch.

Common causes:

• Values that differ between server and client: Date.now(), Math.random(), new Date().toLocaleString() (time zone and locale differ).
• Reading window, localStorage or navigator during render.
• Invalid HTML nesting, such as a <div> inside a <p>, which the browser repairs.
• Browser extensions injecting attributes, or inconsistent conditional rendering based on the user agent.

Fixes:

"use client";
import { useEffect, useState } from "react";

export function Clock() {
  const [now, setNow] = useState<string | null>(null);   // same on server and first client render
  useEffect(() => setNow(new Date().toLocaleTimeString()), []);
  return <span>{now ?? ""}</span>;
}

• Compute browser-only values in useEffect, so the first render matches.
• Use useId for ids, and pass stable data (like a server-generated timestamp) as props.
• Fix invalid nesting.
• Use suppressHydrationWarning only for unavoidable one-off text such as a timestamp.
• next/dynamic with ssr: false for components that cannot render on the server.

What they are checking: Whether you can reason about server versus client render output

Use layers, and put the real check next to the data.

Work from what Google sees to how the page is built.

First find the LCP element in Lighthouse or Chrome DevTools (usually a hero image or a big heading). Then remove what delays it.

Migrate incrementally, because both routers work in the same project. If a path exists in both, app/ wins, so move one route at a time.

Build in CI, not on the small server, and ship only the output.

Never render them all. Paginate or stream, and let the database do the work.

Put the variable part in a dynamic top-level segment and resolve it early.

Reduce the cost per request first, then restrict abusers, without blocking real users or search engines.

Stop building on the production machine, and shrink the build.