Next.js interview questions

What a strong answer covers

• Describe the fundamental architectural shift: App Router uses React Server Components by default, Pages Router uses client-side React with optional server-side data fetching.
• Detail routing conventions: App Router uses folder-based routing with special files (`page.js`, `layout.js`), Pages Router uses file-based routing (`pages/*.js`).
• Discuss data fetching: App Router allows `async/await` directly in Server Components; Pages Router relies on `getStaticProps`, `getServerSideProps`, or client-side fetching.
• Highlight rendering paradigms: App Router emphasizes server-first rendering, Pages Router is client-first with SSR/SSG as enhancements.
• Provide scenarios for choice: App Router for new projects prioritizing performance, SEO, and modern React features; Pages Router for existing projects or simpler applications where its model is sufficient.

Where people lose the point

• ×Confusing the data fetching methods between the two routers (e.g., trying to use `getStaticProps` directly in an App Router Server Component).
• ×Not understanding the 'server-first' nature of the App Router and the implications for client-side JavaScript.
• ×Failing to mention the role of React Server Components as the foundation of the App Router.

What a strong answer covers

• Define Server Components: Rendered on the server, zero client-side JavaScript, can access server resources (database, file system), ideal for static/data-fetching parts of UI.
• Define Client Components: Rendered on the client after hydration, marked with `'use client'`, can use React Hooks, event listeners, and browser APIs, ideal for interactive UI.
• Explain the default behavior: Components in the App Router are Server Components by default.
• Discuss the 'use client' directive: How it marks a component and its children as Client Components.
• Provide use cases: Server Components for data display, SEO-critical content; Client Components for forms, carousels, stateful logic, browser API interactions.

Where people lose the point

• ×Incorrectly stating that Server Components cannot have any interactivity (they can pass props to Client Components that handle interactivity).
• ×Forgetting to mention the `'use client'` directive as the explicit marker for Client Components.
• ×Not understanding the performance implications: Server Components reduce client-side bundle size.

What a strong answer covers

• Explain that data fetching in the App Router primarily happens in Server Components using `async/await`.
• Provide a simple code example demonstrating an `async` Server Component fetching data using `fetch`.
• Detail the benefits: Data is fetched before the component renders, reducing client-side JavaScript, improving initial page load, and enhancing SEO.
• Mention that `fetch` is automatically memoized and de-duplicated by React, optimizing multiple fetches for the same data.
• Contrast with client-side fetching: No need for `useEffect` or state management for initial data.

Where people lose the point

• ×Attempting to use `useState` or `useEffect` directly in a Server Component for data fetching.
• ×Not mentioning the automatic caching and de-duplication of `fetch` requests in React Server Components.
• ×Failing to highlight the performance and SEO advantages of server-side data fetching.

What a strong answer covers

• Define `getStaticProps`: Fetches data at build time, generates static HTML, ideal for data that doesn't change frequently.
• Define `getServerSideProps`: Fetches data on every request, generates HTML at request time, ideal for dynamic, frequently changing data.
• Discuss performance: `getStaticProps` results in faster page loads (served from CDN), `getServerSideProps` has a slight delay due to server-side computation on each request.
• Address data freshness: `getStaticProps` data can be stale until re-build/revalidation; `getServerSideProps` always provides the freshest data.
• Mention SEO implications: Both are good for SEO as content is pre-rendered, but `getStaticProps` is generally preferred for static content due to speed.

Where people lose the point

• ×Confusing when the data is fetched (build time vs. request time).
• ×Incorrectly stating that `getStaticProps` cannot be updated without a full redeploy (ignoring ISR).
• ×Not considering the impact on server load for `getServerSideProps` on high-traffic pages.

What a strong answer covers

• Define ISR: A feature that allows you to update static pages after they've been built and deployed, without requiring a full site rebuild.
• Explain how it works: You specify a `revalidate` time (in seconds) in `getStaticProps`. When a request comes in after this time, the cached page is served, and a new page is generated in the background.
• Describe the problem it solves: It combines the benefits of SSG (fast, cached pages) with the ability to update content without redeploying, addressing the staleness issue of pure SSG.
• Discuss use cases: Ideal for e-commerce product pages, blog posts, or news articles where content updates periodically but not on every single request.
• Mention the fallback mechanism: How Next.js handles requests for pages that haven't been generated yet (e.g., `fallback: true` in `getStaticPaths`).

Where people lose the point

• ×Confusing ISR with SSR (ISR still serves static content initially).
• ×Not understanding that the `revalidate` time is a minimum, and the old page is served while the new one is being generated.
• ×Failing to explain the 'incremental' aspect – only specific pages are regenerated, not the entire site.

What a strong answer covers

