Next.js Interview Questions: App Router, Rendering, and Server Components

Next.js interviews build on top of React fundamentals, but add a layer of framework-specific questions around rendering strategy, routing, and where code actually executes. Since the App Router and Server Components represent the most significant architectural change in the React ecosystem in several years, they're also the area interviewers probe hardest — partly to test knowledge, and partly to see whether a candidate has kept up with the ecosystem rather than working with patterns from several years ago.

Why Next.js Interviews Differ From Plain React

A plain React interview tests component logic and rendering behavior in the browser. A Next.js interview adds a second dimension: where does this code run, and when? Server Components, Server Actions, middleware, and multiple rendering strategies all require a mental model of a request lifecycle that spans server and client — which is exactly the kind of thing interviewers like to probe, because it's easy to use Next.js productively without fully understanding it.

App Router vs. Pages Router

Interviewers want to know you understand the shift, even if a company's codebase still uses the Pages Router. Key differences to be ready to explain:

• File-based conventions changed: page.tsx, layout.tsx, loading.tsx, and error.tsx replace the older pages/ convention, with nested layouts supported natively.
• Server Components by default: in the App Router, components are Server Components unless explicitly marked "use client" — a reversal from the Pages Router, where everything rendered on the client by default (aside from getServerSideProps data fetching).
• Data fetching moved into components: instead of getServerSideProps/getStaticProps exported from a page, data fetching happens directly inside Server Components using async/await.

Rendering Strategies: SSR, SSG, ISR, and CSR

Be ready to explain each and, more importantly, when to reach for it:

• SSG (Static Site Generation): pages rendered at build time. Best for content that doesn't change per-request — marketing pages, blog posts, documentation.
• SSR (Server-Side Rendering): pages rendered on each request. Best when content is personalized or must reflect real-time data (a dashboard, a user-specific page).
• ISR (Incremental Static Regeneration): statically generated, but revalidated on a time interval or on-demand — a middle ground for content that changes occasionally but doesn't need to be rendered fresh on every single request.
• CSR (Client-Side Rendering): rendering happens in the browser after JS loads. Appropriate for highly interactive, client-only UI where SEO and first-paint speed matter less.

Server Components vs. Client Components

This is the single most-tested App Router concept. A strong answer covers:

• Server Components run only on the server, never ship their JS to the browser, and can directly access backend resources (databases, file systems, secrets) without an API layer in between.
• Client Components (marked "use client") are needed for interactivity — anything using useState, useEffect, event handlers, or browser-only APIs.
• Composition rule: Server Components can render Client Components, but Client Components cannot directly import and render Server Components — data has to be passed down as props (or as children) instead.

// This Server Component fetches data directly, no client-side JS shipped for this logic
export default async function PostList() {
  const posts = await getPosts();
  return (
    <ul>
      {posts.map((p) => (
        <PostCard key={p.id} post={p} />
      ))}
    </ul>
  );
}

Most App Router mistakes come from marking too much "use client" out of habit, which quietly drags the old client-heavy rendering model back into a framework designed to minimize it.

Data Fetching Patterns

Interviewers commonly ask about Server Actions — functions marked "use server" that let a client component invoke server-side logic (form submissions, mutations) without manually building an API route. Expect a follow-up on when you'd still reach for a traditional API route handler instead: typically when the endpoint needs to be called from outside the app itself, or needs to support methods/clients beyond your own frontend.

Caching is another frequent topic. By default, fetch requests inside Server Components are cached and deduplicated; understanding cache: "no-store" versus time-based revalidation (revalidate options) is a common practical question, since misunderstanding it is also a very common real-world bug source — stale data showing up in production because a fetch was cached longer than intended.

Performance Questions

• next/image handles responsive sizing, lazy loading, and format optimization automatically — know roughly what it's doing under the hood, not just that "it's faster."
• Streaming with Suspense lets parts of a page render and reach the client before slower data-dependent sections finish loading, improving perceived load time without blocking the entire page.
• Route-level code splitting happens automatically per route in the App Router, which is worth mentioning if asked how Next.js keeps bundle size manageable by default.

Common Practical Questions

• Middleware: runs before a request completes, commonly used for auth checks, redirects, or A/B test routing — know that it runs at the edge, before rendering begins.
• Dynamic routes: [slug] segments and generateStaticParams for pre-rendering dynamic paths at build time.
• Metadata API: generateMetadata for per-page SEO tags, replacing the older next/head pattern.

Mistakes to Avoid

• Marking a component "use client" reflexively instead of pushing interactivity as far down the tree as possible
• Confusing build-time (SSG) behavior with runtime (SSR) behavior when explaining a rendering strategy
• Not knowing that Server Components can be async directly, and trying to reach for useEffect data fetching patterns that belong to the old model
• Being unable to explain caching behavior when asked why data appeared "stale" in a hypothetical scenario

Preparing for the Interview

Beyond reviewing the concepts above, build (or revisit) a small App Router project that deliberately uses Server Components, a Server Action, and at least one dynamic route with generateStaticParams — working through it hands-on surfaces the small gotchas that reading documentation alone tends to skip over, and gives you real examples to reference instead of purely textbook ones.