25 Next.js interview questions
Structure the loop around evidence, not framework trivia. Start with a 30-minute screen covering recent Next.js work, ownership level, and comfort with App Router, React Server Components, caching, and deployment constraints. Follow with a practical coding session or short take-home that exposes routing, data fetching, forms, error states, and performance choices. Add a debugging interview using logs, traces, hydration errors, cache misses, or production incidents. For mid and senior candidates, include a design round focused on rendering strategy, auth, multi-region data, observability, and rollout safety. Close with collaboration and product judgment: how they clarify requirements, review code, document trade-offs, and work with design, backend, and platform teams.
Junior Next.js questions
Fundamentals, learning speed and how they debug.
01You inherit a small App Router page that is slow on first load and also logs a hydration mismatch. How would you investigate before changing code?
Listen for: A strong answer separates measurement from guessing: reproduce locally and in preview, check browser console, server logs, React hydration warnings, network waterfall, bundle output, and Lighthouse or Web Vitals. They should compare server-rendered markup with client state, look for time-dependent rendering, browser-only APIs, unstable keys, and oversized client components.
Red flag: They immediately suggest adding 'use client' everywhere or disabling SSR without diagnosing the cause.
02A product page uses a Server Component to fetch product data and a Client Component for quantity selection. Where should each piece of logic live, and why?
Listen for: Listen for clear boundaries: data loading, access checks, and non-interactive rendering stay on the server; local UI state, event handlers, and browser APIs stay in Client Components. They should mention passing serializable props, avoiding secrets in client bundles, and keeping the client boundary as small as practical.
Red flag: They treat Server and Client Components as interchangeable or put database calls inside Client Components.
03A form submission sometimes creates duplicate records when users double-click submit. How would you make the flow safer in a Next.js app?
Listen for: Good candidates cover both UI and backend safety: pending state, disabled submit, optimistic feedback only when appropriate, server-side validation, idempotency keys or unique constraints, and clear error handling. They should understand that Client Component protections improve UX but cannot be the only protection against duplicate writes.
Red flag: They rely only on disabling the button in the browser.
04You need to add authentication-aware navigation to a layout. What should you consider before reading the session in the layout?
Listen for: They should consider rendering and cache implications. Reading cookies or headers makes the route dynamic and affects CDN caching. A good answer weighs server-side session checks, middleware for coarse redirects, client-side personalization, loading states, and avoiding leakage of private data into shared caches or static output.
Red flag: They add session reads to the root layout without considering caching or static rendering impact.
05A designer reports that an image-heavy marketing page looks fine locally but performs poorly in production. What would you check?
Listen for: Look for practical checks: correct use of next/image, dimensions to prevent layout shift, responsive sizes, priority only for the LCP image, image formats, remote image configuration, unnecessary client JavaScript, font loading, and real production measurements. They should distinguish visual correctness from performance behavior under network constraints.
Red flag: They say performance is a hosting issue without inspecting assets, JavaScript, or loading behavior.
06How would you handle environment variables in a Next.js project with local, preview, and production deployments?
Listen for: A strong junior answer knows the difference between server-only variables and NEXT_PUBLIC variables, avoids committing secrets, validates required values at startup or build time, and understands that public variables are bundled for the browser. They should mention separate preview values and documenting setup for other developers.
Red flag: They put API keys in NEXT_PUBLIC variables because the frontend needs them.
Mid-level Next.js questions
Independent delivery, trade-offs and code quality.
07A dashboard route uses fetch in Server Components and sometimes shows stale data after a mutation. How would you reason about caching and invalidation?
Listen for: Listen for knowledge of Next.js data caching, request memoization, route segment behavior, revalidatePath, revalidateTag, no-store, and when to choose each. Strong candidates connect freshness requirements to product behavior, avoid blanket cache disabling, and describe how mutations should invalidate the exact data affected.
Red flag: They fix all stale data by setting every fetch to no-store.
08You are migrating a Pages Router application to the App Router. How would you plan it without stopping feature work?
Listen for: Strong answers propose incremental migration, route-by-route ownership, compatibility between pages and app directories, shared design system cleanup, API route strategy, test coverage around critical flows, and performance baselines. They should call out changed mental models: layouts, loading and error boundaries, Server Components, metadata, and data fetching patterns.
Red flag: They suggest rewriting the whole application in one branch before shipping anything.
09A Client Component imports a utility that accidentally pulls a large server-side dependency into the browser bundle. How would you detect and prevent this?
Listen for: They should mention bundle analysis, build warnings, dependency graphs, Turbopack or webpack analyzer output, and reviewing client boundary imports. Prevention signals include separating server-only modules, using the server-only package, lint rules, explicit module boundaries, dynamic import for truly client-heavy code, and code review practices.
Red flag: They only say to minify the bundle and do not address the import boundary.
10A route has personalized data, shared catalog data, and feature-flagged UI. How would you choose rendering and caching strategies?
Listen for: Good answers split concerns: cache shared catalog data with tags or revalidation, handle personalized data dynamically and privately, and evaluate feature flags based on whether they are build-time, request-time, or client-evaluated. They should avoid letting one personalized read force all content into an uncached path unnecessarily.
Red flag: They apply a single rendering mode to the whole route without considering data boundaries.
11How do you approach error handling in App Router for a checkout or onboarding flow?
Listen for: Listen for layered handling: field validation, expected server action errors returned as typed state, unexpected exceptions captured by error boundaries and monitoring, not-found for missing resources, retry affordances, and safe logging without sensitive data. Strong candidates distinguish user-correctable errors from system failures.
Red flag: They throw all errors and rely on a global error page for the entire flow.
12You see high serverless function duration for a Next.js route in production. What are your first hypotheses?
Listen for: Strong hypotheses include slow upstream APIs, unbounded database queries, cold starts, large dependency initialization, missing connection pooling strategy, excessive dynamic rendering, blocking third-party calls, waterfall fetches, and heavy CPU work during render. They should describe using traces, logs, timing instrumentation, and production-like reproduction before optimizing.
Red flag: They assume the framework is slow without checking upstream latency or route behavior.
13How would you review a pull request that introduces a new Server Action for updating billing details?
Listen for: Look for security and correctness: authentication, authorization, CSRF posture, input validation, idempotency, audit logging, error handling, cache invalidation, redirect behavior, and tests. Strong candidates also check that secrets remain server-side, the action is not over-broad, and UX handles pending and failure states.
Red flag: They only review whether the form works in the happy path.
Senior Next.js questions
Judgement, architecture and raising the team's bar.
14A Next.js app has grown into many route groups, shared layouts, and mixed ownership. How would you keep architecture understandable?
Listen for: Strong senior answers discuss intentional route organization, ownership boundaries, ADRs, naming conventions, module dependency rules, shared layout governance, and documentation that explains rendering and caching decisions. They should balance consistency with team autonomy and propose checks such as lint rules, code owners, and periodic architecture reviews.
Red flag: They rely on informal knowledge and tell teams to just follow existing patterns.
15Your team is debating Server Actions versus traditional API routes for write operations. How would you guide the decision?
Listen for: Listen for nuanced trade-offs: Server Actions are convenient for UI-coupled mutations and progressive enhancement, while route handlers or external APIs may fit public contracts, mobile clients, webhooks, versioning, or cross-service reuse. They should discuss validation, observability, authorization, testing, cache invalidation, and how the choice affects coupling.
Red flag: They declare one approach universally superior.
16A critical route combines search, filters, pagination, and SEO requirements. How would you design the URL and rendering model?
Listen for: A strong answer treats URL state as a product and platform contract: canonical query parameters, shareability, indexability, metadata, pagination semantics, cacheable data where possible, and accessible loading states. They should weigh server-rendered results against client interactivity and avoid creating duplicate crawl paths or unstable canonical URLs.
Red flag: They keep all filters in client state and ignore SEO and shareability.
17How would you set performance budgets for a Next.js product area and make them stick?
Listen for: Look for specific budgets tied to user journeys: JavaScript per route, LCP image behavior, server response time, interaction latency, and Web Vitals. Strong candidates propose CI checks, bundle analysis, real-user monitoring, ownership, exception processes, and design collaboration rather than one-time optimization work.
Red flag: They mention Lighthouse scores only and no ongoing enforcement.
18A new compliance requirement says certain customer data must never leave a region. What changes might be needed in a Next.js app?
Listen for: They should reason across hosting, databases, logging, analytics, edge middleware, cache layers, image optimization, third-party scripts, and support tooling. Strong candidates identify where data is read, rendered, cached, serialized to clients, or emitted in telemetry, then propose region-aware deployment and data access boundaries.
Red flag: They say keeping the database regional is enough.
19Your team sees intermittent production-only bugs after enabling more caching and partial static rendering. How would you lead the investigation?
Listen for: Strong answers combine technical debugging and coordination: map route segment configs, dynamic functions, fetch cache modes, tags, cookies, headers, and invalidation paths; reproduce with production-like builds; add request IDs and cache diagnostics; define rollback criteria; and communicate risk to product stakeholders during the investigation.
Red flag: They disable all caching immediately without preserving evidence or narrowing scope.
20How do you mentor a team that is new to React Server Components without blocking delivery?
Listen for: Listen for teaching through real code: pairing on boundaries, small examples, review checklists, migration playbooks, and agreed defaults for data fetching, mutations, and client state. Strong candidates create guardrails while allowing exceptions, and they explain mental models in terms of data flow and user experience.
Red flag: They expect everyone to learn by reading docs and correcting mistakes in review.
System design Next.js questions
Designing real systems end to end.
21Design a multi-tenant B2B dashboard in Next.js with tenant-specific branding, role-based access, audit logs, and shared analytics pages.
Listen for: A strong design separates tenant resolution, authorization, theming, and data access. Listen for middleware or server-side checks that do not replace per-request authorization, cache keys scoped by tenant, safe metadata and asset handling, audit logging for mutations, and clear boundaries between shared components and tenant-specific configuration.
Red flag: They rely on the subdomain alone as proof of tenant identity.
22Design a content and commerce site where product pages need SEO, inventory must be fresh, and editorial content can be cached aggressively.
Listen for: Look for split rendering and data strategy: static or revalidated editorial content, fresher inventory and pricing reads, tag-based invalidation, metadata generation, image optimization, preview workflows, and graceful degradation when commerce APIs fail. Strong candidates avoid coupling all content freshness to the strictest data requirement.
Red flag: They make every product page fully dynamic because one field changes often.
23Design an authenticated reporting app with expensive charts, export jobs, and near-real-time status updates.
Listen for: Strong answers move heavy work out of request rendering into jobs, queues, or backend services; use Server Components for initial authorized data; hydrate focused Client Components for chart interactions; stream or poll job status appropriately; and protect exports with scoped authorization, signed URLs, and observability around long-running tasks.
Red flag: They generate large reports synchronously inside a route render.
24Design a Next.js platform that serves both a web app and public API consumers for the same domain model.
Listen for: Listen for a clear contract boundary. UI-coupled operations may use Server Actions, but public or multi-client operations need versioned route handlers or separate services, schema validation, auth scopes, rate limiting, and documentation. Strong candidates avoid duplicating business rules by sharing server-side domain modules safely.
Red flag: They expose Server Actions as if they were a stable public API.
25Design a rollout plan for migrating a high-traffic Pages Router application to App Router with minimal customer impact.
Listen for: A strong plan includes route inventory, risk ranking, performance baselines, observability, feature flags, incremental dual-router migration, compatibility testing, rollback paths, shared component cleanup, and education for developers. They should call out changed caching behavior and how to validate SEO, redirects, analytics, and error tracking.
Red flag: They propose a big-bang migration with no route-level rollback strategy.
Build and Debug a Small App Router Workflow
Create a small Next.js 15+ App Router application for managing project tasks. The app should include a server-rendered task list, a detail page, a form to create or edit a task, validation errors, loading and error states, and one intentionally cacheable data path with correct invalidation after mutation. Use TypeScript and any simple data store such as SQLite, Prisma with a local database, or an in-memory repository with clear boundaries. Include a short README explaining rendering choices, cache decisions, and what you would monitor in production.
How to evaluate it
- Correct App Router structure with sensible Server and Client Component boundaries.
- Data validation, mutation safety, error handling, and cache invalidation behavior.
- User experience for loading, pending, empty, and failure states.
- Code organization, TypeScript quality, and testability of server-side logic.
- README clarity on trade-offs, assumptions, and production monitoring.
Rather skip the interview loop?
Every Octogle Next.js engineer has already passed a technical assessment, system design and a live interview with an engineer who has shipped Next.js. Send a brief and get 3–5 scored profiles in 48 hours.