• Explain automatic optimization: `next/image` automatically optimizes images by resizing, compressing, and serving them in modern formats (like WebP) based on the user's device and browser.
• Detail lazy loading: Images outside the viewport are lazy-loaded by default, improving initial page load performance.
• Discuss preventing layout shift: The `layout` prop (or `fill` in App Router) helps prevent Cumulative Layout Shift (CLS) by reserving space for the image before it loads.
• Mention responsive images: It generates multiple image sizes and uses `srcset` to serve the most appropriate image for the user's screen.
• List key benefits: Improved performance (faster load times), better SEO, reduced bandwidth usage, and enhanced user experience.

Where people lose the point

• ×Not mentioning the automatic format conversion (e.g., to WebP).
• ×Forgetting about the lazy loading feature as a default behavior.
• ×Failing to explain how it helps prevent layout shifts (CLS).

What a strong answer covers

• Define Middleware: Code that runs before a request is completed, allowing you to intercept and modify requests/responses.
• Explain its execution environment: Middleware runs on the Edge runtime, making it very fast and efficient.
• Describe common use cases: Authentication/authorization (checking user sessions, redirecting unauthenticated users), A/B testing, internationalization (rewriting URLs based on locale), logging, URL rewriting/redirects.
• Illustrate how it works: It's defined in a `middleware.js` file at the root, exports a default function that receives `NextRequest` and returns `NextResponse`.
• Mention configuration: How to specify which paths the middleware should apply to using `config.matcher`.

Where people lose the point

• ×Confusing Middleware with API routes (Middleware runs *before* the request reaches a page or API route).
• ×Not mentioning its execution on the Edge runtime.
• ×Failing to provide concrete examples of its practical application.

What a strong answer covers

• Explain dynamic segments: Create folders with square brackets (e.g., `[slug]`) to define dynamic parts of a route.
• Provide an example: `app/blog/[slug]/page.js` would match `/blog/my-first-post` and `/blog/another-post`.
• Describe accessing parameters: In a Server Component, route parameters are available in the `params` prop (e.g., `params.slug`).
• Mention `generateStaticParams`: For dynamic routes with `generateStaticParams`, Next.js can pre-render pages at build time, similar to `getStaticPaths`.
• Discuss catch-all routes: Using `[...slug]` to match multiple segments, useful for nested dynamic paths.

Where people lose the point

• ×Confusing the `params` prop with query parameters.
• ×Not understanding the folder-based convention for dynamic routes in the App Router.
• ×Forgetting to mention `generateStaticParams` for pre-rendering dynamic routes.

What a strong answer covers

• Explain the `loading.js` file: Create a `loading.js` file inside a route segment to automatically show a loading state for that segment and its children.
• Describe its behavior: The `loading.js` component is rendered immediately when navigation to a new route segment begins, while the content of `page.js` is being fetched and rendered on the server.
• Detail the benefits: Provides instant feedback to the user, improving perceived performance and user experience by reducing blank screens.
• Mention streaming: It leverages React's Suspense for streaming UI, allowing parts of the page to load independently.
• Contrast with manual loading states: Automates the process, reducing boilerplate code compared to managing loading states with `useState` and `useEffect`.

Where people lose the point

