
In fresher Next.js interviews, the prompt is a small React product problem: choose the right route files, keep secrets on the server, add the minimum client JavaScript, handle missing data, and explain why one page should be static while another must be request-time.
Definitions alone do not prepare you for those prompts. Tie App Router, Server Components, caching, and Route Handlers to product tasks: "Build a product detail page", "Why did this hydration error happen?", "Where should this API key live?", or "Why is this dashboard showing stale data?"
If your React basics are shaky, pair this guide with GreatFrontEnd's React interview questions and the React Interview Playbook.
| Interview prompt | What the interviewer is checking | Common fresher mistake |
|---|---|---|
"Build /products/[id] and show a 404 for missing products." | Dynamic routes, params, server fetching, notFound(), metadata | Rendering a generic empty div instead of a route-level not-found state |
| "Add a cart button to a server-rendered product page." | Server/Client Component boundary | Marking the whole page as "use client" instead of isolating the button |
| "This page uses an API key. Where should the request happen?" | Secret handling and server-only code | Calling the private API directly from a Client Component |
| "Why does this date cause a hydration error?" | Server HTML must match initial client render | Rendering new Date() or Math.random() directly in shared markup |
| "Product prices changed, but the page still shows old data." | Caching, revalidation, dynamic rendering | Saying "clear browser cache" without checking Next.js data/server caches |
Use this structure for most answers:
page.tsx, layout.tsx, route.ts, generateStaticParams(), notFound(), redirect(), "use client", or fetch() options.For 2026 interviews, use App Router vocabulary by default. If the interviewer asks about pages/, getStaticProps, or getServerSideProps, answer it as Pages Router knowledge and then explain the App Router equivalent.
"A product detail page is server-rendered. Marketing wants it fast for SEO, but price and stock change every few minutes. How would you build it?"
Separate stable and volatile data. Product title, description, images, and SEO metadata can be cached or statically generated. Price and stock may need short revalidation, tag-based revalidation after catalog updates, or request-time fetching if showing stale values would be harmful.
The mistake is treating the whole page as one rendering mode. Next.js lets you split the problem: keep the mostly static shell fast, then choose explicit freshness rules for the data that changes.
"The product page is a Server Component, but the Add to Cart button needs click state. What do you do?"
Keep the page as a Server Component and move only the interactive button into a Client Component.
// app/products/[id]/page.tsxexport default async function ProductPage({params,}: {params: Promise<{ id: string }>;}) {const { id } = await params;const product = await getProduct(id);return (<><h1>{product.name}</h1><AddToCartButton productId={id} /></>);}
Do not move the whole route to the client. Put the client boundary at the smallest component that needs browser behavior.
"Should
/search?q=reactbe statically generated?"
Probably not as a fully static page for every possible query. The route can render a reusable shell, but results depend on searchParams, user input, ranking, and freshness. Explain whether the results should be fetched on the server for SEO/shareable URLs, on the client for highly interactive filtering, or through a mix.
Mention loading, empty, and error states. Search pages fail interviews when candidates only talk about routing and forget the UI states users will actually see.
"A logged-out user visits
/dashboard. Where should the redirect happen?"
If the server can know from cookies that the user is logged out, redirect before rendering protected UI. Depending on the app, that can happen in server route logic or Proxy for broad route gates.
Do not rely only on useEffect(() => router.push('/login')). That flashes protected UI and ships dashboard JavaScript to a user who should not see it.
"The server renders light theme, but the client reads
localStorage.themeand switches to dark during hydration. Why is React warning?"
The first client render does not match the server HTML. Fix it by making the initial render deterministic, delaying browser-only reads until after hydration, using a cookie-backed theme available to the server, or rendering a small client theme boundary that handles the mismatch intentionally.
The word "hydration" alone does not answer the question. Name the mismatch and fix the first render.
Next.js is a React framework for building web applications. It adds routing, server rendering, static generation, data fetching patterns, image optimization, metadata handling, API route handlers, and deployment conventions around React.
Plain React mainly gives you the UI layer. Next.js decides how routes are mapped to files, how pages are rendered, how data can be fetched on the server, and how the app is bundled and optimized.
Say why: If asked "Why use it?", give a product reason: server-rendered pages for SEO, route-based code splitting, safer server data access, built-in metadata, and deployment conventions. Avoid saying only "because it improves performance"; name which part improves and why.
Official reference: Next.js App Router docs.
React is a library for building component-based UI. Next.js is a framework that uses React and adds application structure.
In a React app built with Vite, you choose your own router, data fetching setup, rendering model, and deployment pattern. In Next.js, file-system routing, server rendering, code splitting, metadata, and production build behavior come with the framework.
The App Router is the modern Next.js router based on the app/ directory. It uses React Server Components, layouts, nested routing, loading UI, error boundaries, route handlers, and streaming.
For example, app/products/page.tsx maps to /products, and app/products/[id]/page.tsx maps to dynamic product pages.
What to mention in 2026: App Router is the default mental model for new Next.js work. The Pages Router still exists, but App Router answers should use page.tsx, layout.tsx, Server Components, Route Handlers, and cache/revalidation APIs instead of starting with getStaticProps.
File-based routing means the folder and file structure defines the URL structure. In the App Router, a route segment becomes public only when it contains a page.tsx or page.js file.
For example:
app/page.tsxabout/page.tsxblog/[slug]/page.tsx
This creates /, /about, and /blog/:slug.
page.tsx, layout.tsx, and template.tsx?page.tsx renders the UI for a route. layout.tsx wraps a route segment and its children, and it is preserved across navigation when possible. template.tsx also wraps children, but it creates a new instance on navigation, so state inside it is reset.
Use layouts for shared shells like navbars and sidebars. Use templates when each navigation should remount that wrapper.
Dynamic routes handle URLs whose segment values are not known ahead of time. In the App Router, a folder like [slug] captures a value and passes it through params.
export default async function BlogPost({params,}: {params: Promise<{ slug: string }>;}) {const { slug } = await params;return <article>{slug}</article>;}
Catch-all routes use [...slug], and optional catch-all routes use [[...slug]].
generateStaticParams()?generateStaticParams() tells Next.js which dynamic routes to generate at build time. It replaces getStaticPaths from the Pages Router.
For example, a blog can fetch all slugs during the build and return { slug } objects. Next.js then pre-renders those pages instead of waiting for a first request.
Official reference: generateStaticParams.
Server Components render on the server and do not send their component code to the browser. They are the default in the App Router.
Use them for reading files, querying databases, fetching data with secrets, rendering static content, and reducing client-side JavaScript. They cannot use browser-only APIs, event handlers, or hooks like useState.
How it appears in interviews: "Why can't I add onClick here?" or "Why is window undefined?" The answer is that the component is rendering on the server, not in the browser. Add a Client Component only for the interactive part.
Official reference: Server and Client Components.
Client Components are React components that can run in the browser. Add the "use client" directive at the top of the file to mark a client boundary.
Use Client Components for state, event handlers, effects, browser APIs, focus management, animations that require browser state, and interactive forms.
"use client"?Use "use client" when the component needs client-only behavior: useState, useEffect, useReducer, DOM events such as onClick, or APIs such as window and localStorage.
Do not add "use client" to every file. Once a file is marked as a Client Component, its imported child components are part of that client bundle unless separated by server boundaries. Keeping static and data-heavy UI on the server reduces shipped JavaScript.
Yes. A Server Component can render a Client Component and pass serializable props to it. This is the common pattern for mixing server-rendered data with small interactive widgets.
A Client Component cannot directly import a Server Component, because client code runs in the browser. You can pass a Server Component as children to a Client Component from a server parent.
In Server Components, you can use async components and fetch directly on the server:
export default async function Page() {const response = await fetch("https://api.example.com/products");const products = await response.json();return <ProductList products={products} />;}
In Client Components, fetch with a client-side library or a custom hook when the data depends on browser interaction, local state, or live updates.
Trap: Server-side fetch() in Next.js is not always the same as browser fetch(). Next.js can add caching and revalidation behavior on the server. If the page must always be fresh, say so explicitly with the relevant cache option or rendering choice.
Official reference: Fetching Data.
Static rendering prepares HTML ahead of time and can be served quickly. Dynamic rendering creates the response at request time, which is needed when output depends on request-specific data such as cookies, headers, search params, auth state, or uncached data.
A fresher-friendly rule: use static rendering for public content that can be reused, and dynamic rendering for personalized or request-dependent content.
ISR means Incremental Static Regeneration. It lets static output be refreshed after a configured time or after an explicit revalidation event.
In the App Router, do not treat ISR as only the older Pages Router revalidate option. You will see fetch() cache options, revalidatePath(), revalidateTag(), and, in newer Next.js 16 codebases, Cache Components APIs such as "use cache" and cache tags.
Next.js has multiple caches. Route output, cached async work, server fetch() results, and client navigation data can all have different freshness rules.
You may see server fetch() caching controlled with cache: "force-cache", cache: "no-store", or next: { revalidate }. You may also see Cache Components controlled with "use cache", cacheLife(), cacheTag(), and updateTag(). The interview answer should name the cache and the freshness rule instead of saying "Next.js caches it."
Debugging answer: Name which cache you suspect. "Is the stale value from browser HTTP cache, Next.js server data cache, generated route output, client router cache, or our own data library?" That question beats guessing at one cache blindly.
Official reference: Caching.
loading.tsx?loading.tsx defines loading UI for a route segment. Next.js can show it while the route or a nested part of the route is loading.
It supports streaming because the user can see part of the page while slower server work continues.
error.tsx?error.tsx defines an error boundary for a route segment. It catches uncaught runtime errors from that segment and lets you render a fallback UI.
In the App Router, error.tsx must be a Client Component because error boundaries use client-side React behavior.
not-found.tsx?not-found.tsx defines the UI for a route segment's 404 state. You can trigger it by calling notFound() from next/navigation.
Use it when the route exists but the resource does not, such as /blog/missing-slug.
Route Handlers let you create API endpoints inside the App Router using route.ts or route.js. They support HTTP methods such as GET, POST, PUT, and DELETE.
export async function GET() {return Response.json({ ok: true });}
They fit webhooks, BFF endpoints, auth callbacks, and server-only operations that the browser should not implement directly.
Server Functions are async server-side functions marked with the "use server" directive. In form submissions or mutation flows, they are called Server Actions.
For a fresher interview, explain the idea carefully: the browser submits data, but the trusted mutation logic runs on the server.
A Route Handler exposes an HTTP endpoint. Other clients can call it if they know the URL and have permission.
A Server Action is a server function integrated with React and Next.js for form and mutation flows. Use Route Handlers for external HTTP APIs and webhooks. Use Server Actions for app-owned mutations tied to UI flows.
SSR renders HTML on the server for each request. SSG creates HTML at build time. CSR sends a JavaScript app shell and renders mainly in the browser. ISR serves static output but regenerates it after revalidation.
Next.js can mix these patterns route by route and even within a route when streaming and caching are involved.
Hydration is the process where React attaches event handlers and client-side behavior to HTML that was already rendered on the server.
Server-rendered HTML can be visible before it is interactive. Client Components need hydration before clicks, inputs, and stateful behavior work.
Hydration errors happen when the HTML rendered on the server does not match what React expects on the client.
Common causes include rendering Date.now() or Math.random() directly in markup, reading window during server render, changing output based on browser-only state, invalid HTML nesting, or mismatched data between server and client.
How to fix it: Make the initial server and client render match. Move browser-only reads to an effect, pass server-known values through cookies or props, or isolate the unstable UI in a Client Component that renders a stable placeholder first.
next/link used for?next/link enables client-side navigation between routes. It avoids a full page reload and can prefetch route data when links are likely to be visited.
Use <Link href="/dashboard">Dashboard</Link> for internal navigation. Use a normal <a> for external links.
useRouter() used for?useRouter() is used in Client Components for programmatic navigation, such as redirecting after a user clicks a button or completes a client-side interaction.
In Server Components, use server-side helpers such as redirect() from next/navigation instead.
In the App Router, you can export a static metadata object or an async generateMetadata() function from a page or layout.
Use static metadata when the title and description are known. Use generateMetadata() when metadata depends on params or fetched data.
Official reference: generateMetadata.
next/image?next/image is Next.js's image component. It handles image sizing, optimization, lazy loading, and layout stability when used correctly.
Interviewers ask about it because images are among the largest page assets, and a framework image component can reduce layout shift and improve loading behavior.
next/font?next/font loads and optimizes fonts. It can self-host supported fonts and reduce layout shift by generating font-related CSS during the build.
Use it instead of manually adding third-party font <link> tags when possible, because font loading affects performance and visual stability.
Proxy is the modern name for what older Next.js versions called Middleware. A proxy.ts file can run before a request completes and can redirect, rewrite, set headers, read cookies, or respond early.
Use it for request-level logic such as auth redirects, locale routing, and header changes. Do not put heavy application logic there.
Auth nuance: Proxy runs before route rendering, so it works for broad request decisions. It is not a replacement for server-side authorization inside data access or mutations. If the dashboard route is protected, both the route and the backend operation should still enforce permission.
Official reference: proxy.js file convention.
Server-only environment variables are available to server code and should be used for secrets such as API keys. Variables prefixed with NEXT_PUBLIC_ are bundled for the browser and must not contain secrets.
The interview trap is treating every environment variable as secret. Anything sent to client JavaScript can be viewed by users.
Authentication involves a session cookie or token, server-side validation, and route protection. Server Components can read request data such as cookies, Route Handlers can implement auth callbacks, and Proxy can redirect unauthenticated users before rendering.
Avoid trusting only client-side checks. The server must protect sensitive data and mutations.
redirect() and client-side navigation?redirect() from next/navigation is used during server rendering or server logic to stop rendering and send the user to another route.
Client-side navigation with router.push() happens in a Client Component after browser interaction. Use the server redirect when the server already knows the user should not see the current route.
The standard production flow is to run next build, then host the generated server output on a platform that supports the chosen Next.js features. Vercel supports Next.js features directly, but Next.js can also run on Node-based hosts and other platforms with the right adapter or deployment setup.
Freshers should know that a static-only export cannot support every server feature. Server rendering, Route Handlers, Server Actions, and request-time data need a runtime.
Build one small app with public pages, a dynamic detail page, a form, a Route Handler, metadata, a loading state, and a protected dashboard. That is enough to discuss most junior Next.js topics.
Practice with a mini product catalog or blog: list page, detail page, search params, server-fetched data, a client filter, a form mutation, and a small auth gate.
Next.js supports multiple rendering patterns. A page might be statically generated, dynamically rendered, partially streamed, hydrated on the client, or driven by client-side data after the first load.
"use client" everywhereThis removes many benefits of Server Components. Add "use client" at the smallest boundary that needs browser behavior.
getStaticProps, getServerSideProps, and getStaticPaths belong to the Pages Router. In the App Router, learn Server Components, fetch() options, generateStaticParams(), generateMetadata(), Route Handlers, and cache revalidation APIs.
Server Components and Route Handlers can access secrets. Client Components cannot keep secrets because their JavaScript is sent to the browser.
Build a small product catalog:
/products lists products and has a loading state./products/[id] fetches a product on the server and calls notFound() when missing.AddToCartButton is the only Client Component on the detail page.POST /api/cart is implemented as a Route Handler or app-owned mutation path.When explaining the solution, say which parts run on the server, which parts hydrate, which data can be cached, and where secrets would live. That is the real interview signal.
Next.js fresher interviews become clearer when you explain each feature by execution location: server, client, build, or request boundary. That mental model prevents most wrong answers.
100+ React interview questions and answers, prepared by senior engineers and ex-FAANG interviewers. Updated for 2026 with React 19 coverage including Actions, Server Components, the use hook, and the React Compiler.
Brush up on fundamental JavaScript skills with these essential interview questions and answers. Perfect for freshers preparing for junior developer roles.