A candidate says "I know Next.js." Three follow-ups decide whether that means anything. Which router was the last codebase on? Which major version? And what runs on the server in that app, as opposed to the browser? If you plan to hire Next.js developers, those answers matter more than years of experience, because the caching model, the default component type and the set of security fixes you need all differ between versions and routers.
This guide is part of our series Hire developers by tech stack: rates, vetting and interview guides. It ties each screening topic to what the Next.js documentation says today, so you can check a candidate's answers against a source rather than against your own memory.
What a Next.js developer does that a React developer does not
React renders components. Next.js decides where and when they render: on the server, at build time, or in the browser. It also owns routing, data fetching, caching and the deployment shape. A developer who only knows React hooks and state can build a Next.js page, but can't tell you why it's slow, stale or leaking data.
For React fundamentals, rates and the general interview checklist, use our general React hiring checklist. It doesn't go deep on versions, routers, caching or deployment, which is what the rest of this page covers.
Which Next.js version your candidate needs to know
The Next.js support policy lists two supported lines as of 3 October 2026: 16.x in Active LTS (released 21 October 2025) and 15.x in Maintenance LTS (released 21 October 2024). Maintenance LTS means "only critical bug fixes and essential security updates," and each major version stays there for two years after its initial release. By that rule, 15.x leaves Maintenance LTS around 21 October 2026. That's our derivation, not a date the policy states, but it's close enough to change a hiring plan.
Version 16.3 shipped on 3 August 2026, and what the 16.3 release changed is covered in its own article.
| Version line | Status | What to ask |
|---|---|---|
| 16.x | Active LTS | Have you shipped on 16, and did you adopt Cache Components or stay on the old model? |
| 15.x | Maintenance LTS | What's your upgrade plan to 16, and how would you sequence it? |
| 14 and earlier | Not listed as supported in the policy | What blocked the upgrade, and what would you do first? |
If your codebase is on 15, hire for the migration as well as the maintenance. If it's on 16, a candidate whose experience stops at 14 may need ramp-up time on the Cache Components model.
App Router vs Pages Router: which skills you're hiring for
Ask which router the last project used and whether a migration was planned. Both routers still matter operationally: the September 2026 security advisories (covered below) include one that affects self-hosted Pages Router apps and one that affects App Router metadata image routes built with webpack. The skills overlap less than the names suggest. Don't assume either router is obsolete when you screen.
A candidate who has only worked in the Pages Router will know getServerSideProps and API routes. They'll need time on the server and client boundary described next. A candidate who has only worked in the App Router may never have maintained a legacy codebase, which is what a team with an older codebase will need.
Server Components and Server Actions: the screening questions
The Next.js docs on Server and Client Components state that layouts and pages are Server Components by default. A "use client" directive declares a boundary: its imports and the components it renders directly join the client bundle. The server-only package turns an accidental import into a Client Component into a build-time error. And only environment variables prefixed with NEXT_PUBLIC_ reach the client bundle.
On mutations, the Next.js data mutation guide says Server Functions use POST and are "reachable via direct POST requests," so you must "always verify authentication and authorization inside every Server Function." A form that hides a button from non-admins hasn't protected anything.
| Question | Strong answer signal | Red flag |
|---|---|---|
Where does "use client" go, and why not at the top of every file? | Pushes it to the leaves, explains that everything it imports ships to the browser | Puts it everywhere "to make errors go away" |
| How do you keep a secret out of the client bundle? | Mentions server-only and the NEXT_PUBLIC_ rule | Relies on naming conventions or code review alone |
| Where do you check permissions in a Server Action? | Inside the action itself, every time | Only in the page or the UI that calls it |
| What can you pass from a Server Component to a Client Component? | Serializable props, with examples of what fails | Doesn't know there's a limit |
If the role includes AI features, add a practical task. A streaming chat in a Next.js app is a reasonable take-home shape, because it forces the server/client split and an API key that must stay server-side.
Caching and Cache Components
Next.js 16 changed the caching model, and this is where candidates trained on older material go wrong. According to the Cache Components migration guide, Cache Components requires Next.js 16. The dynamic, revalidate and fetchCache route segment configs are replaced by use cache and cacheLife, and unstable_cache is replaced too. runtime = 'edge' and dynamicParams aren't supported with Cache Components.
The API has three pieces: the use cache directive (usable at data level and UI level), cacheLife to set how long an entry lives, and cacheTag for targeted invalidation. Built-in cacheLife profiles run from seconds, minutes, hours and days through weeks and max, and the docs recommend always pairing use cache with cacheLife, because an implicit default profile applies otherwise. The Next.js 16.3 announcement says the work behind Instant Navigations, which will become the default in a future major version, is aimed at being "dynamic by default, with no hidden or implicit caching," and Cache Components is enabled by setting cacheComponents: true in the config.
One difference catches people out in production. use cache stores entries in memory by default, scoped to a single deployment, while the old fetch Data Cache and unstable_cache persisted across deployments and serverless instances. A developer who treats the new directive as a drop-in replacement will see cold caches after every deploy.
Good screening question: "How would you cache a page that shows per-user data?" A strong answer separates what's shared from what's personal, keeps runtime data behind Suspense, and knows use cache: private exists for runtime data (per the Next.js caching docs, its results are cached in the browser, not in a shared server cache). A weak answer caches the whole page and hopes.
Turbopack, build speed and type checking
Keep this short. The 16.3 announcement claims "up to 90% less memory" in next dev, disk caching in next build, and optional TypeScript 7 type checking in next build. It also cites Vercel's own benchmarks of up to 22% more requests under load for server rendering. The post says some projects see 5.5x faster builds on CI. Its chart of Turbopack compile time shows 30 seconds cold against 5.5 seconds cached on one site, but only about 2.3x and 1.4x on the other two. Treat these as vendor figures.
You don't need a candidate to recite them. Ask one question about CI: "What would you cache in the pipeline, and how would you know a build is slow because of the framework rather than your code?"
Self-hosting vs Vercel: what the developer must know
Plenty of teams don't deploy on Vercel, and the Next.js self-hosting guide is blunt about what changes once you run more than one instance. It recommends a reverse proxy. The default cache is per instance, so a shared cache needs a cacheHandler with cacheMaxMemorySize: 0 (for use cache entries, the guide points to cacheHandlers and use cache: remote). Set a consistent generateBuildId if you rebuild per environment, and a deploymentId for version-skew protection during rolling deployments (when deploymentId is set, generateBuildId has no effect). Every instance needs the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, or users see "Failed to find Server Action" errors. And streaming breaks behind a buffering proxy unless you send X-Accel-Buffering: no.
Questions worth asking anyone who'll own deployment:
- Two instances sit behind a load balancer. What goes wrong with the cache, and how do you fix it?
- A deploy rolls out gradually and users get "Failed to find Server Action." What do you check?
- Streamed responses arrive all at once in production but not locally. Why?
A developer who has only ever pushed to Vercel can still be a good hire. They just shouldn't be your first owner of a Kubernetes deployment.
Security: patch discipline as a screening topic
On 30 September 2026 the Next.js team published its September 2026 security release, listing seven advisories: one High (SSRF), five Medium and one Low. Fixes landed in v16.3.8 on the Active LTS line and v15.5.27 on Maintenance LTS.
Several of them depend on configuration, which makes them a good test of whether a candidate reads advisories or skims headlines. The SSRF issue is in Image Optimization, and the post says that if no images.remotePatterns are configured, the application isn't affected. A self-hosted Pages Router cache issue can replace one route's SSG or ISR entry with another route's content, and apps on Vercel aren't affected. A metadata image routes issue hits App Router builds made with webpack but not Turbopack. Two more concern Cache Components: a nested 'use cache' root-param leak, and a pending use cache fill that can leak Draft Mode content.
We aren't triaging the advisories here. The point for hiring is the habit. Ask: "How do you find out about a Next.js security release, and what do you do in the first hour?" A strong answer names a subscription or watch, checks whether the app's configuration is affected, and has a path to upgrade within a supported line. A weak answer is "we update when something breaks."
How to screen a Next.js developer in four steps
1. Pin router, version and host in the job spec
Write the router (App, Pages or both), the exact major version, and where the app runs (Vercel, containers, your own servers) into the job description. The outcome is a candidate pool that has already filtered itself against your real stack.
2. Review a real repo or take-home for the server and client boundary
Ask for a small repo or a take-home that includes at least one mutation and one cached read. Check where "use client" sits, whether secrets stay server-side, and whether the caching choices match the version. The outcome is evidence of how they actually build, not how they describe building.
3. Run a live session on a caching or Server Action auth problem
Give them a bug: a page that serves stale data after a deploy, or an action that any logged-in user can call. Watch how they reason about it. The outcome is a view of their debugging habits against the model described above.
4. Check upgrade and patch habits
Ask how they handled the last major upgrade and how they track security releases. The outcome is a read on whether they'll keep your app on a supported line.
Cost and engagement
Next.js work isn't priced separately: price the role as a React or full-stack senior hire, and treat Next.js depth as a screening criterion rather than a premium you can quantify. For senior engineers, HighCircl's range is €45-105/hr ($50-115/hr), with no subscription and no minimum hours.
Hiring Next.js developers through HighCircl
HighCircl places senior engineers from seven European countries: Poland, Hungary, Slovakia, Serbia, Slovenia, Romania and Spain. HighCircl's covered stacks include React and Node.js, so state your Next.js requirements up front. Candidates go through four stages run by senior engineers, from background verification to a live technical session on architectural reasoning, and about 1 in 10 applicants pass. You get a shortlist of 3-5 within 72 hours, with no recruitment fee, and a replacement at no additional recruitment cost if the engagement isn't working. Bring the router, version and hosting answers from this guide to the scoping call when you start hiring React engineers through HighCircl.
FAQ
What's the difference between a React developer and a Next.js developer?
A Next.js developer is a React developer who also owns routing, server rendering, data fetching, caching and deployment. In practice the overlap is large, and a strong React engineer can learn Next.js. The risk is on the server side: the boundary between server and client code, and the caching model, are where inexperience shows.
Should a new hire know the App Router or the Pages Router?
In our view, hire for the router your codebase uses, and prefer someone who can work in both if you're mid-migration. There's no basis for treating Pages experience as a disqualifier. For a new project on Next.js 16, App Router experience is the more useful signal.
Do Next.js developers need to know Vercel?
Only if you deploy there. Vercel runs Next.js, but the framework's self-hosting guide covers reverse proxies, shared caches and Server Action encryption keys for teams that don't. Screen for the host you actually use.
How fast can I get a shortlist of Next.js developers?
Through HighCircl, a shortlist of 3-5 vetted candidates arrives within 72 hours. HighCircl's covered stacks include React and Node.js; raise Next.js requirements on the scoping call, including the router, version and hosting.