• ×Confusing `loading.js` with a global loading spinner (it's scoped to its segment).
• ×Not understanding that it's displayed while server-side rendering is in progress.
• ×Failing to mention the improved user experience due to instant feedback.

What a strong answer covers

• Explain `error.js`: Create an `error.js` file within a route segment to define an error boundary for that segment and its children.
• Describe its functionality: It catches runtime errors in Server Components and Client Components, displaying a fallback UI and preventing the entire application from crashing.
• Detail `global-error.js`: A top-level error boundary that catches errors not caught by specific `error.js` files, including errors in the root `layout.js`.
• Mention the `reset` function: The `error.js` component receives a `reset` prop to attempt recovery from the error.
• Discuss benefits: Provides a graceful degradation experience, isolates errors to affected parts of the UI, and allows for user-friendly error messages.

Where people lose the point

• ×Confusing `error.js` with `global-error.js` and their respective scopes.
• ×Not understanding that `error.js` acts as a React Error Boundary.
• ×Failing to mention the `reset` function for error recovery.

What a strong answer covers

• Explain pre-rendering: Next.js's SSR and SSG capabilities ensure that page content is available as HTML to search engine crawlers, improving indexing.
• Discuss performance: Fast load times (due to optimizations like `next/image`, code splitting, and server rendering) are a significant ranking factor for SEO.
• Detail metadata management: Use the `metadata` object or `generateMetadata` function in the App Router to easily set title, description, and other meta tags for each page.
• Mention structured data: Implement JSON-LD structured data within Server Components to provide rich snippets in search results.
• Other optimizations: Ensure semantic HTML, create sitemaps, handle canonical URLs, and optimize image alt text.

Where people lose the point

• ×Only mentioning SSR/SSG without detailing *why* they benefit SEO (crawler accessibility).
• ×Forgetting to mention the built-in metadata API in the App Router.
• ×Not emphasizing the importance of performance as an SEO factor.

What a strong answer covers

• Define Route Groups: Folders wrapped in parentheses (e.g., `(marketing)`) that allow you to organize routes without affecting the URL path.
• Explain their purpose: Primarily used for organizing routes into logical groups, applying shared layouts to specific segments, or creating multiple root layouts.
• Provide a use case: For example, having a `(marketing)` group with its own layout for public pages and an `(app)` group with a different layout for authenticated user dashboards.
• Detail how they work: The parentheses make the folder name transparent in the URL, so `app/(marketing)/about/page.js` results in `/about`.
• Discuss benefits: Improved project organization, ability to create distinct UI experiences for different parts of an application, and better maintainability.

Where people lose the point

• ×Believing that route groups affect the URL path.
• ×Not understanding their primary use for organizing and applying specific layouts.
• ×Failing to provide a clear, practical example of their application.

What a strong answer covers

• Explain its purpose: `generateStaticParams` is used with dynamic route segments to pre-render pages at build time, similar to `getStaticPaths` in the Pages Router.
• Describe its functionality: It exports an `async` function that returns an array of objects, where each object represents the `params` for a dynamic route segment.
• Provide a use case: For a blog with `app/blog/[slug]/page.js`, `generateStaticParams` would return `[{ slug: 'post-1' }, { slug: 'post-2' }]` to pre-render these specific blog posts.
• Discuss benefits: Combines the benefits of dynamic routes with the performance of static generation, serving pre-built HTML for known paths.
• Mention `dynamicParams`: How to control behavior for unknown paths (e.g., `true` for on-demand generation, `false` for 404).

Where people lose the point

• ×Confusing `generateStaticParams` with client-side data fetching for dynamic routes.
• ×Not understanding that it's specifically for pre-rendering dynamic routes at build time.
• ×Failing to explain its relationship to `getStaticPaths` from the Pages Router.

What a strong answer covers

• Identify appropriate scenarios: For highly interactive components, data that changes frequently after initial page load, user-specific data (e.g., dashboard widgets), or when data is not critical for initial render/SEO.
• Explain implementation: Use a Client Component (marked with `'use client'`) and fetch data within a `useEffect` hook.
• Provide an example: Fetching data with `fetch` or a library like SWR/React Query inside `useEffect` and storing it in `useState`.
• Discuss benefits: Reduces server load, allows for real-time updates without full page reloads, and provides a more dynamic user experience.
• Mention considerations: Potential for loading spinners, managing error states, and the impact on initial page load and SEO if critical content is fetched client-side.

Where people lose the point

• ×Suggesting client-side fetching for all data, ignoring server-side options.
• ×Forgetting to wrap the fetching logic in a `useEffect` hook within a Client Component.
• ×Not mentioning the potential SEO drawbacks if critical content relies solely on client-side fetching.

What a strong answer covers

• Define hydration: The process where React takes over the server-rendered HTML on the client-side, attaching event listeners and making the static content interactive.
• Explain its importance: It allows users to see content quickly (fast Time To First Byte/Contentful Paint) while the JavaScript loads, then makes the page interactive, improving perceived performance and user experience.
• Describe how it works: The server sends HTML and a minimal JavaScript bundle. Once the JS loads, React 'rehydrates' the DOM, matching the server-rendered tree with the client-side React tree.
• Identify causes of hydration errors: Mismatches between server-rendered and client-rendered HTML (e.g., using `window` or `localStorage` in a Server Component, incorrect conditional rendering, or third-party scripts modifying the DOM).
• Discuss preventing errors: Ensure consistent rendering on both server and client, use `useEffect` for browser-specific APIs, and conditionally render client-only components.

Where people lose the point

• ×Confusing hydration with rendering (hydration is the *reconciliation* of server-rendered HTML with client-side React).
• ×Not understanding that hydration errors occur due to DOM mismatches.
• ×Failing to mention the performance benefits of hydration (perceived speed).

What a strong answer covers

• Explain automatic optimization: `next/font` automatically optimizes fonts by self-hosting them, removing external network requests, and handling font loading strategies.
• Detail zero layout shift: It prevents Cumulative Layout Shift (CLS) by automatically handling font fallbacks and ensuring that the correct font is loaded without causing content to jump.
• Discuss performance benefits: Reduces render-blocking requests, improves First Contentful Paint (FCP), and ensures text is visible during web font load (FOIT/FOUT prevention).
• Mention local fonts and Google Fonts: Supports both local font files and Google Fonts with similar optimization benefits.
• Describe the problem it solves: Addresses common font loading issues like flash of unstyled text (FOUT), flash of invisible text (FOIT), and layout shifts caused by font loading.

Where people lose the point

• ×Not mentioning the prevention of Cumulative Layout Shift (CLS).
• ×Confusing it with general CSS font-loading techniques; `next/font` is a specific Next.js utility.
• ×Failing to highlight the automatic self-hosting and removal of external requests.