Prep · Design

Practical Questions

Most modern screens don’t ask you to invert a binary tree. They hand you an underspecified prompt — “build a package manager, think npm but not nearly as good” — and then keep adding requirements. The ambiguity is the graded material: you choose the API, you choose the data model, and the choice you make in phase one decides whether phase three is a five-line method or a rewrite.

This lane trains that format directly: registries, caches, documents, limiters, queues, emitters, debounced async search, usage rollups, the app discovery service that pulls all of it into one screen, and the tiny test runner you write before everything else. Work each phase before reading its solution — reading ahead destroys the only thing this set trains.

Design a Package Registry

An underspecified prompt, an API you have to define yourself, and a data-model choice in phase one that decides whether phase three is five lines or a rewrite.

Data modeling → graph

Design a Tag Registry

Messy free-text input, a canonical taxonomy underneath, and a merge escalation that quietly turns into union-find.

Canonicalization → union-find

Design Prefix Autocomplete

Start naive on purpose, then survive the escalations: a trie when scanning dies, a ranking twist that punishes collect-then-sort, and deletion that must not leak.

Naive scan → trie → ranked suggestions

Rank a Search Result Set

One function, one sort key, and the decision that separates a search box from a filter: always return n, and let the ranking do the talking.

score everything → ordinal tiers → popularity as tiebreak

Design an Async Request Cache

Deduplicate in-flight requests with a map of promises — then survive failure semantics, TTLs, and an LRU escalation you've already repped.

Promise dedup → state machine → LRU

Design a Text Document Editor

Class state seeded by a constructor, edits applied through a public method, then undo/redo by storing inverse operations on stacks.

Class state -> inverse operations -> stacks

Design a Rate Limiter

A per-user quota guard using a map of keys to recent request timestamps, with retryAfter and reset as operational escape hatches.

Map key -> sliding window timestamps

Design a Job Queue

A small in-memory queue with generated IDs, claim/complete status transitions, retry budget, and priority with FIFO tie-breaking.

FIFO queue -> status map -> retries

Design an Event Emitter

The small event bus drill: subscribe handlers, emit in order, unsubscribe by function identity, then add once with a snapshot-safe loop.

Map event -> ordered handlers

Design Debounced Search

A timer-backed async wrapper that collapses rapid inputs into one search, resolves pending promises, caches exact terms, and guards stale results.

Timer -> pending promises -> stale guard

Design a Usage Portal

The screen that starts with a repo already written: an event schema, a seeded fixture, and a plan catalog. You add metering, billing windows, a leaderboard, and overage in whole cents.

Event log -> account/metric index

Design an App Discovery Service

The final boss. A gallery full of half-filled publish forms, a controlled tag vocabulary, a type-ahead, a ranking rollout, and an event log that decides which apps win. Every earlier practical shows up in it.

Tag index + event log -> conversion ranking

Debug: The Dropped Page

A cursor pagination walk that checks nextCursor before it drains the page, so the last page is fetched and thrown away. Then replay safety and resumable checkpoints on top of the fix.

Cursor loop -> drain, then decide

Design an Agent Tool Router

The dispatch layer under an agent: a name-to-handler map, per-action human approval that cannot be replayed, and an append-only audit trail.

Name -> handler map + pending approvals + append-only audit

Design an Idempotent Event Processor

At-least-once delivery means the same webhook arrives twice. A map from event id to stored result, a record that only lands on the success path, and a ttl so the map does not grow forever.

Map event id -> stored result

Debug: The Vanishing Cent

A bug squash in the Stripe shape: the starter is finished, plausible code that rounds each payee alone, so the parts stop adding up to the whole. Diagnose it, then make the fix fair and then hostile-input proof.

floor everyone, then hand out the remainder by largest fraction

Design an Eval Harness

Score a suite of cases against a candidate function, keep unknown separate from failure, then diff two runs into a gate that can block a deploy.

Case list -> tri-state verdicts -> diff

Write the Test Runner

The class is already done. Retype assertEqual, test, and main until the recipe is motor memory — then two silly assertions against a given document.

Throw on mismatch → log PASS / FAIL

The Four Asserts

Second lap of the test recipe, against a given undo/redo editor. Same four helpers, same two-test main, different prop.

Four helpers · same throw shape

Playground

Open TypeScript on the bench. The helpers are already there. Run stays in the browser — test() and console.log land in the panel. The judge never sees it.

Before You Type

Write the assert helper first

Three lines before any design. Every requirement sentence becomes a real assertion instead of a console.log you read with your eyes — and test through the public API, never by mutating internals.

Read the prompt like a spec

Every qualifier is deliberate. “Immediate dependencies” means transitive is coming. “First task” means there are more. “No duplicates” is a hint to pick a set-shaped container instead of writing dedup code.

Have an opinion, say why

Most escalations have two defensible answers. Naming the trade-off out loud — what it costs, when you’d choose the other one — is the difference between a correct answer and a senior one.