30 Next.js Interview Questions and Answers (2026)

Next.js shows up in more frontend and full-stack job postings every year, and the framework keeps moving fast enough that last year's interview prep is already out of date. The App Router, React Server Components, the use cache directive, and Partial Prerendering are all stable in Next.js 15 and 16, and interviewers are asking about them directly, not the Pages Router patterns that dominated guides written two or three years ago.

This guide collects 30 questions you are likely to be asked, grouped into five categories that roughly mirror how a real interview escalates: framework fundamentals, App Router conventions, the server/client component split, data fetching and caching, and performance plus advanced topics like PPR and Turbopack. Each answer is written the way you would actually say it out loud, not the way the docs phrase it, with code samples you can reference if you get asked to write something on a whiteboard or shared editor.

If you are setting up a fresh Next.js project to practice these concepts in, getting the tooling right first pays off. A solid Husky, Prettier, and lint-staged setup means you are not fighting formatting issues while you are trying to demo App Router patterns.

These are the questions that establish whether you understand what Next.js actually adds on top of React. They come up early in almost every interview, often as a warm-up before the conversation moves into App Router specifics.

Next.js is a React framework built by Vercel that adds server-side rendering, static generation, file-based routing, image optimization, and a full caching layer on top of React. Plain React is a UI library: it handles the view layer but leaves routing, data fetching, and rendering strategy entirely to you. Next.js makes those decisions configurable rather than something you build from scratch.

Companies prefer it because it ships production-ready defaults: SEO-friendly HTML output, optimized images out of the box, automatic code splitting per route, and a deployment model that works at the edge. For content-heavy or SEO-dependent products, like e-commerce, SaaS marketing sites, and editorial platforms, the performance advantages are measurable from day one rather than something you have to engineer in later.

The Pages Router is the original Next.js routing model, built around a /pages directory. The App Router, stable since Next.js 13.4, is the modern model built around /app, React Server Components, and a richer set of file conventions. Most production codebases still have Pages Router routes somewhere, so knowing both is expected at senior level even though new projects build on the App Router in 2026.

Next.js supports five rendering strategies, and knowing when to reach for each one is one of the most practical signals of real-world experience an interviewer can probe for.

In Next.js, the folder structure inside app/ (or pages/) directly determines the URL structure. You don't configure routes in a separate router file: the filesystem is the router.

Dynamic route segments are created by wrapping a folder name in square brackets, like [slug], [id], or [category]. The detail that trips people up in 2026: starting in Next.js 15, params is a Promise, so you must await it before reading any values.

generateStaticParams is the App Router equivalent of getStaticPaths from the Pages Router. It returns an array of parameter objects that Next.js uses to pre-generate static pages for a dynamic route at build time.

Reach for it whenever you want SSG for a dynamic route: blog posts at /blog/[slug], product pages at /products/[id], documentation pages at /docs/[...path]. Without it, dynamic routes render on demand per request, which behaves like SSR. With it, Next.js pre-builds every page at deploy time and serves each one straight from a CDN. You can combine it with revalidate to get ISR behavior: static pages that quietly regenerate in the background after a set interval.

Next.js handles SEO at several layers at once, which is exactly why it tends to outrank single-page apps built without a framework's help.

next/image is a built-in component that wraps the HTML <img> tag with automatic optimization: it converts images to modern formats like WebP and AVIF (typically 20 to 40 percent smaller than JPEG), resizes images to the size they're actually rendered at, lazy-loads anything below the fold, and reserves layout space before the image loads so the page doesn't jump around as it finishes loading.

That last point is the one interviewers care about most. Cumulative Layout Shift (CLS) is a Core Web Vitals metric that directly affects Google ranking, and unoptimized images are one of the most common causes of a bad CLS score.

Once an interviewer knows you understand the basics, the conversation usually moves to the App Router's file conventions: layouts, loading and error states, route groups, parallel routes, and middleware. These questions test whether you've actually built something with the App Router, not just read about it.

page.tsx defines the unique content for a specific route. layout.tsx defines the persistent shell that wraps one or more pages. The detail that matters most: layouts do not re-render when you navigate between child routes. They stay mounted and keep their state, which is exactly why shared UI like navbars, sidebars, and tab bars belongs in a layout. It doesn't flash or reset on navigation.

app/layout.tsx is the required root layout and must include <html> and <body> tags. Inner layouts, like app/dashboard/layout.tsx, just return their children; they don't need html/body of their own.

