Nuxt Interview Questions

A curated set of Nuxt interview questions, ordered roughly from fundamentals to implementation detail — the kind you'll actually be asked in real screens and on-sites.

Fundamentals#

Q: What does Nuxt give you that plain Vue + Vue Router doesn't? Nuxt is a framework, not just a library — it adds file-based routing generated automatically from the pages/ directory instead of a hand-written router config, server-side rendering and static generation options out of the box, auto-imported components and composables with no import statements, and built-in server API routes under server/api/, all with sensible zero-config defaults you can still override in nuxt.config.ts.

Q: What are Nuxt's three rendering modes, and how do you choose between them? Universal rendering (the default) renders full HTML per request on the server, then hydrates it client-side — the right choice for most public-facing apps, since it's fast on first paint and SEO-friendly. SPA mode (ssr: false) skips server rendering entirely and renders everything in the browser, suiting internal tools where SEO doesn't matter. Static generation (nuxt generate) pre-renders every route to a static file at build time, suiting content that's identical for every visitor, like documentation or a marketing site.

Q: How do Nuxt's auto-imports work without explicit import statements? At build time, Nuxt scans conventional directories — components/, composables/, plus Vue's own APIs like ref and computed — and generates the necessary import statements automatically based on what's actually referenced in each file, injecting them behind the scenes before compilation. This removes the repetitive import boilerplate at the cost of a small amount of "magic" — a component or composable seems to be globally available, when it's really auto-inserted per-file by the build step.

Q: What is a Nuxt module, and why does the ecosystem rely on them so heavily? A Nuxt module is a package that hooks directly into Nuxt's build and runtime lifecycle to configure itself, instead of requiring a consumer to wire it into a bundler config by hand. Because so many common needs — Tailwind, image optimization, an ORM's dev tooling — are shipped as modules, adding significant functionality is usually a one-line addition to the modules array in nuxt.config.ts rather than a manual build configuration change.

Q: What's the difference between useFetch and useAsyncData? useFetch(url) is a convenience wrapper for the common case of fetching from a single URL. useAsyncData(key, handler) is the more general primitive underneath it, used when the async logic is more than one fetch call — combining multiple requests, wrapping a non-fetch async operation, or needing explicit control over the cache key used for deduplication.

Q: How does Nuxt avoid fetching data twice — once on the server, once again on the client during hydration? When useFetch/useAsyncData runs during server-side rendering, its result is serialized into the initial HTML payload sent to the browser. When the client-side app hydrates that markup, it reads the already-fetched data out of that payload instead of re-running the fetch, so the same data is used to produce both the server-rendered HTML and the now-interactive client app. Calling a plain fetch/$fetch directly in a component bypasses this mechanism entirely and does genuinely fetch twice.

Auth and deployment#

Q: Why does Nuxt's useCookie composable exist instead of just reading document.cookie directly in a component? document.cookie only exists in a browser environment, so reading it directly breaks during server-side rendering, where there's no document object at all. useCookie is a Nuxt composable built to work correctly on both sides — it reads (and can set) a cookie's value during SSR on the server and during client-side navigation in the browser, which is exactly what a route middleware checking an auth cookie needs, since that middleware itself runs on both the server and the client depending on how the route was reached.

Q: Why should a server/api/ route protecting sensitive data re-check authentication itself, even if the page calling it is already guarded by route middleware? Route middleware protects navigation to a page, not the underlying API endpoint — the endpoint is still reachable directly by URL, by a script, or by a stale client that bypasses the page entirely. An endpoint that trusts "only a properly-guarded page will ever call this" is one missed edge case away from leaking data to an unauthenticated request; checking the session independently inside the server/api/ handler itself closes that gap.

Q: What's the practical difference between nuxt generate, a server deployment (nuxt build/nuxt start), and SPA mode (ssr: false)? nuxt generate pre-renders every route to static HTML at build time and needs no server at runtime at all — right for content identical to every visitor, like docs or a marketing site. A server deployment builds a real Node.js (or Nitro-compatible) server that renders per request, needed for anything with authentication, live per-request data, or server API routes. SPA mode skips server rendering entirely and renders everything client-side from an almost-empty HTML shell — the simplest deployment target, but poor for SEO or slow-connection first paint, so it suits an internal tool more than a public-facing site.

Q: Why is the split between runtimeConfig's server-only section and its public section a security boundary, not just an organizational one? Anything under runtimeConfig.public is embedded directly into the client-side JavaScript bundle and readable by any visitor who opens their browser's dev tools. Everything else under runtimeConfig stays server-only, readable only from server-side code like server/api/ handlers. A real secret — an API key, a signing key — placed under public by mistake ships to every visitor's browser exactly as if it had been hardcoded into client-side code directly.