Q419: Implementation Drill Saved Snippets First Slice

What Interviewers Want To Evaluate

This drill tests whether you can add persistence without turning a simple practice tool into a fragile product.

Saved snippets are valuable because learners often want to return to a small experiment.

They also add storage, deletion, loading, conflict, and migration problems.

The first slice should be intentionally small.

Short Interview Answer

I would start saved snippets with local storage, a versioned schema, language-specific snippets, an empty state, save current code, load snippet, and delete snippet.

I would avoid accounts, cloud sync, sharing, tags, and search in the first version.

The first slice should protect the learner from losing work while keeping the storage model easy to recover from.

First Slice Scope

Include:

save current code
snippet name
language
created date
updated date
load snippet
delete snippet
empty state
storage recovery

Skip:

cloud sync
folders
tags
sharing
collaboration
execution history

Small persistence is still persistence.

Treat it carefully.

Storage Schema

Use a versioned shape:

type SavedSnippet = {
  id: string;
  language: "javascript" | "typescript";
  title: string;
  code: string;
  createdAt: string;
  updatedAt: string;
};

type SavedSnippetStore = {
  version: 1;
  snippets: SavedSnippet[];
};

The version matters because local storage can outlive code changes.

Future migrations become possible instead of chaotic.

Empty State

An empty saved-snippets panel should be useful.

Say what the user can do:

No saved snippets yet.
Save the current editor when you want to revisit an example.

Do not show a blank list.

Do not make users guess whether the feature is broken.

Load Conflict

Loading a snippet can overwrite current editor content.

Handle it deliberately.

Options:

load immediately if editor is unchanged
ask confirmation if editor has unsaved edits
provide save current first
allow cancel

The first version can use a simple confirmation.

The important thing is not to destroy current work silently.

Delete Behavior

Delete needs confirmation if the action is irreversible.

Keep the confirmation lightweight.

The user should know:

which snippet is being deleted
whether deletion can be undone
what remains after deletion

For the first local-only version, deletion can be permanent.

Say it plainly.

Defensive Parsing

Local storage can contain invalid data.

Reasons:

old app versions
manual edits
browser extension interference
partial writes
corrupted JSON

The app should recover.

If parsing fails, show an empty state or a recovery message.

Do not crash the practice page.

UI Placement

Saved snippets should not crowd the editor.

Useful layout:

editor and console remain primary
snippets live in a side panel or collapsible section
save action stays near editor
load and delete stay with snippet list items

The write-run-inspect loop remains the main experience.

Snippets support it.

They should not dominate it.

Testing Plan

Verify:

save JavaScript snippet
save TypeScript snippet
load snippet into matching practice page
delete snippet
empty state appears
invalid storage recovers
unsaved editor conflict is handled
theme contrast remains readable

This is enough for a first slice.

Common Mistakes

• Adding cloud sync too early.
• Saving without schema versioning.
• Overwriting current editor content silently.
• Letting invalid local storage crash the page.
• Mixing JavaScript and TypeScript snippets without labels.
• Making snippets visually louder than the editor.

Final Mental Model

Saved snippets should start as:

local
versioned
recoverable
language-aware
conflict-safe
small

Persistence should increase learner confidence, not create new ways to lose work.