What to assess in a Next.js developer
Next.js work is React plus a set of decisions about where code runs and when data is fresh. Those decisions are where most production bugs come from, and where an assistant is most likely to be confidently out of date.
- Server and client components: what belongs on each side, and what “use client” actually changes.
- Data fetching and caching: when a page is static, when it is dynamic, and how to revalidate it.
- Routing: layouts, dynamic segments, loading and error boundaries, and not-found handling.
- Mutations: server actions or route handlers, validating input on the server, and keeping secrets out of the client bundle.
- Performance: images, fonts, bundle size, and not shipping a large library to the browser by accident.
- Working with AI: spotting suggestions written for an older Next.js version, and checking them before accepting.
Screening questions for Next.js candidates
The screener follows your approved plan and probes vague answers, so a candidate who has only read a tutorial is asked for the next level of detail.
- A page shows data that is an hour old after a user updates it. Where would you look first?
- Which parts of a product page would you render on the server, and which on the client? Why?
- How do you keep an API key out of the browser in a Next.js app?
- An assistant suggests getServerSideProps in an App Router project. What do you do with that suggestion?
- How would you handle a form submission that must validate input and show errors without a full reload?
The Next.js coding round
The coding round opens a real Next.js project with starter files, Testing Library tests and a live preview in the browser. The candidate has Monaco, a terminal, inline completions, file-aware chat and an agent. In guarded mode the helper is limited; in unguarded mode they have a full assistant. The server enforces the mode.
Every line is tinted by authorship, and the server reruns the tests when the round ends. You can review their change as a diff against the starting files, with line comments.
AI-fluency signals for a Next.js developer
| Signal | What it tells you about a Next.js developer |
|---|---|
| Time to first prompt | Whether they looked at the app's routes and layouts before asking for code. |
| Prompt quality | Whether prompts say which router, which component and whether it runs on the server. |
| AI-generated share | How much of the final route or component came from accepted AI output. |
| Verification | Whether they checked the preview or ran the tests soon after accepting a change. |
| Over-reliance flags | Large accepted blocks, such as a whole page file, never reviewed or tested. |
| Recovery | What happened when the assistant suggested an outdated API: a fix, a better prompt, or nothing. |
From evidence to a decision
Fundamentals and AI fluency are scored separately and never averaged. Scores that cannot cite a real answer or edit are dropped and shown as gaps. The hiring manager round and any panel you add sit on the same record, and a named person signs off every outcome.
Questions
Does the Next.js coding round have a live preview?
Yes. The round runs a real Next.js project in a sandbox, with a terminal, tests and a live preview the candidate and you can both see in the replay.
Can I test whether a candidate knows the App Router?
Yes. Put it in the screening plan and the screener will ask about it and follow up on vague answers. The coding round's starter project is a real Next.js app, so you see how they actually use it.
What if the assistant gives the candidate outdated Next.js code?
That is part of what the round shows. The recovery and verification signals record whether the candidate caught it, re-prompted, or accepted it without checking.
Is a Next.js role assessed differently from a React role?
The plan is drafted from your job description, so a Next.js role gets sections on rendering, caching and server code that a pure React role would not.