Next.js Interview Questions

Analogy categoryAnalogies

Next.js interviews at the mid-to-senior level rarely test syntax memorization; they probe whether you understand tradeoffs — when to use Server Components versus Client Components, how caching layers interact, and why a particular rendering strategy fits a given product requirement. The strongest answers explain the 'why' behind a choice, not just the 'how', and connect the decision back to user-facing outcomes like load time or data freshness.

🏏

Cricket analogy: It's like a captain being judged not on reciting the rulebook but on explaining why they set an attacking field on a fresh pitch versus a defensive one on a flat wicket in the death overs.

Rendering Strategy Questions

A classic question is: 'When would you choose Static Site Generation over Server-Side Rendering in the App Router?' The strong answer distinguishes based on data volatility and personalization: SSG (achieved by default when a page has no dynamic data access) suits content that's the same for every visitor and changes infrequently, like a blog post or marketing page, while SSR (triggered by using cookies(), headers(), or { cache: 'no-store' }) suits per-user or highly time-sensitive content like a personalized dashboard or a live stock ticker. A follow-up worth anticipating: 'What about content that's mostly static but needs periodic updates?' — the answer is Incremental Static Regeneration via revalidate, which serves cached HTML instantly while regenerating it in the background after the specified interval.

🏏

Cricket analogy: It's like choosing between printing match programs in bulk before the tournament (static, same for everyone) versus a live scoreboard app that must refresh every ball (dynamic, per-viewer state).

typescript

// SSG by default: no dynamic data access
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await fetch(`https://api.example.com/posts/${params.slug}`).then(r => r.json());
  return <article>{post.content}</article>;
}

// SSR: opting into per-request rendering
export default async function Dashboard() {
  const data = await fetch('https://api.example.com/me', { cache: 'no-store' }).then(r => r.json());
  return <div>Welcome, {data.name}</div>;
}

// ISR: cached but periodically refreshed
export const revalidate = 3600; // seconds

Server vs Client Components

A frequently asked question: 'How do you decide if a component should be a Server or Client Component?' The default in the App Router is Server Component, and the answer should walk through the specific triggers for opting into 'use client': needing useState/useEffect, browser-only APIs like window or localStorage, event handlers like onClick, or third-party libraries that themselves rely on React hooks. A senior-level nuance interviewers look for: Client Components can still be rendered on the server for the initial HTML (hydration), and the best pattern is pushing 'use client' boundaries as far down the tree as possible — wrapping just the interactive leaf (like a like-button) rather than making an entire page client-side.

🏏

Cricket analogy: It's like deciding which parts of a broadcast need a live commentator (interactive, client-side) versus which are just pre-recorded graphics packages (static, server-rendered) — you don't put a live mic on the entire broadcast, just the parts that need real-time reaction.

A great interview answer for 'why Server Components' ties it back to bundle size: code that never needs to run in the browser (data fetching, formatting, markdown rendering) shouldn't ship JavaScript to the client at all — Server Components literally never send their code to the browser.

Data Fetching and Caching Questions

Expect questions like 'What happens if two components on the same page fetch the same URL?' The correct answer references Next.js's automatic request deduplication within a single render pass: identical fetch() calls (same URL and options) are automatically memoized, so only one actual network request fires even if called from multiple components in the tree. Another common question, 'How would you invalidate cached data after a form submission?', tests whether you know revalidatePath() and revalidateTag() from next/cache, typically called inside a Server Action right after a successful mutation.

🏏

Cricket analogy: It's like a stadium's PA system announcing the score once and every section of the crowd hearing it simultaneously, rather than each stand sending a separate runner to check the scoreboard.

Request deduplication only applies within a single render pass on the server, and only for fetch() calls with matching URL and options — it does not deduplicate across separate user requests or non-fetch data access like a raw database client call, which you'd need to memoize yourself with React's cache() function.

Interviewers care about tradeoff reasoning (why SSG vs SSR vs ISR) more than API syntax recall.
SSG fits static, visitor-agnostic content; SSR fits personalized or highly time-sensitive data; ISR bridges the two via revalidate.
Server Components are the App Router default; opt into 'use client' only for state, effects, browser APIs, or event handlers.
Push 'use client' boundaries as far down the tree as possible to minimize shipped JavaScript.
Identical fetch() calls within a single render pass are automatically deduplicated by Next.js.
revalidatePath() and revalidateTag() are the standard tools for invalidating cached data after a mutation.
Deduplication and caching only apply to fetch(); raw database clients need manual memoization via React's cache().