Compare Pages Router and App Router file-based routing conventions and capabilities

WHAT THIS TESTS: This question tests whether you understand that the App Router is not a cosmetic change but a fundamental rethinking of how file system conventions map to route segments and UI boundaries. Interviewers want to see that you know Pages Router treats JavaScript files as route endpoints, while App Router treats folders as route segments and uses special files to render UI at different levels of the tree. They also want to hear that you understand the implications for layouts, loading states, error handling, and data fetching defaults.

A GOOD ANSWER COVERS: First, the core convention difference: in Pages Router, pages/posts/[slug].js is both the route definition and the page component, but in App Router, app/posts/[slug]/page.js is just the leaf UI inside a folder that represents the segment. Second, nested layouts: App Router lets you colocate layout.js in any route folder to create nested layouts that persist across navigation, whereas Pages Router only gives you a single _app.js and _document.js at the root. Third, segment-level primitives: App Router introduces loading.js for automatic Suspense boundaries, error.js for error boundaries, template.js for re-mounting layouts, and not-found.js for 404 handling, none of which exist as file conventions in Pages. Fourth, API patterns: Pages Router uses pages/api for API routes, while App Router uses route.js files inside the app tree to create Route Handlers. Fifth, rendering model: App Router defaults to React Server Components in page.js unless you add the use client directive, while Pages Router components are always client bundles even when server-rendered.

COMMON WRONG ANSWERS: A major red flag is saying the App Router is just the Pages Router with an app folder instead of pages. Another is claiming dynamic route syntax changed; it did not, brackets still denote dynamic segments, but the file placement and behavior did. Candidates who say App Router removed API routes or who confuse next/router with next/navigation also signal they have not used App Router in production. Finally, describing App Router as purely a performance optimization misses the point; it is an architecture change for nested routing and server-first rendering.

LIKELY FOLLOW-UPS: The interviewer may ask when you would still choose Pages Router over App Router, or how you would migrate an existing site. They might dig into how layout.js preserves state across navigation while template.js re-mounts, or ask you to explain how parallel routes and intercepting routes work as advanced App Router features. Another common follow-up is how data fetching differs: getServerSideProps and getStaticProps versus async Server Components or fetch caching semantics.

ONE CONCRETE EXAMPLE: Imagine a dashboard at /dashboard/settings. In Pages Router, you would have pages/dashboard/settings.js and a single _app.js wrapping every page. If you wanted a dashboard shell with a sidebar, you would have to build it into the page or use a layout component manually. In App Router, you create app/dashboard/layout.js for the shell, app/dashboard/settings/page.js for the specific page, and app/dashboard/loading.js for a skeleton while settings data loads. The layout persists when the user navigates from settings to profile, and the loading state is automatically tied to that segment.