loading.tsx renders instantly while a page's async data is being fetched. Next.js automatically wraps the page in a Suspense boundary using this file as the fallback, so you get streaming with zero extra configuration: just create it alongside any page.tsx.

error.tsx catches runtime errors thrown during rendering or data fetching within its route segment, acting as a React error boundary. It must be a Client Component, since error boundaries rely on client-side lifecycle behavior, and it receives two props: error (the thrown Error object) and reset (a function to retry rendering the segment).

Any folder in app/ can have its own layout.tsx, and Next.js composes them automatically from outermost to innermost. For a route like /dashboard/settings, three layers stack: the root layout (app/layout.tsx), the dashboard layout (app/dashboard/layout.tsx, which provides the sidebar and top nav), and finally the page content itself.

Navigate from /dashboard/overview to /dashboard/settings and only the page content re-renders. The dashboard layout stays mounted, so the sidebar doesn't flash, and the root layout stays mounted too, so there's no full page reload. That's a meaningful UX improvement over the Pages Router, where persisting a layout meant manually engineering it inside _app.tsx.

Route groups are folders wrapped in parentheses, like (marketing) or (auth). They let you organize routes under a shared layout without adding the folder name to the URL.

Parallel routes let you render multiple pages simultaneously within the same layout. They're defined by folders prefixed with @, like @modal or @sidebar, and these slots get passed to the parent layout as props.

The most common use case is intercepted route modals: clicking a photo opens it in a modal overlay while the URL changes to /photos/42, navigating directly to that URL shows the full photo page, refreshing on the modal URL shows the full page rather than the modal, and closing the modal returns you to the previous page without losing scroll position. Parallel routes combined with intercepting routes is how Next.js implements that Instagram-style modal pattern without hand-rolled client-side state management.

Middleware is code that runs on every request before it reaches a page or API route, operating at the edge before any rendering happens. Typical uses include authentication redirects, role-based authorization, A/B testing rewrites, locale-based redirects for internationalization, and adding security headers to every response.

In Next.js 15 and earlier, this lived in middleware.ts at the project root. In Next.js 16, the file was renamed to proxy.ts. The reasoning: the file operates at the network proxy layer, not inside the React rendering pipeline, and the new name makes that clearer. The API itself is identical; only the filename changed.

This is where interviews tend to separate candidates who have shipped App Router code from candidates who have only read about it. The server/client boundary touches everything: data fetching, bundle size, hydration, and how you structure components day to day. If your background is heavier on the React internals side, how React's renderer decides what to re-render and when is a useful companion to the questions in this section, since RSC builds directly on those same rendering primitives.

Add "use client" the moment a component genuinely needs interactivity or browser access: useState, useReducer, or useContext; useEffect, useLayoutEffect, or useRef; event handlers like onClick, onChange, or onSubmit; browser APIs such as window, document, localStorage, navigator, or sessionStorage; or third-party libraries (animation, charts, drag-and-drop) that rely on any of those internally.

Avoid it when the component only fetches and displays data, receives everything it needs as props, or involves no user interaction at all. Every "use client" boundary adds JavaScript to the client bundle, and marking a purely display-oriented component as a Client Component sends unnecessary code to the browser, throws away the performance benefit of RSC, and makes the component ineligible for server-side data fetching.

The pattern that resolves almost every case: keep data fetching in a Server Component and pass the results as props to a thin Client Component that handles only the interactive part.

A hydration error happens when the HTML the server generated doesn't match what React renders on the client during hydration. React expects them to be identical so it can attach event listeners to the existing DOM without a full re-render; when they differ, it throws.

You pass data as serializable props. A Server Component can fetch data and hand it to a Client Component as plain JavaScript values: strings, numbers, booleans, arrays, and plain objects.

