Timer Design: Choosing the Use Case, the MVP and How Timers Fire on Time

Design a timer system. Decide what kind of timer it is and who relies on it, what it must do first, and sketch at a high level how it would work. ```hint Start from the failures Before choosing features, list the ways a timer can let down whoever depends on it (firing late, firing twice, going unnoticed) and decide which of those failures your design must prevent first. ``` ### Clarifying Questions - Is this a consumer timer (on phones, watches, speakers or a dedicated device), or a timing service that other software calls to schedule something at a future moment? - Should a timer work across several of a person's devices, or on one device only? - What is the goal: frequent everyday use, trust in reliability, or support for another product? - How precise does a timer need to be, and must it still fire when a device is asleep, offline or restarted? ### What a Strong Answer Covers - A stated reading of "timer system" and a chosen first user or use case, each weighed against alternatives - Use cases and pain points specific to that choice, tied to the moments a timer is actually used - A prioritized feature set, with an MVP and what is deferred - A high-level technical sketch of how timers keep accurate time and fire through sleep, restarts and lost connectivity - Success metrics with guardrails, and the main risks ### Follow-up Questions - A timer could ring on three devices in the same home. How would you decide where it rings, and what should happen if nobody responds? - If the interviewer meant a backend service that other teams use to schedule events, what would change in your requirements and design? - Which metric would reveal late or missed timers before users start complaining, and how would you collect it?