Next.js Interview Questions to Ask Before You Hire

12 Next.js interview questions — with what to listen for

1. 1

   Explain server components versus client components: what runs where, and how do you decide where the boundary goes?

   What a strong answer covers

   Server components render on the server with zero client bundle cost and direct data access; client components hydrate for interactivity, marked with 'use client'. The design instinct: push boundaries as low as possible so interactive islands sit inside server-rendered trees. Knowing that children can pass server content through client components is the nuance test.

2. 2

   Walk me through the rendering options — static, dynamic, streaming, ISR — and give a concrete page type for each.

   What a strong answer covers

   Static generation for marketing and docs, dynamic rendering for personalized dashboards, streaming with Suspense for slow-data pages showing shells fast, and incremental static regeneration for large catalogs updated on interval or on demand. Mapping each mode to a business page, not just defining them, is the pass.

3. 3

   Next.js caching has multiple layers. Describe the ones you have actually fought with and how you took control.

   What a strong answer covers

   Fetch-level caching with revalidate options, the full route cache for static output, the client router cache, and revalidatePath/revalidateTag for on-demand invalidation. Honest war stories — stale data after a deploy or a mutation — plus the fix demonstrate real App Router mileage; reciting docs headings does not.

4. 4

   How do server actions work, and what do you still use route handlers for?

   What a strong answer covers

   Server actions as RPC-style mutations callable from forms and components with progressive-enhancement benefits; validation and auth still mandatory since they are public endpoints in disguise. Route handlers remain for webhooks, third-party API surfaces, and non-React consumers. Security framing is the senior marker.

5. 5

   A Next.js app's Core Web Vitals are poor — walk me through your triage for LCP and INP specifically.

   What a strong answer covers

   LCP: image optimization via next/image with priority on the hero, font loading strategy, server response times, render-blocking chains. INP: less client JavaScript, smaller hydration surfaces, breaking up long tasks, deferring non-critical work. Field-data-first methodology (CrUX, RUM) over lab-only scores signals production experience.

6. 6

   How do you handle authentication in the App Router — where do checks live, and what are the pitfalls?

   What a strong answer covers

   Session verification in server components, server actions, and route handlers close to the data; middleware for coarse redirects with the explicit caveat that middleware alone is not an auth boundary. Cookie handling across server contexts, plus data-access-layer centralization of checks, is the mature architecture.

7. 7

   When do you still choose the Pages Router, and how would you migrate an existing Pages app?

   What a strong answer covers

   Pages for legacy stability or team familiarity, with incremental migration route by route — both routers coexist. The candidate should describe what changes: data fetching from getServerSideProps to async components, layout system, and the caching model. A rewrite-everything answer misses the framework's own migration path.

8. 8

   How does next/image work, and what trade-offs come with it?

   What a strong answer covers

   On-demand optimization, responsive srcsets, lazy loading by default, layout-shift prevention via required dimensions. Trade-offs: optimization compute or a paid image service at scale, remote-pattern configuration, and cases for skipping it. Naming priority for above-the-fold images ties back to LCP.

9. 9

   Where do you put shared state in an App Router application, given that server components cannot use context?

   What a strong answer covers

   Server state via props and cache-deduplicated fetches, URL as state for shareable UI, client-side stores or context confined to client component subtrees, and libraries like React Query for client-server sync where mutations are heavy. The instinct to keep state server-first and minimal on the client is the modern pattern.

10. 10

    Describe your approach to code splitting and bundle discipline in Next.js.

    What a strong answer covers

    Route-level splitting for free, dynamic imports for heavy client components (charts, editors), bundle analysis to catch bloat, and dependency choices scrutinized for client cost. Awareness that every 'use client' boundary pulls its import graph into the bundle shows they understand the cost model.

11. 11

    How do you run and structure tests for a Next.js app, including server components?

    What a strong answer covers

    Unit tests for logic, component testing for client components, and honest acknowledgment that async server-component testing has rough edges — often covered better by integration/E2E with Playwright against a running app. Testing server actions as functions with mocked session context is a practical pattern worth hearing.

12. 12

    Your product needs parts of the site on the edge runtime. What changes, and when is edge the wrong choice?

    What a strong answer covers

    Edge runtime's subset of Node APIs, no native modules, size limits, and latency wins for geographically distributed personalization or middleware. Wrong when you need full Node compatibility, long CPU work, or database connections without an edge-compatible driver or pooling story. Balanced cost-benefit rather than edge-everything enthusiasm.

Frequently asked questions