Key difference between Server and Client Components in Next.js?

WHAT THIS TESTS: This question checks if you understand the App Router's dual-environment model and can articulate why Next.js defaults to server rendering. Interviewers want to see that you know where code executes, what ships to the browser, and how that impacts bundle size, data access, and security. It also reveals whether you treat Next.js as a plain React SPA or as a framework with distinct server and client boundaries.

A GOOD ANSWER COVERS: First, execution environment: Server Components run only on the server and their code never downloads to the browser, which eliminates client bundle size for those components. Second, capability differences: Server Components can import server-only modules like database drivers or filesystem utilities, while Client Components can use React hooks like useState and useEffect, event handlers like onClick, and browser APIs like localStorage. Third, the opt-in rule: in the App Router, every component is a Server Component by default, and you must add the "use client" directive at the top of a file to create a Client Component. Fourth, the decision criteria: you choose a Client Component precisely when you need interactivity, client-side state, effects, or browser-only APIs; everything else should stay on the server.

COMMON WRONG ANSWERS: A major red flag is saying that Client Components do not run on the server; in reality, they render on the server during SSR and then hydrate in the browser. Another mistake is claiming that Server Components cannot render HTML; they absolutely do, they just do it without client-side JavaScript. Candidates also err by stating that "use client" is required for all components or that hooks work in Server Components. Finally, suggesting that you should wrap entire pages in "use client" just because one small element needs interactivity shows a lack of understanding of granular component boundaries.

LIKELY FOLLOW-UPS: The interviewer may ask how you pass data from a Server Component to a Client Component, which is done via props, but you cannot import a Server Component directly into a Client Component unless it is passed as a child or prop. They might ask about the impact on bundle size if you mark too many components as client components. Another follow-up is whether you can use context in Server Components, which you cannot, so shared state must be handled carefully across the boundary. You might also be asked how third-party packages that use hooks should be imported, which requires marking the consuming component as a client component.

ONE CONCRETE EXAMPLE: Imagine an e-commerce product page. The page layout, product description, and reviews list should be Server Components so they can fetch data directly from a database and send no JavaScript to the browser. The "Add to Cart" button, however, needs onClick handlers and useState to manage loading and confirmation feedback, so it should be a Client Component imported into that otherwise server-rendered page. This keeps the client bundle small while isolating interactivity to exactly the pieces that need it.