Svelte interview questions

What a strong answer covers

• Describe Svelte's compile-time approach: Svelte analyzes component code at build time and generates highly optimized JavaScript to directly update the DOM.
• Explain that reactivity is achieved through simple variable assignments (`=`) within the `<script>` block, which the compiler transforms into DOM update logic.
• Contrast with React/Vue: No virtual DOM diffing at runtime, no need for `useState`/`ref` hooks or observable wrappers; Svelte avoids runtime overhead.
• Mention that Svelte's approach leads to smaller bundle sizes and potentially faster performance due to less runtime work.

Where people lose the point

• ×Incorrectly stating Svelte uses a virtual DOM or a similar runtime diffing mechanism.
• ×Believing Svelte requires special functions (like `setState` or `ref.value`) to trigger updates.
• ×Failing to emphasize the compile-time aspect as the core differentiator.

What a strong answer covers

• Explain that props are declared in the child component using `export let propName;` within the `<script>` tag.
• Demonstrate how a parent component passes data as attributes to the child component instance (e.g., `<ChildComponent myProp={value} />`).
• Describe the data flow as primarily one-way: parent to child. Changes in the parent's prop value automatically update the child.
• Mention that while `bind:` directives exist for two-way binding, the default and recommended pattern is one-way.

Where people lose the point

• ×Attempting to directly modify a prop's value from within the child component.
• ×Confusing Svelte's prop declaration with other frameworks' prop types or interfaces.
• ×Not mentioning the `export let` syntax for prop declaration.

What a strong answer covers

• Explain the use of `{#if expression}` blocks for conditional rendering.
• Demonstrate how to include `{:else if expression}` and `{:else}` clauses for more complex conditions.
• Provide a simple code example showing an `{#if}` block controlling the visibility of an element.
• Mention that these blocks are compile-time directives, generating efficient JavaScript for DOM manipulation.

Where people lose the point

• ×Trying to use JavaScript `if` statements directly in the template outside of a script block.
• ×Forgetting the `#` and `:` syntax for Svelte's control flow blocks.
• ×Not understanding that the condition is a reactive expression.

What a strong answer covers

• Explain the use of the `{#each array as item}` block for iterating over arrays and rendering elements for each item.
• Demonstrate how to access the `item` and optionally `index` within the block.
• Emphasize the importance of providing a `key` (e.g., `{#each array as item (item.id)}`) for efficient DOM updates.
• Explain that the `key` helps Svelte identify individual items in the list, allowing it to reorder, add, or remove items without re-rendering the entire list, preserving component state.

Where people lose the point

• ×Omitting the `key` when rendering dynamic lists, leading to potential performance issues or incorrect state preservation.
• ×Using the array index as a key when items can be reordered, added, or removed.
• ×Not understanding that `{#each}` is a compile-time directive.

What a strong answer covers

• Explain that Svelte uses the `on:` directive to attach event listeners to DOM elements (e.g., `on:click`, `on:input`).
• Demonstrate how to assign a JavaScript function directly to the `on:` directive (e.g., `<button on:click={handleClick}>`).
• Mention that event handlers receive the native DOM `event` object as their first argument.
• Discuss event modifiers (e.g., `on:click|once`, `on:keydown|enter`) for common patterns like preventing default behavior or stopping propagation.

Where people lose the point

• ×Trying to use `addEventListener` directly in the template or `onMount` for simple event handling.
• ×Forgetting the `on:` prefix for event directives.
• ×Not knowing about event modifiers for common use cases.

What a strong answer covers

• Explain `onMount`: runs after the component has been rendered to the DOM. Use for fetching data, setting up subscriptions, or interacting with the DOM.
• Explain `onDestroy`: runs just before the component is removed from the DOM. Use for cleaning up resources, unsubscribing from stores, or clearing timers.
• Mention `beforeUpdate` and `afterUpdate`: run before and after the component's DOM has been updated. Less commonly used but useful for specific DOM manipulations or measurements.
• Explain `tick()`: a utility function that returns a promise that resolves after any pending state changes have been applied to the DOM. Useful when you need to wait for DOM updates.

