Loadingone moment…
Sign in to run and submit your work
Reading is open to everyone. Running code and saving drafts need an account so your work is yours and comes back on your next visit.
or
CODE WORKSPACE
The scheduler runs hundreds of jobs a night and the platform team has to decide how many workers to rent. The number that matters is not the average load; it is the peak: the most jobs that were running at the same moment.
Write peak_concurrency(jobs). It takes jobs, a list of dicts with a job name and integer start and end minutes. A job runs during the half-open range from start up to but not including end. It returns a dict {"peak": int, "at_minute": int | None}: the largest number of jobs running together, and the earliest minute at which that number was reached.
Function to write
peak_concurrency(jobs: list[dict]) -> dictA dict with the peak number of jobs running together and the earliest minute that peak was reached, or peak 0 and None when nothing ran.
How to approach it
Do not compare jobs with each other. Turn each job into two events, sort them, and keep one running count. Decide what sorts first when two events share a minute.
Sample cases
+ 3 held back until you submit
a nightly batch window
Three jobs overlap between minutes 25 and 30, so the peak is 3 and it first happens at minute 25.
Input
Argument 1
| job | start | end |
|---|---|---|
| extract | 0 | 30 |
| transform | 20 | 50 |
| load | 25 | 40 |
| report | 60 | 70 |
Returns
{
'peak': 3,
'at_minute': 25
}jobs that only touch
Each job starts the minute the last one ends. Half-open intervals never overlap here, so the peak is 1.
Input
Argument 1
| job | start | end |
|---|---|---|
| a | 0 | 10 |
| b | 10 | 20 |
| c | 20 | 30 |
Returns
{
'peak': 1,
'at_minute': 0
}nested and identical jobs
The outer job holds the whole range while two identical jobs sit inside it: peak 3 at minute 10.
Input
Argument 1
| job | start | end |
|---|---|---|
| outer | 0 | 100 |
| inner | 10 | 20 |
| twin-1 | 10 | 20 |
Returns
{
'peak': 3,
'at_minute': 10
}no jobs at all
Nothing ran, so the peak is 0 and there is no minute to report.
Input
Argument 1
[] (empty list)
Returns
{
'peak': 0,
'at_minute': None
}Constraints
at_minute as the earliest minute at which the peak count was reached. When two separate moments tie for the peak, the earlier one wins.end <= start never runs. Ignore it completely.{"peak": 0, "at_minute": None}.Worked example
Take the jobs extract 0–30, transform 20–50, load 25–40 and report 60–70. Turn each into two events: +1 at its start and -1 at its end. Sorted, the events are 0:+1, 20:+1, 25:+1, 30:-1, 40:-1, 50:-1, 60:+1, 70:-1. The running count goes 1, 2, 3, 2, 1, 0, 1, 0. The count first reaches 3 at minute 25, so the answer is {"peak": 3, "at_minute": 25}.
The trap: jobs a 0–10, b 10–20 and c 20–30 only touch. If the sort puts the +1 at minute 10 before the -1 at minute 10, the count briefly reads 2. You then report a peak that never happened.
What this tests
The sweep line, the interval pattern behind LeetCode 'Meeting Rooms II'. The idea is to think about events, not intervals. Starts add one, ends take one away, and a sorted pass keeps a running count. Data engineers use it to size worker pools, count simultaneous connections, and find the busiest moment in a job history. A detail that often trips people up is what happens to events at the same minute.
peak_concurrency(jobs: list[dict]) -> dictSubmit for review to find out what your query gets right, what it gets wrong, and how it compares with the best working query for this exercise.
This scenario runs a full workspace — editor, canvas and results side by side. It needs a laptop or desktop to be usable. Open this page on a bigger screen to start building.