What are Next.js Route Groups and a practical use case?

What's really being asked

This question tests whether you understand the App Router file-system conventions beyond basic nested folders. Specifically, the interviewer wants to know if you recognize that folders normally map to URL segments, and that Route Groups are the exception. They are also checking if you can use this feature to solve real architectural problems like sharing layouts across sections or organizing code by domain without affecting the public URL structure.

The full answer

A strong response starts by defining Route Groups as folders wrapped in parentheses such as (marketing) or (shop) that are completely omitted from the URL path. Next, it explains that these groups let you apply different root layouts to different parts of an application without introducing extra path segments. Then it provides a practical use case, such as splitting a project into (marketing) and (app) directories where each has its own layout.tsx but routes inside them remain at top-level URLs like / and /dashboard. Finally, it notes that Route Groups can be nested and that a group can contain its own layout.js, loading.js, or error.js files that only affect the routes within that group.

The mistakes people make

Candidates often confuse Route Groups with dynamic segments like [id] or [...catchAll], or they claim that the parenthesized folder name appears in the URL. Another red flag is suggesting Route Groups work in the Pages Router; they are an App Router convention only. Some engineers also incorrectly state that Route Groups affect caching behavior or SEO, or they propose using them as a replacement for middleware when the goal is simply URL rewriting.

What usually comes next

An interviewer might ask how you would create multiple root layouts for different sections of a site, or whether you can nest Route Groups inside one another. They may also ask how Route Groups interact with Parallel Routes and Intercepting Routes, or challenge you to explain what happens when a route belongs to multiple groups. Another common follow-up is when to choose a Route Group over a standard layout file in a non-grouped folder.

A concrete example

Consider an e-commerce application where the browsing experience needs a rich navigation header but the checkout flow needs a minimal distraction-free layout. You create app/(shop)/layout.tsx with the full header and place app/(shop)/page.tsx so the homepage lives at /. Separately, you create app/(checkout)/layout.tsx with a slim header and place app/(checkout)/cart/page.tsx so the cart lives at /cart. The (shop) and (checkout) names never appear in the browser address bar, yet each section maintains independent layouts and clean file colocation.