How to Hire a Next.js Developer in 2026

Hire a Next.js developer in 2026 by posting the job alone, and you’ll get two very different kinds of applicants: people who’ve built two or three App Router projects end to end, and people whose Next.js experience is a Pages Router project from 2022 plus a résumé keyword. Both will say “yes” when you ask if they know Next.js. The screen that tells them apart takes about fifteen minutes if you ask the right things.

What “knows Next.js” actually means now

The App Router isn’t new anymore, but the mental model shift it required still trips people up. Components are Server Components by default: they render on the server, and their code never reaches the browser. That’s the opposite of how React worked for most of the last decade, where everything eventually became client-side JavaScript. A candidate who hasn’t internalized this will write App Router code that looks right and works, but ships far more JavaScript to the browser than it needs to, because they added 'use client' reflexively instead of deliberately.

Server Actions are the other big shift. Instead of writing a separate API route for a form submission, you write a function marked 'use server' and call it directly from a component. It feels like magic the first time it works. The catch, and the thing worth screening for, is that a Server Action is a public network endpoint whether the developer treats it that way or not.

// app/actions.ts
'use server'

export async function updateBilling(formData: FormData) {
  // This function is callable from the network. Full stop.
  // If you don't check the session here, anyone who knows
  // the action's compiled ID can call it directly.
  const session = await auth()
  if (!session) throw new Error('Unauthorized')

  const amount = Number(formData.get('amount'))
  if (!Number.isFinite(amount) || amount <= 0) {
    throw new Error('Invalid amount')
  }

  await db.billing.update({ userId: session.userId, amount })
}

Ask a candidate to review that function without the auth and validation lines present. If they don’t flag the missing session check on their own, that’s not a nitpick, that’s a security gap that ships to production the first time they touch a payment or account-settings feature.

The bundler question, and why it’s not trivia

Next.js 15 made Turbopack the default, and 16.3 added a persistent build cache that Vercel’s own release notes describe as cutting repeat production build times by several times over on large applications. That’s not a fact worth quizzing someone on directly, it’s a proxy for a better question: have they actually worked on a codebase large enough that build time was a problem worth solving? Someone who’s only run next dev on a portfolio project won’t have hit a Turbopack-specific bug or a monorepo configuration issue. That’s not disqualifying for a junior role. For a senior hire on a growing codebase, it’s a real gap.

Three questions that separate real experience from résumé keywords

“Walk me through how you’d fetch and cache data for a product page that changes hourly.” You’re listening for fetch with a revalidate option, or the newer Cache Components model, and for them to explain the tradeoff between static generation, incremental static regeneration, and dynamic rendering. A vague “I’d just fetch it in the component” answer means they haven’t had to think about staleness in production.

“When would you reach for a Route Handler instead of a Server Action?” The honest answer: Server Actions for form mutations triggered from your own UI, Route Handlers when you need a real REST or webhook endpoint that something outside your app calls (a third-party webhook, a mobile client, another service). A candidate who says “they’re basically the same thing” hasn’t had to expose an API to a consumer outside their own Next.js app.

“Your App Router page is shipping more JavaScript to the client than expected. How do you find out why?” Real answers mention the bundle analyzer, checking for unnecessary 'use client' boundaries pulling in large dependencies, or client components importing something that should have stayed server-side. This is the question that most reliably separates “read the docs” from “shipped and debugged this.”

Red flags and green flags

Red flags: reflexively adding 'use client' to fix any error without explaining why; no opinion on when to use Server Actions versus Route Handlers; treating a Server Action like it’s automatically authenticated because “Next.js handles that”; no experience with any deployment target other than Vercel’s default settings, which is fine for some roles but a gap if you’re self-hosting.

Green flags: can explain the render-then-hydrate cost of over-using client components in plain language; has an opinion on next/image and when its automatic optimization isn’t enough; has debugged a caching bug where stale data showed up in production and can describe what actually happened, not just the textbook explanation.

When to hire Next.js-specific versus general React

If the role is a marketing site, a dashboard with straightforward data fetching, or anything that doesn’t push hard on caching or Server Components, a strong general React developer will ramp up within a sprint or two; the React technical screen we use still applies to most of what they’ll do day to day. If the project leans on a real caching strategy, self-hosted deployment, or Server Components for data-heavy pages, hire someone who has shipped and debugged an App Router project specifically. The ramp-up gap between “knows React” and “has actually fought with Next.js caching in production” is real, and it shows up in the first month either way.

If you’d rather skip the search, codercops screens React and Next.js developers and hands you a vetted shortlist. See available React developers on codercops and post your role to get matched.

---

If you’re filling adjacent roles, the full-stack developer hiring guide and the frontend developer hiring guide cover overlapping ground from different angles.