Technology interview warm-up
Vue.js interview questions and Vue JS answers for Vue 3 rounds, with short answers, reactivity scenarios, Composition API, Router, Pinia/Vuex, testing, security, performance, and coding prompts.
On this page
Popular clusters
Short answers
Vue.js is a progressive JavaScript framework for building reactive user interfaces with components. Vue tracks reactive state, renders templates, and patches the DOM when dependencies change. Its practical strength is that simple components stay approachable while larger apps can add Router, Pinia, composables, testing, and build tooling as needed.
Review Vue concepts →Vue 3 introduced a Proxy-based reactivity system, the Composition API, better TypeScript support, fragments, Teleport, Suspense, and a faster runtime. Vue 2 used Object.defineProperty-based reactivity and the Options API as the dominant authoring model. The compatibility concern is that migrations can expose plugin, lifecycle, state-management, and template-assumption differences.
Review Vue 3 patterns →Vue tracks reactive reads during rendering or effects and triggers the dependent work when those values are written. In Vue 3, proxies let Vue observe object property access and updates more flexibly than Vue 2. The important edge case is that extracting values out of a reactive proxy can disconnect them from tracking unless you preserve refs.
Review reactivity →ref wraps a value in an object with a .value property, while reactive returns a proxy for object-shaped state. ref is usually clearer for primitives and replaceable values; reactive can be convenient when mutating properties on a stable object. Destructuring reactive state can break reactivity, so toRef or toRefs may be needed when extracting fields.
Compare ref and reactive →Computed properties are cached derived values based on reactive dependencies. They rerun only when a dependency changes, which makes them better than methods for values used repeatedly in templates. Computed getters should stay pure and synchronous; side effects belong in watch or watchEffect.
Review computed values →A method called from a template can run again whenever the component renders. That is fine for cheap event handlers or formatting, but it is risky for expensive derived values. If the value is derived from reactive state and should be cached, computed is usually the better fit.
Review template methods →Use watch when a reactive value changing should trigger an imperative side effect such as fetching, logging, writing to storage, or syncing external state. A watcher can observe a specific source and gives access to new and old values. It is the wrong tool for pure derived display state, where computed is simpler and safer.
Compare computed and watch →watchEffect automatically tracks reactive values read during its callback and reruns when any of them change. It is useful when dependencies are natural to read inside the effect, but it can be less explicit than watch. A common failure is creating loops by writing to the same reactive state the effect reads.
Review watchEffect traps →nextTick waits until Vue has flushed pending DOM updates from reactive state changes. It is useful when you need to focus, measure, or scroll after the DOM reflects new state. It should not be used as a general fix for unclear data flow; first explain why DOM timing is the actual dependency.
Review nextTick timing →Lifecycle hooks run at specific points in a component lifecycle, such as creation, mount, update, and unmount. They help place setup, DOM-dependent work, subscriptions, and cleanup at the correct time. Bugs often come from reading DOM too early or forgetting to clean up timers, listeners, and external subscriptions.
Review lifecycle hooks →Vue components are reusable UI units that combine template, state, behavior, styles, and a public contract. Single-file components make that contract easier to maintain by keeping the component implementation in one file. The component should expose clear props and emits instead of letting children mutate parent-owned state directly.
Review component scope →Props are inputs owned by the parent and passed down to a child. A child should treat props as read-only and emit an event when it wants the parent to change state. Mutating props directly creates ownership confusion and can be overwritten on the next parent update.
Review prop ownership →Declaring emits documents the events a component can send and helps catch mistakes in event names or payload expectations. It also separates component events from native DOM events. In larger codebases, explicit emits make component contracts safer to refactor.
Review emits contracts →Slots let a parent provide content to a child component while the child controls placement. Named slots support multiple content regions, and scoped slots let the child expose data back to the parent render scope. The trade-off is that too many slot contracts can make component behavior harder to trace.
Review Vue slots →provide and inject pass dependencies through a component tree without threading props through every level. They fit design-system services, form context, deeply nested wiring, or plugin-style dependencies. They can hide coupling, so app-wide business state is often clearer in a store such as Pinia.
Review provide/inject →v-model is syntax sugar for binding a value and listening for an update event. On custom components, it usually maps to a modelValue prop and update:modelValue event, with support for named models and modifiers. Understanding the expansion helps debug controlled form components and event payload bugs.
Review v-model internals →v-if conditionally creates and destroys DOM and component instances, while v-show keeps the element mounted and toggles display. v-if is better when the block is rarely shown, and v-show is better for frequent visibility toggles. State reset and lifecycle cleanup are the key behavioral differences.
Compare visibility strategies →Keys give Vue stable identity for list items across insertions, removals, and reordering. Without stable keys, Vue may reuse DOM or component state for the wrong item. Index keys are fragile for dynamic lists because identity changes when order changes.
Review list keys →Directives are template instructions such as v-bind, v-on, v-if, v-for, v-model, and v-show. They compile into reactive behavior that connects state, events, attributes, rendering, and visibility. Custom directives are useful for direct DOM behavior, but they should not replace component state flow.
Review directives →The Composition API lets Vue components organize logic around features using setup, refs, reactive state, computed values, watchers, and composables. It is especially useful when one feature spans state, lifecycle, and side effects. The main benefit is maintainability and reuse, not simply replacing Options API syntax.
Review Composition API →Composables are functions that encapsulate reusable Composition API logic. They can own refs, computed values, watchers, lifecycle hooks, and cleanup behavior. A good composable has a clear ownership boundary and does not hide surprising global state unless that is its explicit purpose.
Review reuse patterns →Vue Router manages client-side navigation, route matching, nested views, params, query state, and navigation guards. It lets a Vue app behave like multiple pages while avoiding full document reloads. Route guards should have clear allowed, denied, and redirect outcomes to avoid navigation loops.
Review Vue Router →Use local component state until state must be shared across distant components, persisted, debugged centrally, or coordinated through a predictable update path. Pinia is the modern Vue 3 default, while Vuex still appears in older applications. The key decision is state ownership, not moving every value into a global store.
Review store boundaries →Vue renders a virtual node tree and compares the next tree with the previous one to decide what DOM patches are needed. Stable keys help Vue preserve the correct item and component identity during list changes. Diffing is efficient, but it cannot fix unclear identity or excessive reactive dependencies.
Review Vue diffing →Start by reducing unnecessary reactive work, using computed values for cached derived state, keeping keys stable, splitting heavy components, and avoiding expensive template methods. For large lists, use pagination, windowing, or server-side constraints instead of rendering everything. Measure before optimizing because many Vue bottlenecks are data-shape or component-boundary problems.
Open Vue prep path →Beginner to experienced
Start with Vue templates, directives, components, props, emits, v-model, computed values, watchers, lifecycle hooks, and the difference between v-if, v-show, and v-for keys.
Move into reactivity traps, Composition API design, composables, Router guards, Pinia/Vuex boundaries, SSR/Nuxt hydration, testing, security, performance, and production debugging scenarios.
Reactivity + rendering
Vue tracks which reactive values are read while rendering or while running an effect. When one of those values changes, Vue schedules the dependent component or effect instead of rerendering everything immediately. The practical debugging step is to find which reactive read created the dependency.
Review dependency tracking →Destructuring a property out of a reactive object can copy the current value out of the proxy. Later reads may no longer go through Vue tracking, so updates can appear stale. Use toRef or toRefs when extracted properties must remain reactive.
Debug destructuring →Computed getters are meant to return cached derived state from reactive inputs. If a computed getter writes state, fetches data, or mutates external resources, rendering can become unpredictable. Use watch or watchEffect for side effects and keep computed values pure.
Compare computed and watch →Vue batches reactive updates and patches the DOM asynchronously. Reading or focusing DOM immediately after changing state can see the old DOM. nextTick waits for the pending patch, which makes it useful for focus, measurement, and scroll logic.
Review DOM timing →v-if creates and destroys the element or component as the condition changes. That means child state resets, mounted and unmounted hooks can run, and cleanup must be correct. Use v-show when preserving state and avoiding repeated lifecycle work matters more than removing DOM.
Review v-if behavior →Keys tell Vue which item or component instance is the same across renders. Stable keys preserve the right local state during reorder, insertion, and deletion. Unstable or index keys can attach input state, animation state, or component state to the wrong data item.
Review keyed lists →Vue compares virtual nodes to patch only the DOM regions that changed. Static analysis and keyed identity help Vue skip or narrow work. Diffing still depends on clear state and stable identity; it cannot guess business meaning when keys are wrong.
Review diffing →Vue queues reactive updates and flushes DOM patches together to avoid unnecessary repeated work. Multiple state writes in the same tick can produce one DOM update. This improves performance but means DOM-dependent code must wait for the flush when timing matters.
Review rendering pipeline →Component contracts
Props are parent-owned inputs, so mutating them inside a child creates two unclear owners for the same state. Vue may warn, and the next parent render can overwrite the child mutation. Emit an event that describes intent and let the parent update its state.
Review prop ownership →Native events come from DOM elements, while component events are emitted by Vue components as part of their public API. Component events do not automatically bubble like DOM events. Declaring emits makes that boundary explicit and easier to type or refactor.
Compare event boundaries →Scoped slots let a child expose data while the parent controls how that data is rendered. This is useful for reusable list, table, and layout components. The trade-off is that the parent becomes responsible for rendering details, so the slot contract must stay clear.
Review scoped slots →provide/inject reduces prop drilling but creates an implicit dependency between ancestor and descendant. That can make data flow harder to discover and test. Use it for stable context-like dependencies, not as a replacement for every shared state problem.
Review provide/inject →A custom component should treat its model prop as an input and emit update events when the user changes it. It should not mutate the model prop directly. Named models and modifiers can support richer contracts, but the one-way ownership pattern still matters.
Review v-model expansion →Single-file components keep template, script, and style for a component in one explicit module. They make ownership, imports, and local styles easier to reason about than broad global registration. Global components still fit truly shared primitives, but feature components should usually remain local.
Review SFC trade-offs →A component public API is mostly its props, emits, slots, and exposed behavior. The API should describe what the parent can control and what events the child can request. Internal refs, watchers, and DOM details should not leak unless the component is intentionally exposing them.
Review emits contracts →Vue apps scale better when state ownership, feature boundaries, and component contracts are explicit. A flat global store or broad provide/inject tree can hide too much coupling. Clear component boundaries make tests, refactors, and route-level loading safer.
Review architecture choices →Scenarios + code
const state = reactive({ count: 0 });
const { count } = state;
function increment() {
state.count++;
}count is copied out of the reactive proxy, so reads of count no longer go through Vue tracking. Use toRef(state, "count") or toRefs(state) when the extracted value must remain reactive.
Fix destructuring →watchEffect(() => {
total.value = items.value.length + total.value;
});The effect reads total and writes total, so the write can retrigger the same effect. Derived values should be computed, while effects should avoid writing to the same reactive values they depend on.
Review watchEffect loops →<li v-for="(item, index) in items" :key="index">
<input v-model="item.name">
</li>The index key changes meaning when items are inserted, removed, or reordered. Vue can reuse DOM and component state for the wrong item. Use a stable item id as the key.
Debug index keys →const props = defineProps<{ user: { name: string } }>();
function rename() {
props.user.name = 'Ada';
}The child is mutating parent-owned data through an object prop. That hides the update from the component contract and can be overwritten by the parent. Emit an intent event or ask the parent to pass a dedicated update callback.
Review prop mutation →editing.value = true;
inputRef.value?.focus();Changing editing schedules a DOM update, but the input may not exist until Vue flushes that update. Await nextTick before focusing the element. This is a timing issue, not a reason to delay every state change.
Review nextTick →<ProfileForm v-if="showProfile" />v-if destroys and recreates the component, so local form state resets. If the form should preserve state while hidden, v-show or lifting the state may be a better choice. The correct answer depends on whether reset is desired.
Compare v-if and v-show →const fullName = computed(() => {
analytics.track('full-name-read');
return first.value + ' ' + last.value;
});Computed getters can run during rendering and should remain pure. Tracking analytics inside the getter creates a side effect tied to rendering and cache invalidation. Use watch when a state change should trigger external work.
Review computed purity →watch(query, async (value) => {
results.value = await searchUsers(value);
});A slower previous request can resolve after a newer request and overwrite the latest results. Track request identity, cancel stale work when possible, or ignore responses that no longer match the current query.
Practice debounced search →Modern Vue 3
Options API organizes code by option type, such as data, computed, methods, and hooks. Composition API organizes related feature logic together inside setup and composables. Options API can still be fine, but Composition API is usually easier to scale when logic is reused or split by feature.
Review Composition API →script setup is a compile-time syntax for writing Composition API components with less boilerplate. Top-level bindings are directly available to the template, and defineProps and defineEmits make component contracts concise. The trade-off is that developers must understand the compile-time macros instead of treating them like normal runtime functions.
Review setup patterns →A good composable has a clear input and output contract, owns cleanup for side effects it creates, and does not hide surprising shared state. It should be reusable without forcing a component structure. If every consumer needs different lifecycle or ownership rules, the abstraction may be too broad.
Review reuse trade-offs →Pinia has a simpler API, strong TypeScript ergonomics, and fits Vue 3 Composition API patterns well. Vuex still appears in existing apps and teaches useful centralized-state concepts. Migration should focus on store boundaries and update flow, not only syntax replacement.
Review store boundaries →Vue Router 4 encourages returning values from guards instead of relying on next callbacks everywhere. This makes allowed, redirected, and canceled navigation outcomes clearer. Guard code still needs careful async handling to avoid loops or unresolved navigation.
Review router flow →Teleport renders part of a component subtree somewhere else in the DOM, such as moving a modal to a root overlay container. It keeps logical component ownership while changing DOM placement. Focus management, stacking, and cleanup still need to be handled correctly.
Open Vue prep path →Suspense can coordinate fallback UI while async dependencies inside a component tree resolve. It is useful around async setup and route-level loading patterns. The boundary placement matters because too broad a boundary hides too much UI and too narrow a boundary can create noisy loading states.
Open Vue prep path →SSR renders HTML on the server, then the client hydrates it into an interactive Vue app. Nuxt adds routing, data loading, SSR conventions, and deployment structure around Vue. Hydration bugs often come from different server and client output, browser-only data during initial render, or unstable IDs.
Open Vue prep path →Testing + security + performance
Test user-visible behavior through rendered output, interactions, emitted events, validation states, loading, and errors. Vue Test Utils helps mount components and interact with them, while tests should avoid depending on private implementation details. The goal is to prove the component contract, not the exact internal ref names.
Open Vue prep path →Vitest runs assertions, mocks, timers, and test files, while Vue Test Utils renders Vue components and exposes wrapper utilities. Together they cover component behavior and smaller unit logic. A good test still waits for Vue async DOM updates before asserting rendered changes.
Open Vue prep path →After changing reactive state or triggering DOM events, wait for Vue to flush updates with nextTick or helper utilities. For promises and network-like flows, flush pending promises before asserting final UI. Otherwise tests may pass or fail based on timing instead of behavior.
Review update timing →Mount the component, trigger the user action, and assert the emitted event name and payload. This verifies the child contract without requiring a parent component. For v-model components, assert the update event rather than mutating the prop in the child.
Review emits →v-html inserts raw HTML into the DOM, so untrusted content can create XSS if it is not sanitized before rendering. Interpolation escapes text by default, but v-html intentionally bypasses that escaping. Use it only for trusted or sanitized HTML and keep user-controlled input out of DOM sinks.
Review interpolation safety →Sanitize rich text before it reaches v-html, restrict allowed tags and attributes, and avoid user-controlled URLs or scripts. Backend validation and a Content Security Policy reduce the impact of mistakes. Client-side rendering choices do not replace server-side trust boundaries.
Review DOM safety →Start with browser performance tools and Vue Devtools to identify expensive components, renders, and data changes. Then reduce unnecessary reactive dependencies, expensive template methods, unstable keys, and oversized lists. Optimization should follow measurement instead of guessing.
Review rendering costs →Leaks usually come from timers, event listeners, subscriptions, observers, or async callbacks that outlive the component. Cleanup belongs in the lifecycle owner that created the resource. Watchers and effects should also have clear invalidation or teardown behavior when they create external work.
Review cleanup hooks →Critical for coding rounds and edge-case discussion.
Implement a Vue 3 debounced search input that calls a fake API. Use a watcher with a timeout, cancel stale calls, and manage loading/error/empty states. This mirrors real-world search UX. Concepts: vue, composition-api,…
Open Vue coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a Vue 3 autocomplete search input. It should debounce queries, show a dropdown with results, support keyboard navigation (↑/↓/Enter/Esc), and close on outside click. Keep the UI styles exactly as provided.
Open Vue coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a contact form in a Vue 3 single file component using the Composition API. You will only work inside <script setup> in App.vue. The template and styles are already provided for you. Validate the user's input…
Open Vue coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a Material-like invite field in Vue 3. As users type, show autocomplete suggestions, convert selections into removable chips, and support keyboard shortcuts (Enter/comma/backspace).
Open Vue coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a 3-step signup flow in Vue 3 that collects basic info, address info, and shows a summary with a final submit action. Each step should be validated before the user can proceed.
Open Vue coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a small Vue 3 UI that renders a parent checkbox and multiple child checkboxes. The parent controls all children, and the children keep the parent in sync (checked, unchecked, or indeterminate). Vue focus: compute…
Open Vue coding interview challenge →Need more implementation reps? Open the full coding list or follow a study plan.
Frequently tested in explanation-heavy rounds.
Computed properties and watchers both react to reactive changes, but they solve different problems: <strong>computed</strong> is for <strong>derived state</strong> (cached, declarative), while &l…
Open Vue interview question →Frequently tested in explanation-heavy rounds.
Explain how Vue slots work (default, named, and scoped slots), what problem they solve, and how slot props allow a child component to pass data back to the parent’s template while still keeping one-way data flow.
Open Vue interview question →Frequently tested in explanation-heavy rounds.
Compare v-show and v-if through DOM cost, lifecycle impact, preserved state, and the performance/debug trade-off between cheap toggles and true unmounting.
Open Vue interview question →Frequently tested in explanation-heavy rounds.
Explain the real difference between ref() and reactive() in Vue 3’s Composition API, when each is the better choice (primitives vs objects, replacement vs mutation, destructuring, template unwrapping), and the most comm…
Open Vue interview question →Frequently tested in explanation-heavy rounds.
Explain the difference between watch() and watchEffect() in Vue 3, when each one runs, how dependency tracking works (explicit vs automatic), and the common patterns that accidentally cause infinite update loops.
Open Vue interview question →Frequently tested in explanation-heavy rounds.
Computed properties are cached derived state in Vue. Strong answers compare them with template methods, show a real performance-use case like cart totals or filtered lists, and explain why computed getters should stay p…
Open Vue interview question →Need more concept coverage? Open the full concepts list or browse company packs.
Interview prep context
Vue prompts are grouped by FrontendAtlas importance signals and reviewed for framework-specific interview traps.
Quick answers
Yes. The page starts with Vue fundamentals, then moves into experienced-developer topics such as reactivity traps, Composition API design, Router, Pinia/Vuex, scenarios, testing, security, and performance.
Yes. It covers Vue 3 reactivity, ref, reactive, computed values, watch, watchEffect, script setup, composables, Composition API trade-offs, Router, Pinia/Vuex, Teleport, Suspense, SSR, and Nuxt-style concerns.
Yes. The reactivity sections cover ref, reactive, computed values, methods, watch, watchEffect, nextTick, dependency tracking, destructuring traps, virtual DOM diffing, and update batching.
Yes. The scenario section covers destructuring that breaks reactivity, watcher loops, unstable v-for keys, prop mutation, nextTick timing, v-if lifecycle resets, computed side effects, and stale async search results.
Yes. It covers Vue Test Utils, Vitest, async DOM assertions, emitted events, v-html XSS risk, safe rich text, profiling, update dependencies, and cleanup for timers, listeners, and external subscriptions.
Start with the Vue coding preview on this page, then move into debounced search, autocomplete, tabs, shopping cart, and the Vue prep path when you need a structured practice sequence.
Start with one route first. Then expand into Question Library, Study Plans, and Company Prep only when you need them.
Recommended preparation
Start with the interview preparation guide and shared baseline, then tighten Vue coding, concepts, and follow-up depth.