How would you use generateStaticParams for known products and on-demand unknowns?

WHAT THIS TESTS: This question probes whether you understand the App Router route segment configuration and the precise boundary between build-time static generation and on-demand server rendering. Specifically, it checks if you know that generateStaticParams only covers the predeclared set and that a separate config flag controls what happens to unknown dynamic segments.

A GOOD ANSWER COVERS: First, the candidate should state they would export an async generateStaticParams function from the page file that returns an array of param objects for the known products, such as slugs pulled from a CMS at build time. Second, they must mention dynamicParams in the route segment config, noting that it defaults to true, which means any slug not returned by generateStaticParams will be server-rendered on demand rather than returning a 404. Third, they should explain that the page component itself remains the same, receiving params and fetching data, but Next.js chooses the rendering strategy based on whether the slug was pregenerated. Fourth, a senior candidate might note that the on-demand render can be cached or revalidated using route segment config like revalidate or by calling revalidatePath after a mutation.

COMMON WRONG ANSWERS: A major red flag is describing the Pages Router pattern, such as getStaticPaths with fallback true or blocking. Another is saying generateStaticParams alone handles unknown paths dynamically without mentioning dynamicParams. Some candidates incorrectly state that unknown slugs will automatically 404 unless you use ISR, which confuses the default behavior. Others suggest client-side data fetching as the fallback, which misses the point of on-demand server rendering entirely.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle cache invalidation when a new product is added, prompting a discussion of revalidatePath or time-based revalidation. They might also ask what happens if dynamicParams is set to false, which would turn unknown slugs into 404s. Another angle is asking how this behaves in static export mode, where dynamicParams has no effect because there is no server to render on demand.

ONE CONCRETE EXAMPLE: Imagine an e-commerce site with one thousand products. You export generateStaticParams that queries your database and returns the top one hundred best-selling product slugs. These pages are built as static HTML at deploy time for instant loads. When a shopper visits a long-tail product page whose slug was not in that array, Next.js falls back to server-rendering the page on the first request because dynamicParams is true. After that first render, the result can be cached at the CDN or edge depending on your fetch and revalidation setup.