Lesson 1 of 5
What Next.js Interviews Probe
"This version has breaking changes — APIs, conventions, and file structure may all differ from your training data." — the instruction file at the root of the repository this volume was written in
That warning was written for an AI, and it applies at least as strongly to a human candidate. Next.js 16 changed enough that fluent, confident recall is now a liability in an interview: priority on an image is deprecated, Middleware is called Proxy, fetch is no longer cached by default, reset is unstable_retry, and Partial Prerendering is the default rather than an experiment. A candidate who answers those quickly and wrongly reads worse than one who says "that changed recently, let me tell you what it is now".
Which is the first thing worth understanding about these interviews. They are not primarily testing whether you have memorised an API surface, because the API surface has been moving and everyone in the room knows it. They are testing whether you understand a small number of structural facts well enough to reason from them — and those facts have been the spine of this entire volume.
There are four of them. Where does this code run. How often does it run. What crosses the boundary. What happens when it fails. Almost every question in this part decomposes into one or more of those, and almost every wrong answer in the preceding seven parts came from getting one of them wrong.
What is actually being assessed when someone asks you a Next.js question — and how would you tell the difference between an answer that sounds right and one that is right?
The four questions underneath everything
Every substantive failure in this volume traces to one of four.
The practical value of that list is as a checklist you run silently while reading code in an interview. Four questions, ten seconds, and you have located the interesting thing about almost any snippet somebody hands you.
Consider how a good building surveyor works. They do not arrive with a memorised catalogue of every construction technique of the last century, and they do not need one, because they carry four or five questions instead: where does the water go, what is holding this up, what has been altered, and what happens when it gets cold. Those questions locate almost every real problem in almost any building, including building types the surveyor has never seen. Someone who has memorised techniques can tell you what a thing is called. Someone with the questions can tell you what is going to fail. Interviews for senior work are mostly trying to find out which of those you are, and the tell is what you do when shown something unfamiliar: reach for a label, or start asking.
The recall trap
Because so much moved in version 16, confident answers are actively risky. It is worth knowing which of your beliefs are dated.
That last observation is the more sophisticated version of tracking a framework. Facts persist while their consequences are discovered, and being able to say "this was documented as a performance feature and it is also a security constraint" is a stronger signal than any amount of API recall.
Front-end interviewing has a well-earned reputation for testing the wrong things, and the reason is partly structural: the field's surface churns fast enough that any question about a specific API is testing recency rather than ability. The industry's response over the last decade has been to move towards fundamentals — closures, the event loop, rendering — which was an improvement and produced its own distortion, because a candidate can now be excellent at JavaScript trivia and have no model of the system they would be paid to build. What is interesting about the Server Components era is that it created a genuinely new category of question that is neither trivia nor fundamentals: questions about where code runs. Those did not exist in a meaningful way when everything ran in one place, and they cannot be answered from JavaScript knowledge alone, because the language gives no indication. I think that is why the boundary questions have become such reliable interview material so quickly — they are the first thing in years that is both specific to the stack and genuinely difficult to fake.
What differs between levels
Not the quantity of knowledge. The question each level answers.
That framing — what happens when the person who understood it leaves — is the most reliable single lens for pitching an answer at a senior level. It shifts the discussion from mechanism to durability, and durability is what the role is actually about.
The habit I would most recommend for preparation is to build a list of things you have been wrong about, with the reason. Not a list of facts — a list of corrections. "I thought fetch was cached; it stopped being in 15, and the reversal is an admission that implicit caching was dangerous." That format is enormously more useful in a room than a fact, because it gives you something to say when you are uncertain and because interviewers respond to it: a candidate who can narrate their own model updating is demonstrating the thing the job requires. The second habit is to practise the four questions out loud against code you did not write. Open any Next.js repository, pick a component, and answer where it runs, how often, what crosses, and what happens when it fails. It takes a minute and it is the closest thing to the actual task of a technical interview. And the third is to prepare one real incident thoroughly — the diagnosis, the wrong hypotheses, the fix, what you changed afterwards — because almost every senior interview contains a moment where a specific story is worth more than any general answer.
The company lenses, collected
Every chapter of this volume carried four. Read together, they are a map of what different organisations actually probe.
I have watched a strong engineer lose an interview to a weaker one on a question they knew better. The question was about caching a user-specific dashboard. The stronger candidate gave an accurate, detailed account of cache keys, closure capture, and revalidation — genuinely more knowledgeable than the other candidate's answer. The weaker one said something much simpler: "I would be careful here, because if the tenant is not in the key you serve one customer another's data, and it is a cache hit so nothing looks wrong." Then they described the two-tenant test. The panel hired the second candidate, and the debrief note was about risk awareness rather than knowledge. What I take from that is not that depth is unwelcome — it is that an answer's shape communicates as much as its content. Detail signals familiarity. Naming a failure and how you would catch it signals that you have operated something. Most panels are staffed by people who have been on call, and they are listening for the second thing whether or not they have articulated it.
When you do not know
The most common avoidable loss in these interviews.
Common Mistakes
Answering from memory in an area that changed. Version 16 moved enough that a fast wrong answer is worse than a slow qualified one.
Preparing a feature list rather than the four questions. The failures are combinations, and combinations cannot be memorised.
Giving a longer mid answer to a senior question. Depth is not the axis; durability and detectability are.
Not naming the trade-off. At mid level and above, an answer with no cost attached reads as incomplete.
Describing a fix without the failure it addresses. "Use the DAL" means little without "because a layout check does not re-run".
Preparing for one company lens. The same knowledge scores differently depending on whether they want practical, mechanism, judgement or operational.
Stopping at "I don't know". Honest and terminal; reasoning out loud from a constraint is honest and productive.
Inventing an API name. The one unrecoverable move, because it undermines every other answer.
Neglecting to prepare a real incident. Most senior interviews have a moment where a specific story beats any general answer.
Treating a fact as settled because it has not changed. Layouts not re-rendering is the same fact it was in 2023 and now carries security weight.
Interview Corner
fetch was cached by default until 15, that priority on images was deprecated in 16, that Middleware became Proxy — because the reason behind a change usually generalises further than the change does. The fetch reversal, for instance, is an admission that implicit caching was dangerous, and that principle shows up again in use cache being explicit. I also check the docs that ship inside the installed package rather than trusting recall, because that takes thirty seconds and this is a codebase where a confident memory is frequently a stale one.Two functions modelling the assessment itself. The first scores an answer against the level it is pitched at, where the rule is that a senior answer must add detectability and a guardrail rather than more mechanism — the distinction this chapter turns on. The second is a staleness checker over claims about the framework: given a statement and the version it was true in, decide whether it still holds, which is the discipline that keeps the recall trap from closing on you.
Summary
Four questions underlie almost every Next.js interview question: where does this run, how often, what crosses the boundary, and what happens when it fails.
The failures are combinations, which is why a feature list is poor preparation and the four questions are good preparation.
Version 16 moved enough that confident recall is a liability. Proxy, uncached
fetch, deprecatedpriority,unstable_retry, PPR as default,paramsas a Promise."That changed in 16 — it used to be X, it is now Y, and here is why" is a stronger answer than a correct answer to the old question.
Some facts persisted while their significance changed. Layouts not re-rendering is a performance note that became an authorisation hazard.
Levels differ by which question you answer, not by how much you know: mechanism, then trade-off, then durability and detectability.
The senior failure mode is a longer mid answer. The senior question is what happens when the person who understood it leaves.
The four company lenses want different skills from the same knowledge — practical, mechanism, judgement, operational.
Prepare four sentences per topic: how I would do it, why it works, when I would not, and how it fails and how I would know.
Bound your uncertainty and then reason. The one unrecoverable move is inventing an API name.
Knowing what is being probed is the frame. The next chapter is the single most common architectural question in these interviews, and the one where reciting a changelog is most tempting and least effective: App Router vs Pages Router.
The interview I described above — the more knowledgeable candidate losing — has stayed with me for a reason that has nothing to do with hiring. It is that the winning answer was shorter, and its brevity was the substance. "If the tenant is not in the key you serve one customer another's data, and it is a cache hit so nothing looks wrong" is one sentence containing a mechanism, a consequence, and an observation about detectability. The longer answer contained more true statements and made no claim about what would happen to anybody. I think we systematically over-reward completeness because completeness is easy to assess and consequence is not, and interviews are one of the few settings where that bias gets corrected — panels of people who have been paged at four in the morning listen for a specific note. If there is a transferable lesson from this whole volume it is probably that one: knowing how something works and knowing how it fails are different kinds of knowledge, and the second is rarer, more useful, and much harder to acquire from documentation.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.