Where people lose the point

• ×Confusing Svelte's lifecycle hooks with those of other frameworks (e.g., `useEffect`, `componentDidMount`).
• ×Forgetting to import lifecycle functions from `svelte`.
• ×Not understanding the asynchronous nature of `tick()`.

What a strong answer covers

• Define Svelte stores as objects with a `subscribe` method, used for managing shared, reactive state across components.
• Explain `writable` stores: allow both reading and writing of values. Created with `writable(initialValue)`, updated with `set()` or `update()`.
• Explain `readable` stores: allow reading but not direct writing. Useful for values that change externally or are initialized once.
• Explain `derived` stores: create a new store whose value is computed from one or more other stores. Automatically updates when dependencies change, useful for reactive computations.

Where people lose the point

• ×Confusing stores with local component state.
• ×Not knowing how to update a `writable` store.
• ×Failing to explain the automatic reactivity of `derived` stores.

What a strong answer covers

• Explain that Svelte uses the `bind:` directive for two-way data binding, primarily with form elements (e.g., `bind:value`, `bind:checked`).
• Demonstrate with an `<input>` element: `bind:value={variableName}`. When the input changes, `variableName` updates, and vice-versa.
• Explain that Svelte compiles this into efficient event listeners and prop updates, abstracting away the manual `value={variable}` and `on:input={e => variable = e.target.value}` pattern.
• Mention that `bind:` can also be used for component props, allowing a child component to update a parent's state (though often less preferred than explicit events).

Where people lose the point

• ×Believing Svelte's two-way binding is fundamentally different from event listeners and prop updates; it's a syntactic sugar.
• ×Trying to use `bind:` on elements that don't support it or for non-form-related data.
• ×Not understanding the underlying mechanism of `bind:`.

What a strong answer covers

• Define the Context API as a mechanism to share data across deeply nested components without prop-drilling.
• Explain `setContext(key, value)`: used in a parent component to provide a value associated with a unique key.
• Explain `getContext(key)`: used in any descendant component to retrieve the value associated with that key.
• Discuss use cases: global configurations, theme settings, user authentication status, or any data that many components need but doesn't change frequently or require complex reactivity (for which stores are better).

Where people lose the point

• ×Confusing Context API with Svelte stores; stores are for reactive, application-wide state, Context is for static or less frequently changing data.
• ×Using Context API for every piece of shared state, leading to less explicit dependencies.
• ×Forgetting to import `setContext` and `getContext` from `svelte`.

What a strong answer covers

• Advantages: Smaller bundle sizes (no runtime framework), faster performance (direct DOM manipulation, no virtual DOM), simpler reactivity model (plain JS assignments), better developer experience (less boilerplate, 'just works').
• Disadvantages: Steeper learning curve for debugging compiler output (though rarely needed), less mature ecosystem compared to React/Vue (fewer libraries/tools), potential for slower build times on very large projects (though often offset by runtime gains).
• Mention that Svelte's approach means less work for the browser, leading to better user experience, especially on lower-powered devices.
• Acknowledge that the 'disadvantages' are often minor or improving as Svelte matures.

Where people lose the point

• ×Overstating the disadvantages or presenting them as critical flaws.
• ×Not understanding that the compiler is the core differentiator and source of both pros and cons.
• ×Failing to connect the compiler to specific benefits like bundle size or performance.

What a strong answer covers

• Define Svelte actions as functions that are called when an element is created and can return an object with `update` and `destroy` methods.
• Explain their purpose: to extend the functionality of HTML elements, encapsulate reusable DOM logic, or integrate with third-party libraries.
• Demonstrate usage: `use:actionName` on an HTML element, optionally passing parameters `use:actionName={parameters}`.
• Provide examples: creating a tooltip, handling drag-and-drop, integrating a custom scrollbar, or managing focus.

Where people lose the point

