25 Svelte interview questions

Listen for: A strong answer separates ownership from computation. They should keep mutable UI state local when the component owns it, derive values instead of syncing duplicate state, and pass stable data or callbacks through props when parents coordinate behavior. They should mention avoiding hidden two-way coupling and testing behavior through user interactions.

Red flag: They treat every value as writable state and rely on manual synchronization between variables.

Listen for: Listen for a step-by-step approach: inspect the route's load function, check whether data is coming from page data, a store, or client fetch, and confirm invalidation behavior. They should mention depends, invalidate, cache headers, and browser devtools before changing architecture. Good candidates distinguish server load from universal load effects.

Red flag: They immediately suggest forcing a full page reload without finding the stale data source.

Listen for: They should describe using SvelteKit form actions with progressive enhancement, returning structured validation errors, preserving submitted values, and enhancing the form only for nicer pending states or optimistic UI. Strong signals include thinking about disabled states, focus management, server-side validation, and not trusting client-side checks alone.

Red flag: They only describe an on:submit handler that calls fetch and bypasses server validation.

Listen for: A good answer covers semantic HTML first, then ARIA only when needed. They should check focus order, Escape/Enter/Arrow key behavior, labeling, click-outside behavior, and screen reader announcements. They should be comfortable using browser accessibility tools and testing with keyboard-only navigation instead of relying on visual inspection.

Red flag: They say accessibility can be added later with a few aria attributes.

Listen for: They should favor behavior tests with Testing Library or Playwright component testing over internal implementation assertions. Listen for cases around empty input, case handling, sort direction, no results, and URL/state persistence if relevant. Strong answers mention keeping pure filtering logic separately testable when it becomes complex.

Red flag: They only test that internal variables changed after calling component methods.

Listen for: They should recognize server-side rendering is executing module imports or code that assumes window/document. Good answers include dynamic import in onMount, guarding browser-only code with browser from $app/environment, disabling SSR only as a last resort for that route, and considering bundle size and loading states.

Red flag: They disable SSR for the whole application without understanding why the build fails.

Listen for: A strong answer assigns state by lifetime and ownership: server-loaded user data, durable cart persistence if needed, and route-scoped checkout state. They should avoid a single global store for everything, discuss invalidation after mutations, and know when context, runes-based modules, URL state, or server sessions are appropriate.

Red flag: They propose one app-wide writable store for all state, including server-owned data.

Listen for: Listen for measuring before changing: inspect waterfalls, server timing, duplicated fetches, and layout invalidation. Strong candidates discuss parallel loading, moving data to the lowest route that needs it, using parent data deliberately, cache headers, streaming where suitable, and avoiding client-side refetches that duplicate server work.

Red flag: They suggest converting everything to client-side fetching as the default fix.

Listen for: They should mention cookies or session tokens handled on the server, hooks.server for request context, locals for user/session data, and route-level authorization in load or server endpoints/actions. Good answers separate authentication from authorization, handle redirects safely, avoid leaking protected data during SSR, and plan token/session refresh behavior.

Red flag: They store long-lived credentials in localStorage and check access only in client components.

Listen for: A strong answer ties rendering choice to data freshness, personalization, SEO, interactivity, hosting constraints, and failure modes. They should know SvelteKit supports per-route settings and adapters, and they should resist one-size-fits-all answers. Listen for examples like marketing pages, account dashboards, admin tools, and content pages.

Red flag: They say SvelteKit apps should always use the same rendering mode everywhere.

Listen for: Good answers are incremental: understand current behavior, migrate leaf components first, keep tests or visual regression coverage, and avoid mixing patterns carelessly. They should know stores still exist and are useful for streams or external subscriptions. Listen for attention to event syntax, props, snippets, effects, and lifecycle differences.

Red flag: They recommend rewriting the entire app before shipping any feature work.

Listen for: They should question whether effects are being used for derivation, state synchronization, or data fetching that belongs in load/actions. Strong candidates reduce effects, use $derived for computed values, isolate external side effects, add guards or cleanup, and make dependencies explicit. They should mention reproducing the loop with logging or tests.

Red flag: They add boolean flags until the loop stops without addressing the data flow.

Listen for: Listen for layered handling: validation errors returned to the form, expected domain failures shown inline, unexpected failures logged and routed to error boundaries, and API errors normalized at the server edge. Strong answers preserve user input, avoid exposing sensitive backend details, and define retry or recovery behavior where useful.

