Cron Scheduler Take-Home

What they ask

The backend take-home has been the same brief since 2021, and the company keeps it in a public repository on its GitHub organisation. After the intro call an engineer sends you the link and a deadline, and the task comes back in the onsite loop as a dedicated discussion round.

Build an in-process cron scheduler that accepts a job and runs it periodically. A client registers a job with:

• an expected duration for a single run, for example 30m,
• a frequency, for example 1hr for a job that should run every hour,
• the job itself, a function,
• a unique job identifier.

The solution must run several jobs concurrently, ship with tests, and instrument every run (actual execution time, logging). It has to be written in Go, Java, Python, C++, Ruby or JavaScript, and it must not lean on a scheduling library. The brief names Java's ScheduledExecutorService.scheduleAtFixedRate as the kind of shortcut that is not allowed.

The README is graded as hard as the code. They ask for a short description, the reasoning behind your technical decisions, the trade-offs you made, usage snippets, and what you would improve next.

What candidates built

Published solutions cluster around three shapes: a priority queue keyed by next run time with worker threads, a plain loop per job with sleeps, and an actor-style design with a timer actor, a scheduler actor and one monitor per job. Deleting a job is a common pain point, and a tombstone set checked when the job reaches the head of the queue is the usual answer.

What they look for

• A clear policy for the run that overruns its frequency: skip, queue, or run in parallel, and why.
• What the expected duration is for. The good answer is a timeout and a metric, not a sleep.
• Fixed rate versus fixed delay, and how you keep drift out of the schedule.
• Thread safety when jobs are added or removed while the scheduler is running, and a graceful shutdown that lets in-flight runs finish.
• Tests that do not sleep for real minutes: an injectable clock or a tiny tick granularity.
• A README that reads like an engineer explaining a design to a colleague.