Svelte 5 Interview Questions: Runes, Derived State, and Effect Pitfalls

Svelte 5 interview answers need minor-version boundaries. Current documentation says $derived values could not be overridden before 5.25 but may be temporarily overridden later unless declared const. $effect tracks synchronous reads, runs only in the browser, and schedules reruns after state changes; React dependency-array rules do not transfer.

The preparation method in this guide is deliberately practical: build a small model, change one condition at a time, predict the result, and compare the prediction with a recorded check. The prediction snippets are documentation models, not output captured from a bundled Svelte compiler.

Start with Design State for a Three-Column Work Board after the worked scenario.

What Is Verified and What Is Preparation

Official fact: Svelte documents $derived dependency tracking and the post-5.25 override behavior.

Official fact: Svelte documents $effect synchronous dependency discovery, teardown, microtask scheduling, and browser-only execution.

Candidate-report boundary: No candidate account is needed to establish the technical behavior in this guide. Any process description should come from the reader’s invitation.

Editorial inference: Output prediction is stronger than definition recall because it forces the candidate to name version, dependency, scheduling, and cleanup. That is why the rest of this article emphasizes a reusable reasoning method instead of a supposedly fixed question list.

Before practicing, write down the runtime, product or service version, input contract, and allowed tools. Version details are part of the answer, not administrative trivia. If the invitation is company-specific, ask the recruiter only for format details that affect preparation: language, editor, expected deliverable, time box, and tool rules. Do not ask for the prompt.

Reason About Runes Through Output

Derived dependency

Synchronous reads inside the expression become dependencies. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Changing a read source invalidates the value.

Override version

Before 5.25 derived overrides are not allowed; later mutable derived bindings can be overridden. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Version is stated first.

Effect tracking

Only synchronous reads during effect execution are tracked. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: A read after await is not silently assumed.

Cleanup

A returned function runs before rerun and on teardown. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Subscriptions do not accumulate.

SSR boundary

Effects do not run during server rendering. In an interview, make the governing condition explicit before you predict the result. Then name the observation that would disprove your answer. Check: Required server data is not produced by an effect.

The five ideas belong in one explanation. Begin with the request or event, identify the controlling state, follow the transition, and finish at the observable output. Avoid reciting definitions separately. A good interviewer can then change one assumption and see whether your model still holds.

Predict an Optimistic Like Counter

Use the following original scenario to make each state transition and failure visible before proposing a fix.

let likes = $state(10)
let doubled = $derived(likes * 2)
// optimistic override, rollback, and effect cleanup vary by version

Use this trace rather than jumping straight to a fix:

1. Version — Fix Svelte 5.24 or 5.25+.
2. Initial render — Compute state and derived output.
3. Optimistic change — Predict override and later dependency recomputation.
4. Failure rollback — Restore source or overridden value by contract.
5. Cleanup — Record effect setup and teardown order.

The local companion check records these predictions. It passed 5 of 5 assertions. Test boundary: A local prediction table checked five documented rune rules; no Svelte compiler or browser runtime was installed. No credentialed vendor environment was used, so the result verifies the model and arithmetic only. It does not prove hosted behavior, quotas, latency, or account-specific configuration.

Change One Condition at a Time

The fastest way to expose shallow understanding is to change several variables at once. Instead, use paired cases. Keep the request and surrounding state fixed, then alter only the version, identifier, policy, timeout, watermark, or failure point. Say what changed in the governing rule before giving the new output.

Changed condition	Prediction	Evidence to inspect	Best response
Use Svelte 5.24	Override fails	Version docs	Update source instead
Use 5.25+ mutable binding	Temporary override allowed	Binding declaration	Plan rollback
Read after await	Not tracked by initial synchronous run	Effect trace	Read synchronously or restructure
Dependency changes	Derived recalculates	Output sequence	Expect override to be replaced
Server render	Effect does not run	SSR output	Move required work outside effect

For every row, separate an observed fact from an assumption. Logs, documented fields, an execution history, and a reproducible test are evidence. A plausible architecture guess is still a guess. If a required field is missing, ask for that field and explain how each possible value would alter the diagnosis.

Common Interview Traps

• Calling derived always read-only: That is version-dependent. A stronger answer states what would happen, why, and how to verify it.
• Copying React rules: Svelte tracks reads rather than a dependency array. A stronger answer states what would happen, why, and how to verify it.
• Using effects for derived state: It obscures data flow. A stronger answer states what would happen, why, and how to verify it.
• Ignoring teardown: Listeners and requests can overlap. A stronger answer states what would happen, why, and how to verify it.
• Claiming compiler output without running it: Separate documentation prediction from execution. A stronger answer states what would happen, why, and how to verify it.

