Episode 2 — React Frontend Architecture NextJS / 2.18 — Getting Started with NextJS
2.18 — Interview Questions: Getting Started with Next.js
Pair with 2.18.a (why teams adopt), 2.18.b (framework vs library), 2.18.c (tooling & env), 2.18.d (App Router URLs), 2.18.e (layouts, templates, metadata).
Beginner
Q1. In one sentence, why is Next.js popular?
Model answer: It wraps React with file-based routing, server rendering primitives, and deployment-friendly defaults so teams ship full-stack web apps with less custom glue and better baseline performance for SEO and UX.
Q2. Is Next.js a replacement for React?
Model answer: No—React remains the UI library. Next supplies the application framework around it: routing conventions, rendering pipeline, and server features. You still think in components and hooks.
Q3. What file defines the /about page in the App Router?
Model answer: Typically app/about/page.tsx. The folder path under app/ maps to the URL; page.tsx marks a routable segment.
Q4. What do npm run dev, npm run build, and npm start roughly do?
Model answer: dev runs the hot-reload development server; build compiles the app for production (and reports static/dynamic hints); start runs the production server output from build. Exact flags vary by host, but that is the mental tripod.
Q5. Where do local secrets go—and what must never be prefixed NEXT_PUBLIC_?
Model answer: Local developer secrets go in .env.local (gitignored). Only non-secret values belong in NEXT_PUBLIC_* because they are exposed to the browser bundle. Database URLs and API keys must stay server-only.
Intermediate
Q6. Explain framework vs library using Next and React.
Model answer: A library (React) provides building blocks you compose inside your architecture. A framework (Next) defines extension points—page.tsx, layout.tsx, route.ts—and calls your code inside its lifecycle. Inversion of control is the technical hallmark.
Q7. What is the difference between layout.tsx and template.tsx?
Model answer: A layout wraps children and does not remount when navigating between sibling routes under it—good for persistent chrome. A template remounts on navigation—useful for animations or resetting local subtree state deliberately.
Q8. What does NEXT_PUBLIC_ mean for environment variables?
Model answer: Variables prefixed with NEXT_PUBLIC_ are exposed to the browser bundle. Anything secret (API keys, DB URLs) must not use that prefix and should only be read in server modules.
Q9. How do route groups affect URLs?
Model answer: Parentheses folders like app/(marketing)/page.tsx organize code and layouts but do not add a URL segment—they are invisible in the path. Useful to separate concerns without changing public routes.
Q10. What are dynamic segments, catch-all, and optional catch-all?
Model answer: [id] captures one path segment. [...slug] captures one or more segments as an array. [[...slug]] makes the catch-all optional so the route also matches the parent path with zero extra segments.
Q11. Where does middleware run relative to page.tsx?
Model answer: middleware.ts runs at the edge of the request, before rendering the matched routes—good for redirects, auth gating, and geo headers. It should stay fast; heavy DB work here is usually a smell unless you accept latency trade-offs.
Q12. What belongs in export const metadata vs generateMetadata?
Model answer: Static metadata is for fixed titles/descriptions/OpenGraph. generateMetadata is for async or request-derived SEO fields (e.g., load a CMS document by slug). Both participate in the head management story for Server Components.
Advanced
Q13. When would you not choose Next for a new greenfield web app?
Model answer: When the deliverable is a tiny embed, a library demo, or the org already standardized on another framework with heavy investment. Also when hosting constraints forbid a Node server and output: 'export' cannot satisfy dynamic needs—then a static SPA or different stack may win.
Q14. How do you decide App Router vs Pages Router for an existing codebase?
Model answer: Default App Router for new work unless there is a hard dependency on legacy patterns. Migration is often incremental with app/ alongside pages/. I weigh team familiarity, library/plugin compatibility, and feature parity (some edge cases still differ by version).
Q15. How do Server Components change the “getting started” mental model for data fetching in page.tsx?
Model answer: page.tsx can be async and await data on the server without shipping the data-fetching implementation to the client bundle—when you stay in the Server Component graph. Client interactivity still moves behind 'use client' islands.
Quick-fire
| # | Question | One-line answer |
|---|---|---|
| 1 | Default router in App Router? | File system under app/ |
| 2 | Server component default? | Yes in app unless 'use client' |
| 3 | Root layout must include? | <html> and <body> |
| 4 | Dynamic segment syntax? | [param] |
| 5 | Catch-all? | [...slug] |
| 6 | Optional catch-all? | [[...slug]] |
| 7 | API in App Router file? | route.ts exporting HTTP verbs |
| 8 | Colocation pattern? | Private _folder or shared components/ per team rules |
| 9 | Parallel routes folder? | @slot segments (advanced layout feature) |
| 10 | notFound() usage? | Trigger 404 UI for missing resources |
Answers at a glance (maps to 2.18.a → 2.18.e)
| Lesson | What interviewers expect you to recall |
|---|---|
| 2.18.a — Why Next | Routing + rendering + server primitives + deploy integration reduce glue; better SEO/perf defaults than hand-rolled SPA. |
| 2.18.b — Framework vs library | React draws UI; Next owns lifecycle and conventions (IoC). |
| 2.18.c — Setup | create-next-app, TS/ESLint, .env.local, scripts (dev/build/start/typecheck). |
| 2.18.d — Routing | page.tsx ↔ URL; groups ( ); dynamics [ ], [...], [[...]]; route.ts for HTTP; middleware.ts early in pipeline. |
| 2.18.e — Layouts | Nested shell persists; template remounts; metadata / generateMetadata for head. |