Frontend design rounds are newer than backend ones and interviewers run them inconsistently, which is why having your own structure matters: it keeps the conversation moving and shows judgement even when the prompt is thin. The method below fits 45 to 60 minutes and every Nuxt-shaped product.

Know

• Minute 0–5, requirements. Functional: the three to five core flows. Non-functional: number and kind of users, devices and network, SEO and link previews, personalisation, freshness of data, accessibility level (WCAG 2.2 AA by default), languages and regions, offline, compliance (GDPR, payments), existing stack and team. Ask, do not assume; write them down where the interviewer can see.
• Minute 5–8, scope. State the MVP you will design and what you are explicitly leaving out (admin tooling, mobile app, analytics pipeline). Prioritising is a senior signal.
• Minute 8–15, high-level architecture. Boxes: browser, CDN, the Nuxt app with rendering mode per route group (static marketing, swr catalogue, SSR personalised pages, SPA behind auth), the Nitro layer as backend-for-frontend, the domain APIs or database, third parties (payments, search, email). Arrows: request paths and data flow. Say why each route group renders the way it does.
• Minute 15–22, data and API. Entities and their relationships, the endpoints or queries the UI needs (list with cursor pagination, detail, mutations), what is cached where and for how long, what is realtime, the auth model (session cookie), the error shape.
• Minute 22–30, UI structure and state. Routes and layouts, the key components and their contracts, and the state placement table: URL for shareable view state, useState for small shared UI state, a store for client-owned application state, a keyed cache for server data, cookies for what SSR needs, browser storage for drafts. Hydration and SSR safety come up here.
• Minute 30–40, deep dive. The part the interviewer cares about: search with autocomplete (debounce, cancellation, keyboard, ARIA), an infinite feed (cursor, virtualisation, restoring scroll), checkout (idempotency, optimistic UI limits, validation on both sides), uploads (presigned URLs, progress), permissions (server-side checks, UI hints), realtime (SSE versus sockets, versions). Show mechanism, then trade-off.
• Minute 40–45, cross-cutting. A performance budget (LCP under 2.5 s, INP under 200 ms, script budget), code splitting and lazy hydration, image and font strategy; accessibility built in with a primitive library and tests; security defaults (validation, HttpOnly sessions, CSP); i18n routing; error handling and monitoring; the test strategy.
• Minute 45+, trade-offs and evolution. What you chose and what it costs (edge versus region, SSR CPU versus SEO, a query library versus built-ins), the risks, and how the design evolves (more locales, mobile app sharing the API, scale).
• Notation: a box per system, an arrow per request or data flow with the protocol, a table for rendering per route and another for state placement; numbers where you have them (users, p95 targets, payload sizes).
• What is scored: structure, asking before assuming, depth on demand, explicit trade-offs, pragmatism about team and time, communication. What loses points: coding, jumping to a favourite library, ignoring non-functionals, silence, defending a choice after learning it is wrong.

How it works

The tables that do most of the talking, filled in for a mid-size e-commerce prompt:

Rendering per route group
  /                       prerender          marketing, changes with deploys, crawlable
  /c/:category, /p/:slug  swr 300s           public, shared, changes hourly; cart badge is client-side
  /search                 SSR, no cache      query-dependent, still crawlable for popular terms
  /cart, /checkout        SSR, private       personalised; cookie session; no shared cache
  /account/**             SPA (ssr: false)   behind auth, not indexed, interaction-heavy
  /admin/**               SPA + role check   internal users only

State placement
  filters, page, sort        URL query (parsed with a schema)
  cart                       Pinia store, hydrated from payload, persisted in a cookie (ids + qty only)
  product data, listings     useFetch cache keyed by params; swr on the server
  session/user               nuxt-auth-utils cookie; useUserSession
  locale, currency, consent  cookies (SSR needs them)
  checkout draft             localStorage, restored after hydration
  live stock on PDP          SSE stream, versioned messages

Architecture sketch
  [Browser] --HTTPS--> [CDN: static + swr HTML, /_nuxt immutable]
                          |
                          v
                     [Nuxt on Nitro]  ---> [Product API / DB (Postgres, read replica)]
                       BFF: /api/*    ---> [Search (Meilisearch)]
                       sessions       ---> [Payments (Stripe) via server only]
                       cachedFunction ---> [CMS (headless) with webhooks -> cache invalidation]
                          |
                          v
                     [Queue/outbox tasks: emails, search reindex, image processing]

Deep-dive template, applied to search autocomplete:

Mechanism   input -> 250ms debounce -> $fetch /api/search/suggest?q= with AbortSignal (cancel stale)
            server: Meilisearch prefix query, cachedFunction 30s per normalised q, 10 results
UI          role=combobox / listbox / option, aria-activedescendant, arrow keys, Enter, Escape,
            live region "N results"; results render server-side for full-page /search?q=
Perf        keyboard-first, no layout shift (reserved height), prefetch top result page on hover
Trade-offs  client debounce vs server rate limit; prefix index freshness vs reindex cost;
            what breaks at scale: hot terms -> cache; abusive queries -> rate limit per IP

Exercise

Be able to say