The Deceptively Simple Interview: Designing a Color Picker Service

Imagine reaching the final round at a top tech company, braced for "design WhatsApp" — and the principal engineer across the table asks you to design… a color picker. A service that saves one color, for one user, and shows it back tomorrow. Welcome to one of the sharpest instruments in the Staff/Principal interview toolkit: the deceptively simple system, where there is no fog of complexity to hide in, and the only thing being measured is your judgment.

The Trap Built Into Small Systems

Most system design preparation trains you to summon machinery: sharded databases, cache hierarchies, event backbones, multi-region replication. The deceptively simple prompt inverts the test. Hand a prepared candidate a trivial system and one of two failures usually follows:

• The Dismissal: The candidate treats the problem as beneath them, skips the discipline — clarification, estimation, measurable requirements — and delivers a shallow sketch. Signal: process collapses when stakes look low.
• The Citadel: The candidate panics at the emptiness and erects the full planetary-scale apparatus — Kafka, Redis clusters, microservices — around a service measured at 120 requests per second and 60 megabytes of data, ever. Signal: judgment can be baited.

The passing performance is rarer than either: a system right-sized with precision — five components, every absence defended with a number, every escape hatch named in advance. That performance is what this module teaches, end to end.