What you cannot pass: functions (they aren't serializable across the server/client boundary), class instances, React components as values rather than JSX, anything with circular references, or symbols. Trying to pass a non-serializable value triggers a serialization error at build time or request time, so for complex shapes, convert to a plain object before handing it across.

Suspense is a React feature that shows a fallback UI while waiting for an async operation to finish. In Next.js, it's the mechanism that powers streaming Server Components.

The payoff: users see meaningful content instantly instead of a blank screen, slow data fetches don't block fast ones, and the time to first byte stays low because the server doesn't have to wait on every fetch before sending anything. loading.tsx is really just syntactic sugar for wrapping an entire page in Suspense; reach for <Suspense> directly when you want component-level control.

Server Actions are async functions marked with "use server" that run on the server but can be called directly from Client Components. They're designed for mutations: creating, updating, and deleting data, and they replace the older pattern of standing up a POST API route just to handle a form submission or button click.

Caching is where Next.js interviews tend to get genuinely hard, and for good reason: it's where the framework's behavior is least intuitive and most consequential for production bugs. These six questions cover the explicit caching model that replaced the confusing implicit fetch caching of Next.js 13/14.

"use cache" is an explicit caching directive introduced in Next.js 15 and stable in Next.js 16. Placing it at the top of an async function, component, or file marks its return value for server-side caching. It exists specifically to replace the implicit fetch() caching from Next.js 13/14, which left most developers unsure when results were being cached or for how long. "use cache" makes caching explicit and predictable instead.

Both invalidate cached data and trigger a re-fetch, but at different levels of granularity. revalidatePath(path) invalidates everything cached for a specific URL path, which is the right call when a mutation only affects a single page. revalidateTag(tag) invalidates every cached entry carrying that tag, regardless of which URL it appears on, which is the right call when the same underlying data shows up across multiple pages.

ISR lets you generate pages statically at build time and then automatically regenerate them in the background after a set interval, without a full redeploy. The flow: a page is generated statically (at build time or on first request), an incoming request gets served the cached static version instantly, and once that cache expires, Next.js triggers a background regeneration so the next request gets the freshly built version. Users never wait on the regeneration; they always get a fast static response.

On-demand ISR via revalidateTag is generally preferred in production, because time-based ISR regenerates pages even when nothing changed, while on-demand regenerates only when your CMS or database actually has new content to serve.

Both run on the server, but they exist for different reasons.

Next.js 15 and 16 ship with four distinct caching layers, and being able to explain which layer is responsible for a given behavior, and how to invalidate it, is one of the most reliable signals of senior-level mastery an interviewer can check for.

Next.js 15 made four previously synchronous APIs asynchronous: params, searchParams, headers(), and cookies(). You now have to await all four.

The reasoning behind the change: accessing these synchronously meant the response had to wait until the values were available. Making them asynchronous lets Next.js start streaming the page before all of the request data has resolved, which improves both time to first byte and overall streaming performance.

The last stretch of a Next.js interview, especially for senior roles, often turns to the newest parts of the framework: Partial Prerendering, Turbopack, deeper next/image mechanics, and how to wire up authentication correctly across the server/client boundary.

PPR is a rendering strategy that removes the all-or-nothing static-versus-dynamic choice at the page level and moves it down to the component level instead. It went from experimental in Next.js 14 to the stable default in Next.js 16.

The mental model: everything outside a <Suspense> boundary is static and prerendered at build time, and everything inside one is dynamic and rendered at request time. Next.js serves the static shell from the CDN edge instantly, then streams the dynamic parts in as they resolve, all within a single HTTP response.

The result is CDN-speed time to first byte (often under 50ms) for the static shell, a fast LCP because the core product information ships in that shell, and dynamic data that's still fresh and personalized. Before PPR, a single dynamic component, like a cart count, forced the entire page into SSR mode and slowed down everything on it. PPR removes that tradeoff entirely: the cart can be dynamic inside its own Suspense boundary while the rest of the page stays static.

Turbopack is a Rust-based JavaScript bundler built by Vercel as a modern replacement for Webpack. It was introduced as experimental in Next.js 13 (next dev --turbo), became stable and opt-in by default for next dev in Next.js 15, and became the default bundler for everything, including next build, in Next.js 16.

next/image directly addresses two Core Web Vitals metrics. For LCP (Largest Contentful Paint), the priority prop tells Next.js to preload the hero or banner image instead of lazy-loading it; skip it and your LCP image loads late, which hurts the score. For CLS (Cumulative Layout Shift), next/image requires either explicit width and height or fill, which lets the browser reserve space before the image arrives. Zero layout shift from images means zero CLS contribution from them, while plain <img> tags without dimensions are a common cause of poor CLS.

Authentication in the App Router rests on three layers working together, and walking an interviewer through all three, in order, is usually the strongest answer you can give. If you're also handling provider keys or session secrets in the same project, it's worth pairing this with how Next.js environment variables actually reach the server versus the browser, since getting that boundary wrong is one of the most common ways auth secrets leak.

Use this as a final scan the night before an interview: if any row makes you pause, jump back up to that question's full answer.