25 Vue.js interview questions

Listen for: A strong answer starts with reading behavior and tests before moving code. Listen for extracting small presentational components, moving API and derived state into composables, replacing unnecessary watchers with computed values, keeping props and emits explicit, and making incremental commits that preserve behavior.

Red flag: They immediately propose a full rewrite or moving everything to global state without understanding the component's responsibilities.

Listen for: Good candidates check whether the list is reactive, how items are mutated, whether the total is computed from the right source, and whether keys are stable. They should mention Vue Devtools, reproducing with a small case, checking async timing, and avoiding stale local copies of props or store state.

Red flag: They assume Vue reactivity is broken and start adding forceUpdate or random watchers.

Listen for: Look for judgment, not definitions. Computed should be described as cached derived state used by the template or other logic. Watchers should be reserved for side effects such as syncing URL params, calling APIs, analytics, or bridging non-Vue libraries, with attention to cleanup and avoiding infinite loops.

Red flag: They use watchers for most derived data because it feels easier to control.

Listen for: A solid answer considers ownership, lifetime, shareability, persistence, and navigation. Local UI state can stay in the component; reusable behavior can move to a composable; cross-route domain state may belong in Pinia; filters, pagination, and shareable view state often belong in query params.

Red flag: They put all state in Pinia by default.

Listen for: Listen for testing behavior rather than implementation details. They might use Vue Test Utils with Vitest, mock network calls with MSW or a service boundary, assert loading and empty states, use accessible queries where possible, and add a Playwright test for the critical user path.

Red flag: They only test snapshots or private component methods.

Listen for: Strong answers mention semantic HTML first, focus management, ARIA only when necessary, Escape and arrow key behavior, visible focus styles, tab order, screen reader labeling, and testing with keyboard and accessibility tooling. They should know when to use a native select instead of a custom widget.

Red flag: They treat accessibility as a CSS polish task to do after the feature is complete.

Listen for: A good answer separates route-level orchestration from reusable components, keeps filter state shareable through query params, centralizes domain state only when multiple screens need it, and isolates chart or table adapters. Listen for composables for fetching and transformations, typed interfaces, and avoiding one giant dashboard component.

Red flag: They describe a single Pinia store and a deeply nested component tree without clear ownership boundaries.

Listen for: Look for splitting by domain or workflow, removing component-only UI state, moving reusable fetch logic into services or composables, keeping getters for true derived state, and adding characterization tests before changes. They should discuss migration strategy, compatibility, and avoiding circular store dependencies.

Red flag: They split files mechanically without changing responsibilities or test coverage.

Listen for: Strong candidates distinguish server state from client state. They may mention TanStack Query for Vue, Nuxt useFetch/useAsyncData, or a thin service layer with explicit cache rules. Listen for stale data handling, cancellation, optimistic updates when appropriate, error states, retries, and invalidation after mutations.

Red flag: They store all API responses permanently in Pinia and manually remember to refresh them.

Listen for: Good answers start with profiling in browser tools and Vue Devtools, identifying expensive renders, unstable keys, broad reactive dependencies, and heavy computed work. They should mention virtualization, debouncing expensive operations, shallowRef or markRaw for large immutable structures, component boundaries, and measuring after each change.

Red flag: They guess at optimizations such as memoization everywhere without profiling.

Listen for: Listen for explicit inputs and outputs, no unexpected side effects during import, dependency injection for clients or timers, cleanup with onScopeDispose, typed return values, and clear naming. They should separate pure utilities from lifecycle-aware composables and avoid singletons unless shared state is intentional.

Red flag: They put module-level reactive objects in composables without considering lifetime or test isolation.

Listen for: A strong response breaks guard responsibilities apart, makes auth state initialization explicit, avoids racing async checks, and keeps unsaved-change prompts close to the editing feature. They should mention route meta, clear redirect rules, tests for navigation flows, and logging enough context to diagnose failures.

Red flag: They add more conditions to the same global beforeEach guard until the bug disappears.

Listen for: Look for schema-based validation with tools such as Zod, Valibot, VeeValidate, or FormKit when appropriate, plus server-side validation handling. Strong candidates discuss field-level feedback, debounced async checks, accessibility, preserving dirty state, preventing duplicate submits, and keeping business rules shared or clearly duplicated.

