How do you create a /blog/[slug] route and access the slug value?

WHAT THIS TESTS: This question probes whether you understand Next.js file-system routing conventions and whether you know the boundary between the App Router and the Pages Router. At the senior level, interviewers care that you can articulate why the access pattern differs by rendering environment, not just recite syntax.

A GOOD ANSWER COVERS: First, the file structure. In the App Router, you create a folder named app/blog/[slug] and place a page.js file inside it. The brackets tell Next.js to match any single path segment and expose it as a parameter. Second, how you read the value depends on whether the component is a Server Component or a Client Component. A Server Component receives params as a direct prop, so you destructure it from the function signature like export default function BlogPost({ params }) and await or destructure slug from params. A Client Component cannot receive the same server prop directly in the same way, so you import useParams from next/navigation and call it inside the component body to get an object containing the slug key. Third, in the legacy Pages Router, the convention is different: you create pages/blog/[slug].js and access the value via useRouter imported from next/router, reading router.query.slug. Fourth, a senior candidate should mention generateStaticParams for App Router, which lets you tell Next.js which slugs to pre-render at build time, turning a dynamic segment into static HTML.

COMMON WRONG ANSWERS: A major red flag is suggesting window.location.pathname and manually parsing the string. Next.js abstracts the router so components remain testable and isomorphic. Another red flag is importing useRouter from next/router inside an App Router project; that hook is for Pages Router only and will not work correctly in the app directory. Similarly, saying you would use useParams from next/router is wrong because that hook lives in next/navigation. Confusing query strings with route parameters is also a signal of weak routing knowledge.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle catch-all routes like [...slug] or optional catch-all routes like [[...slug]]. They might also ask how you would type the params object in TypeScript, which involves defining the page props interface with params as a Promise or object depending on the Next.js version. Another common follow-up is how you would fetch data for a specific slug inside a Server Component, which opens the door to discussing async page components and error boundaries.

ONE CONCRETE EXAMPLE: Imagine a blog at app/blog/[slug]/page.js. The Server Component would look like export default async function Page({ params }) { const { slug } = await params; return an h1 element that renders the slug text }. If you needed interactivity and added a client button, you would create a separate client component inside the same folder, mark it with use client, and read const { slug } = useParams() to know which post the user is viewing.