• ×Confusing actions with event handlers; actions are for extending element behavior, not just reacting to events.
• ×Not understanding the `update` and `destroy` methods for managing the action's lifecycle.
• ×Trying to use actions for general component logic instead of DOM-specific enhancements.

What a strong answer covers

• Explain that Svelte provides built-in transitions (e.g., `fade`, `slide`, `blur`, `fly`, `scale`, `draw`) and allows custom transitions.
• Describe how transitions are applied using `transition:name` or `in:name` / `out:name` directives on elements that are added or removed from the DOM.
• Provide an example of `transition:fade` or `transition:slide` on an `{#if}` block to show an element appearing/disappearing smoothly.
• Mention that Svelte handles the CSS and JavaScript necessary for these animations, making them easy to implement and performant.

Where people lose the point

• ×Confusing Svelte transitions with CSS transitions or animations that you'd write manually.
• ×Trying to apply transitions to elements that are always present in the DOM, rather than those entering/exiting.
• ×Not understanding the difference between `transition:` (bidirectional) and `in:`/`out:` (unidirectional).

What a strong answer covers

• Utilize browser developer tools: `console.log()` for inspecting variable values, the Elements tab for DOM inspection, and the Network tab for API calls.
• Leverage Svelte's reactivity: ensure variables are correctly reassigned to trigger updates; be aware of common reactivity pitfalls (e.g., modifying array elements directly without reassigning the array).
• Use the Svelte DevTools browser extension: provides a component tree, state inspection, and store values, similar to React/Vue DevTools.
• Isolate issues: create minimal reproducible examples, comment out sections of code, or use temporary components to narrow down the problem area.

Where people lose the point

• ×Over-relying on `console.log` without using the Svelte DevTools for state inspection.
• ×Forgetting Svelte's reactivity rules, leading to 'why isn't this updating?' scenarios.
• ×Not understanding how to inspect compiled Svelte code in the browser (though usually not necessary).

What a strong answer covers

• Explain improved SEO: Search engine crawlers can easily index fully rendered HTML content, leading to better search rankings.
• Describe faster initial page load: Users see content sooner as the server sends a complete HTML page, reducing perceived load time.
• Discuss better performance on low-powered devices: The server handles the initial rendering, offloading work from the client's browser.
• Mention enhanced user experience: Content is immediately visible and interactive (after hydration), providing a smoother start.

Where people lose the point

• ×Confusing SSR with client-side rendering (CSR) or static site generation (SSG).
• ×Not understanding the 'hydration' process where client-side JavaScript takes over after SSR.
• ×Failing to connect SSR benefits directly to user experience and technical advantages.

What a strong answer covers

• Define reactive declarations (`$:`) as a way to declare values that are re-computed whenever their dependencies change.
• Explain that they are essentially labels for JavaScript statements, which Svelte's compiler treats specially to ensure reactivity.
• Provide a use case: deriving a `fullName` from `firstName` and `lastName`, or performing a side effect like `$: console.log(count)` when `count` changes.
• Emphasize that `$: ` can be used for both computed values and side effects, making them a powerful tool for managing reactive logic.

Where people lose the point

• ×Confusing `$: ` with a standard JavaScript label or a simple variable declaration.
• ×Not understanding that the entire statement after `$: ` is re-run when any of its dependencies change.
• ×Trying to use `$: ` for non-reactive computations or for logic that should be in an event handler.

What a strong answer covers

• Define slots as a mechanism for passing HTML content (not just data) from a parent component into a child component.
• Explain that a child component defines a slot using `<slot />` in its template, acting as a placeholder for content.
• Demonstrate how a parent component passes content by placing it between the child component's opening and closing tags (e.g., `<Card><p>Card Content</p></Card>`).
• Discuss named slots (`<slot name="header" />`) for passing multiple distinct blocks of content, and slot props (`<slot let:item={item} />`) for passing data back to the slot content.

Where people lose the point

• ×Confusing slots with props; slots pass markup, props pass data.
• ×Not understanding the difference between default slots, named slots, and slot props.
• ×Trying to use slots for simple data passing instead of content projection.