Red flag: They catch every error and display a generic toast while swallowing the details.

Listen for: A senior answer probes ownership, invalidation, security, serialization, and duplication with server-loaded data. They should distinguish stable client preferences from server authority, suggest route data or context where appropriate, and ask how mutations invalidate cached state. Strong candidates also consider testability, memory leaks, and debugging complexity.

Red flag: They accept global client state as an automatic solution because it is convenient.

Listen for: Look for a balanced design using layout data for shared shell information, widget-level data boundaries, parallel fetches, caching, preloading, skeletons, and selective invalidation after mutations. They should consider SSR versus client updates, streaming where it improves perceived performance, backend aggregation, and instrumentation to verify the user experience.

Red flag: They promise instant navigation by preloading all dashboard data for every user on login.

Listen for: They should define conventions that reduce ambiguity: route/data ownership, component boundaries, runes usage, form patterns, accessibility requirements, testing layers, linting/formatting, and code review expectations. Strong answers avoid bureaucracy, explain how standards evolve, and include examples, templates, and automated checks in CI.

Red flag: They rely on personal review preferences instead of shared, documented conventions.

Listen for: A strong answer narrows differences between server and client output: nondeterministic values, time zones, locale formatting, browser-only data, feature flags, random IDs, and environment-specific branches. They should reproduce with production build, inspect rendered HTML, add targeted logging, and prefer deterministic rendering or client-only boundaries when justified.

Red flag: They suppress the warning or disable SSR without isolating the mismatch.

Listen for: Listen for criteria beyond appearance: accessibility quality, design system fit, bundle impact, SSR compatibility, theming, maintenance, escape hatches, and team skill. A senior candidate may propose headless primitives for complex controls, custom components for product-specific patterns, and a proof of concept before broad adoption.

Red flag: They choose a library solely because it has the most components.

Listen for: They should separate build-time and runtime configuration, avoid leaking server-only secrets, and design feature flags so authorization is enforced server-side. Strong answers mention environment modules, adapter constraints, theming boundaries, route gating, test matrices, and observability that identifies configuration-related failures.

Red flag: They suggest shipping all features to the client and hiding unavailable ones with CSS or client checks.

Listen for: They should combine profiling, budgets, ownership, and prevention. Listen for using build analysis, Web Vitals-style field monitoring, route-level measurements, Playwright performance smoke tests where practical, and review guidelines for data loading and bundle additions. Good answers prioritize user journeys and create feedback loops in CI and production.

Red flag: They treat performance as occasional minification and image compression work only.

Listen for: Strong answers separate public prerendered or cached content from authenticated author routes, use server-side preview authorization, and avoid exposing draft data in client bundles. They should discuss load functions, actions for editing, cache invalidation after publishing, adapter constraints, and how preview mode interacts with cookies or signed URLs.

Red flag: They make all content client-fetched from a public endpoint and rely on hidden routes for drafts.

Listen for: Listen for an architecture that separates initial SSR or server-loaded state from live updates via WebSocket, SSE, or polling based on infrastructure needs. They should handle reconnection, backpressure, optimistic acknowledgments, permissions, stale indicators, cleanup on route changes, and testing of message ordering and failure cases.

Red flag: They open unmanaged WebSocket connections inside several components with no cleanup or shared ownership.

Listen for: A good answer puts organization and user context in server request handling, enforces authorization on server routes/actions, and uses layout data to drive navigation without trusting it for security. They should discuss safe redirects, CSRF considerations, audit event creation, invalidation after role changes, and UI behavior when access changes mid-session.

Red flag: They rely on client-side role checks to protect admin routes and actions.

Listen for: Strong answers model checkout as server-owned workflow state, with route-scoped steps, form actions, validation, idempotent mutations, and recovery after redirects. They should think about preserving input, handling browser back/refresh, separating payment provider state from UI state, and avoiding sensitive data in client stores or URLs.

Red flag: They keep the entire checkout state in a client store and submit it once at the end.

Listen for: Look for incremental routing strategy, shared component extraction, adapter/deployment planning, and compatibility around authentication and API calls. They should propose migrating low-risk routes first, adding tests around critical journeys, preserving URLs, measuring performance changes, and teaching the team SvelteKit data-loading and server/client boundaries.

Red flag: They propose a big-bang rewrite with no intermediate releases or rollback path.