Most “Next.js interview questions” lists you’ll find online are trivia. They ask what ISR stands for, what getStaticProps did, or what a Server Component is. A candidate can pass every one by reading documentation the night before, without ever shipping a Next.js app that took real traffic.<\/p>\n\n\n\n
That gap costs money. The engineers who cause expensive production incidents often knew the vocabulary perfectly. They just never had to decide whether a product page should revalidate on a tag or a timer, or why wrapping a whole route in ‘use client’ quietly doubled the JavaScript bundle.<\/p>\n\n\n\n
This set of scenario-based questions addresses the four decisions a Next.js engineer makes every week<\/strong>: rendering strategy, the Server and Client Component boundary, caching and revalidation, and the proxy layer that runs before your route code. Each one comes with what a strong answer covers and the plausible-sounding weak answer that signals shallow experience.<\/p>\n\n\n\n Written for Next.js 16 (released October 21, 2025), verified against the official Next.js documentation. Note that Next.js 16 renamed middleware.ts to proxy.ts, and that this layer now runs on the Node.js runtime by default.<\/em><\/p>\n\n\n\n In this guide:<\/strong><\/p>\n\n\n\n Scenario questions work because they force a candidate to pick one option and defend it against a constraint, which recall questions never do. A definition has one right answer, while a rendering decision has tradeoffs, which are where seniority shows up.<\/p>\n\n\n\n Each row below tests the same underlying knowledge. The left column can be answered from memory, while the right column cannot.<\/p>\n\n\n\n\n
How to use scenario-based questions to assess Next.js judgment<\/strong><\/h2>\n\n\n\n
Trivia vs. architectural judgment: what to test<\/strong><\/h3>\n\n\n\n