HomeChallengesRepsProblemsLeaderboardTake a challenge

The Job Scheduler

Jobs declare what they need. Work out what runs, in what order, what can run in parallel — and which jobs can never run at all.

Advanced25 min on the clock5 graded checks · 100 pointsData Structures at Work
Graded by running your code against real cases.

What you build

  • topoSort(jobs) — a valid order, alphabetical among everything ready
  • waves(jobs) — the jobs grouped into parallel rounds
  • findCycle(jobs) — the ids that can never run, sorted, or null
  • A dependency on a job that does not exist can never be satisfied
  • One case orders 8,000 jobs on a time budget

Done means

Nothing runs before what it needs, parallel work is grouped, and a cycle is named rather than hung on.

How it is graded

Published in full, before you start — every point is one of these and there is nothing else. Each one runs your code; it is not a search for keywords.

  1. topoSort never runs a job before what it needs+30Dependencies and ordering
  2. waves groups what can run at the same time+25Dependencies and ordering
  3. findCycle names what can never run+25Dependencies and ordering
  4. A dependency that does not exist is never satisfied+10Dependencies and ordering
  5. It orders 8,000 jobs in time+10The cost of a loop inside a loop

What it teaches

Dependencies and orderingadvanced

When things depend on other things, you cannot just sort them — you repeatedly take whatever is ready, and whatever is never ready is a cycle, which is exactly how a CI pipeline decides what to run and when to refuse.

The cost of a loop inside a loopintermediate

A search inside a loop does the work once per row per row: at 20,000 rows that is 400 million comparisons, and it is the single most common reason a working feature is unusably slow.

The rest of Data Structures at Work