Red flag: They rely only on HTML required attributes or validate everything after submit with vague error messages.

Listen for: A strong answer proposes an incremental plan based on risk and value: dependency audit, build tooling, test safety net, compatibility constraints, component migration strategy, and team conventions. They should avoid converting code just for style, prioritize risky libraries, and define completion criteria beyond syntax changes.

Red flag: They propose stopping product work for a big-bang rewrite.

Listen for: Listen for lightweight conventions: folder structure by domain or feature, component API guidelines, TypeScript rules, routing patterns, testing expectations, linting, and examples. Strong candidates involve the team, document trade-offs, enforce only what matters in CI, and revisit standards when evidence changes.

Red flag: They rely on personal preference and code review comments instead of shared, documented decisions.

Listen for: Good answers separate product bugs from test design issues. They mention stable selectors, controlling network with MSW or test fixtures, reducing dependence on timing, isolating state, reviewing CI environment differences, moving coverage to lower-level tests where appropriate, and tracking flake causes over time.

Red flag: They suggest deleting most E2E tests or only increasing timeouts.

Listen for: Strong candidates discuss organizational boundaries, independent deployment needs, shared design system contracts, routing ownership, dependency duplication, runtime failure modes, observability, and local development. They should also explain simpler alternatives such as packages, monorepos, or feature modules when team coordination is the real problem.

Red flag: They treat micro-frontends as a default scaling pattern for any large Vue app.

Listen for: Look for production-focused thinking: bundle analysis, code splitting, hydration cost if SSR is used, third-party scripts, image delivery, API latency, caching headers, long tasks, and field monitoring. They should connect metrics like LCP, INP, and CLS to specific Vue and delivery decisions.

Red flag: They only profile on their laptop and assume production users have similar devices and networks.

Listen for: A senior answer weighs routing complexity, SEO, SSR or SSG needs, authentication, deployment model, team familiarity, edge constraints, data fetching, and operational complexity. They should understand Nuxt 3/4 strengths while recognizing that a simpler Vite SPA may be better for authenticated internal tools.

Red flag: They choose Nuxt or avoid Nuxt based only on personal preference.

Listen for: Listen for API versioning, migration guides, codemods where useful, visual regression tests, accessibility checks, release notes, deprecation windows, and communication with consumers. Strong candidates balance consistency with product needs and provide escape hatches without letting the system fragment.

Red flag: They push breaking changes and expect application teams to fix everything immediately.

Listen for: Look for route meta and guard design, tenant and region resolution, permission checks in both UI and API, feature flag boundaries, form state persistence, typed API clients, error handling, and observability. Strong answers avoid scattering authorization checks across templates and plan for testing roles and tenants.

Red flag: They rely on hiding menu items in the UI as the main security model.

Listen for: Strong answers separate layout state from server data, define widget contracts, isolate chart libraries, use virtualization where needed, and handle refresh, cancellation, and backpressure. They should discuss persistence format, undo or draft state, performance profiling, and graceful degradation when one widget fails.

Red flag: They place all widget data and layout behavior in one global store.

Listen for: Listen for route rendering strategy, caching, hydration cost, image optimization, code splitting, cart state boundaries, personalization without destroying cacheability, and API error fallbacks. Strong candidates discuss Core Web Vitals, third-party script control, server and client data ownership, and deployment observability.

Red flag: They enable SSR everywhere without considering caching, personalization, or hydration trade-offs.

Listen for: A good answer covers package boundaries, semantic versioning, Storybook or Histoire documentation, accessibility requirements, visual regression testing, design token delivery, theming, contribution workflow, and migration support. They should balance governance with product speed and define what belongs outside the shared library.

Red flag: They try to put every product-specific component into the shared library.

Listen for: Strong candidates cover local persistence with IndexedDB, sync queues, idempotent mutations, conflict detection, attachment upload strategy, optimistic UI, retry policies, and clear user feedback. They should separate transient UI state from durable offline data and plan tests for network changes and partial failures.

Red flag: They assume localStorage plus a retry button is enough for reliable offline behavior.