Another trap is proposing a large redesign before proving the failure. Prefer the smallest safe correction that restores the contract, then describe a follow-up improvement if the design still creates operational risk. This shows scope control and leaves room for the interviewer to add a requirement.

Explain the Result as an Engineering Decision

Use a four-part answer: decision, rule, evidence, consequence. For example: “I predict this path will fail. The controlling rule is X. The event history shows Y. Therefore I would change Z and add this regression check.” The exact nouns vary by topic; the structure stays useful.

When there is a trade-off, name both sides concretely. An effect can integrate imperative APIs but creates lifecycle work; derived state stays declarative but cannot replace every side effect. Choose a default for the stated workload, and say what measurement or requirement would make you choose differently. “It depends” becomes useful only after you name the dependency.

For troubleshooting questions, end with a safe next action. Preserve evidence before changing state. Prefer a reversible mitigation, define the success signal, and state what would trigger rollback or escalation. For implementation questions, end with a boundary test and an invariant. For design questions, end with capacity and failure assumptions.

Practice Questions and Follow-Ups

Work through these prompts aloud:

1. Explain the normal path without using framework vocabulary. What enters, what state changes, and what leaves?
2. Which single field or timestamp would you inspect first after the reported failure, and why?
3. What happens if the same operation is retried after the external side effect succeeds?
4. Which answer changes across the versions or modes named in the title?
5. What is the smallest regression test that prevents this failure from returning?
6. How would you explain the same incident to an engineer and to a non-specialist stakeholder?

A complete answer should survive one follow-up. After your first response, add a constraint such as a lower resource limit, a late event, a cross-account boundary, a process crash, or a changing requirement. Update only the affected part of your model and keep prior invariants visible.

Verified question	Focus	Practice output
Design State for a Three-Column Work Board	State modeling	Write a prediction, evidence path, and decision
Build an Event-Driven Folder Browser	Event lifecycle	Write a prediction, evidence path, and decision
Build a Real-Time Event Feed Dashboard	Reactive updates	Write a prediction, evidence path, and decision
Implement list, form, and API rendering with pitfalls	UI edge cases	Write a prediction, evidence path, and decision
Compare frontend data management beyond Redux	State trade-offs	Write a prediction, evidence path, and decision

A Focused Preparation Routine

On the first pass, spend 25 minutes reconstructing the governing rules from official documentation and write three paired predictions. On the second, spend 35 minutes on the original scenario, including one failure and one recovery. On the third, explain the result aloud in ten minutes, then answer two changing-requirement follow-ups.

Review the recording or notes for four signals: did you state the version; did you distinguish fact from inference; did you prove the failure with the smallest useful trace; and did your recommended change preserve the original contract? Count evidence-backed decisions, not the number of terms you mentioned.

Finish by preparing two questions for the interviewer about the real team’s constraints. Ask about workload shape, failure ownership, testing environments, or observability. Those questions connect the exercise to engineering work without pretending that public documentation reveals a private interview rubric.

Build an Evidence Worksheet

For one final rehearsal, divide a page into six columns: claim, source or input, governing rule, predicted output, observed output, and next decision. Put only one claim in each row. This prevents a correct fact from being attached to the wrong version, mode, principal, message, or failure point. It also makes an unanswered question visible instead of letting an assumption disappear inside a long explanation.

Start with the normal path and then copy the row four times. In each copy, change exactly one condition from the worked scenario. Predict the new result before checking documentation or running the local model. If your prediction is wrong, record the rule you missed rather than merely replacing the answer. That error log becomes a more useful study guide than a list of definitions because it captures where your mental model fails.

During a mock interview, give the worksheet to the interviewer or practice partner only after you finish. Ask them to challenge the weakest evidence row. Respond by saying which part is confirmed, which part is inferred, and what observation would settle the uncertainty. If you need to revise the answer, preserve the original constraint and change only the affected decision. This demonstrates that new information improves your reasoning instead of resetting it.

The worksheet also creates a clean stopping rule. Once the blocking failure is proved, the smallest safe correction is named, and a regression check covers it, summarize. Extra terminology does not strengthen the answer. Save broader redesign ideas for a follow-up and connect each one to a measurable requirement.

State the Svelte version before every derived override answer and use a timeline for effect setup, dependency change, cleanup, and SSR.

Sources and Further Reading

• Svelte $derived — official current derived behavior
• Svelte $effect — official current effect behavior
• Hyring Svelte questions — competitor reference checked against official docs