What is the hierarchy of all routing files?

0-2 years experience

1. 1You need to add a new page at /about in a Next.js app. Which file do you create and where should it live in the project structure?
2. 2If you place a file named `blog/[slug].js` under the `pages` directory, what URL pattern will it match and how does Next.js resolve the route?
3. 3What happens if you create both `pages/index.js` and `pages/home.js`? Which one will be served at the root URL?

2-5 years experience

1. 1Your team added a catch‑all route `pages/docs/[...slug].js` but navigating to `/docs` returns a 404. Walk me through how the routing hierarchy determines this behavior and how you would fix it.
2. 2During a refactor we moved a nested dynamic route from `pages/shop/[category]/[id].js` to `pages/store/[category]/[productId].js`. Some links broke. Explain how Next.js builds the routing tree and what you need to update.
3. 3We introduced a custom `_middleware.js` in `pages/api` and observed it running for page routes as well. Explain why the file hierarchy matters for middleware execution.

5-8 years experience

1. 1Our application needs to support both static generation and server‑side rendering for a set of dynamic routes under `/dashboard/[user]/[section]`. Discuss the trade‑offs in placing the files, using `getStaticPaths` vs `getServerSideProps`, and how the routing hierarchy impacts performance at scale.
2. 2We are migrating a large monorepo to Next.js and want to consolidate API routes under a separate folder while keeping page routes untouched. How would you restructure the routing hierarchy, and what edge cases must you guard against (e.g., overlapping dynamic segments, custom server rewrites)?
3. 3Explain how the new App Router (`app` directory) changes the routing hierarchy compared to the legacy `pages` directory, and what implications this has for a team moving from pages to app.

8+ years experience

1. 1Our organization runs multiple Next.js services that share a common set of route conventions. Propose a strategy for standardizing the routing hierarchy across services, considering versioning, backward compatibility, and cross‑team ownership.
2. 2We need to introduce a feature‑flag system that can enable or disable entire sections of the site (e.g., `/beta/*`). How would you design the routing hierarchy and any custom server or middleware to support this without breaking existing routes?
3. 3Discuss the long‑term maintenance implications of mixing static, dynamic, and catch‑all routes in a large codebase. What guidelines would you set for route file placement, naming, and deprecation to keep the hierarchy manageable?