Section 1: Cron, Multiplied by Three Thousand Teams - Problem Understanding & Clarifications

Executive Summary: This section covers the opening minutes, where a familiar-sounding prompt has to become a scope you can defend. We break the prompt into what, who, why and how, show why "cron on one box" fails in exactly the ways the prompt forbids, and ask the questions that settle the big forks: who runs the code, how precise "on time" must be, what "every run has to happen" honestly means, and whose clock the schedule follows. You leave with written assumptions, a running example for the next eleven sections, and a sense of what the interviewer is scoring.

The interviewer reads you one sentence:

"Design a distributed job scheduler for our company. Thousands of internal teams need to run jobs at a specific future time or on a recurring cron schedule, and every scheduled run has to actually happen, on time, even when machines fail."

Your first thought is probably cron, but on more machines. It's a useful starting point and a dangerous place to stop. Cron solves this perfectly for one machine. What the prompt adds is its last clause, every run, on time, even when machines fail, which makes three things hard. Time gets hard because tenants think in local clocks that skip and repeat hours. Coordination gets hard because exactly one machine should fire each timer, even while machines are dying. And delivery gets hard because "every run happens" sounds like a promise of exactly once, which nobody can actually keep.

Why One Box Is Not Enough

It helps to say out loud why the obvious design fails, because each failure turns into a requirement:

The single box loses runs silently. The obvious fix, a second box, creates duplicates. Cron itself has no memory of what it missed. And the box's clock setting quietly decides what "2 AM" means. Every branch is a problem you'll solve later; naming them now shows you understand the problem before solving it.

Quick check before moving on: