How to Hire a Next.js Developer: The Complete Guide

Why Hiring Next.js Developers Is Hard

Next.js experience claims are abundant; actual Next.js expertise is not. A developer who built a blog with Next.js in 2021 is very different from an engineer who has shipped a production SaaS with App Router, streaming, Server Components, and a robust deployment pipeline.

This guide gives you the specific signals, questions, and tests to tell the difference.

What You're Actually Hiring For

Before posting a job, define the actual role:

Frontend-heavy Next.js: UI implementation, CSS, component architecture, performance. The backend is a separate team's problem.

Full-stack Next.js: API routes, database integration, auth, server-side data fetching. One engineer owns the full request lifecycle.

Next.js architect: Senior engineer who designs the system — rendering strategy, caching architecture, deployment topology. Probably not writing 100% of the code.

Most early-stage startups need a full-stack Next.js engineer, not a pure frontend specialist.

Screening Resumes

Look for:

Positive signals:

• Specific Next.js version experience (App Router vs Pages Router — these are different skills)
• Mentions of RSC, streaming, Server Actions, or ISR — terms that indicate real App Router experience
• Production deployments (Vercel, AWS, self-hosted) — not just "built projects"
• TypeScript (non-negotiable for maintainable Next.js code)
• Testing experience (Jest, Playwright, Cypress)

Yellow flags:

• "React/Next.js" listed without version context — may be Pages Router only
• No mention of backend or database work for a full-stack role
• GitHub with only tutorial projects, no real deployment history
• Five years of "experience" but all from a single employer with vague impact statements

Red flags:

• CSS frameworks listed as "proficiency" alongside "learning React" — experience level mismatch
• No testing mentioned at all
• Claims of "expert" in 15 different technologies

Technical Phone Screen (30 minutes)

Ask open-ended questions and listen for the depth of the answer:

"Explain the difference between Server Components and Client Components. When would you choose each?"

Expected: Server Components run on the server, have no state or browser APIs, are good for data fetching and reducing bundle size. Client Components have 'use client' directive, can use hooks, handle events, access localStorage. The candidate should give concrete examples of each choice.

"How does Next.js caching work in the App Router?"

Expected: Next.js has four caching layers — Request Memoisation, Data Cache, Full Route Cache, Router Cache. A senior engineer knows all four. A mid-level engineer knows Data Cache and Route Cache. An entry-level engineer may not know any.

"Walk me through how you'd implement authentication in a Next.js App Router application."

Expected: Mention of cookies/JWTs for session storage, middleware for route protection, server-side session validation. Bonus: awareness of libraries like NextAuth.js/Auth.js, Clerk, or rolling their own. Red flag: "I'd use localStorage for the token."

"How would you optimise a Next.js page that's slow to load?"

Expected: Audit bundle size, check for unnecessary client components, implement streaming, optimise data fetching (parallel fetches), optimise images with next/image, review Core Web Vitals. Strong candidates mention Lighthouse and real user monitoring.

Take-Home Assessment (2–4 hours)

Keep the scope small and realistic. Good take-home prompts:

Option A — Feature addition: "Here's a Next.js App Router repo with a basic blog. Add a search feature that filters posts by title. The search should work server-side. Include tests."

Option B — Bug investigation: "This Next.js app has a performance problem — the dashboard page is slow. Identify the issue, fix it, and explain your reasoning."

Option C — Architecture design: "Design the data fetching architecture for a dashboard that shows user analytics from three different APIs. Write the key components and explain the rendering strategy."

What you're evaluating:

• Code quality and TypeScript usage
• Understanding of server vs client rendering
• Test coverage (does any exist?)
• README quality — can they communicate their decisions?
• Handling of edge cases (loading states, errors, empty states)

Technical Interview (60 minutes)

Walk through their take-home submission together. Ask:

• "What would you change if you had more time?"
• "How would this perform at 100x the data volume?"
• "How would you test this in a CI pipeline?"

Then explore specific technical areas:

Data fetching: "Show me how you'd implement pagination for a large list. What's your approach to cursor-based vs offset pagination?"

Performance: "How does next/image help with Core Web Vitals? What's the priority prop for?"

Deployment: "Walk me through how you'd set up a CI/CD pipeline for a Next.js app. What happens between a git push and a Vercel deployment?"

TypeScript: "Show me how you'd type the response from an API route that can return either data or an error."

Evaluating Portfolios

Ask for production URLs, not just GitHub repos. In the browser:

• View source — is it server-rendered HTML or an empty <div>?
• Run Lighthouse — what do Core Web Vitals look like?
• Check Network tab — is the bundle size reasonable?
• Look at the source code — are there any any types, missing error handling, or unused dependencies?

Strong candidates will mention performance numbers without being asked. "This reduced load time by 40%" is a sentence that distinguishes engineers from coders.

Compensation Benchmarks (2026, USD)

UK equivalents: roughly 55–70% of US rates. Eastern Europe: 30–50%.

Agency vs Freelance vs Full-Time

Full-time hire: Best when you have a stable roadmap and sustained engineering needs. Takes 2–4 months to hire correctly.

Senior freelancer: Best for a specific project with a clear scope. Gets up to speed faster than a new hire, costs more hourly but no equity or benefits overhead.

Agency: Best when you need a team (design + engineering) or when time-to-market is the priority and hiring overhead is unaffordable. Higher day rate, but fully managed, with accountability for delivery.

The worst outcome is hiring a mid-level engineer to do an architect's job because the architect's rate felt high. You pay twice — once for the hire, once for the rewrite.