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
A streaming job writes small micro-batches, and the compaction service merges consecutive batches into files of at least a target size so the lake is not full of tiny files. To tune it, the team wants to know the fewest consecutive batches that would ever have been enough to fill one file.
Write shortest_run(batch_sizes, threshold). It takes batch_sizes, a list of positive integer batch sizes (in MB here, to keep the numbers readable) in arrival order, and threshold, the integer target file size in the same unit. It returns a dict {"start": int, "length": int} for the shortest qualifying run, or None.
Function to write
shortest_run(batch_sizes: list[int], threshold: int) -> dict | NoneA dict with the start index and length of the earliest shortest run whose total reaches the threshold, or None when none does.
How to approach it
Grow the run until it fills the file, then shrink it from the left for as long as it still does — every step of that shrinking is a candidate answer.
Sample cases
+ 3 held back until you submit
a morning of micro-batches
No run lands exactly on 100, but 35 + 10 + 60 = 105 fills it in three batches.
Input
Argument 1
[
20,
35,
10,
60,
5,
40,
30
]Argument 2
100Returns
{
'start': 1,
'length': 3
}two shortest runs tie
Two pairs reach exactly 100 (starting at 0 and at 2), so the earliest start wins.
Input
Argument 1
[
60,
40,
25,
75,
10
]Argument 2
100Returns
{
'start': 0,
'length': 2
}one batch is enough
A single oversized batch fills the file alone, so the shortest run has length 1.
Input
Argument 1
[
30,
150,
20
]Argument 2
100Returns
{
'start': 1,
'length': 1
}the file never fills
All three batches together total only 60, so no run qualifies and the answer is None.
Input
Argument 1
[
10,
20,
30
]Argument 2
100Returns
None
Constraints
batch_sizes. It qualifies when its total is greater than or equal to threshold — overshooting is fine.{"start": i, "length": n} where n is the fewest batches in any qualifying run and i is that run's first index.None when no run qualifies, when batch_sizes is empty, or when threshold <= 0 (a non-positive target is treated as meaningless, not as 'zero batches').Worked example
Take [20, 35, 10, 60, 5, 40, 30] with threshold = 100. Grow the run from the right and keep a running total: 20, 55, 65, then adding 60 gives 125 — the run 0–3 fills the file in 4 batches. Now shrink from the left while it still fills: drop 20 → 105, still ≥ 100, so run 1–3 fills it in 3. Drop 35 → 70, too small, stop. Add 5 → 75, add 40 → 115: run 2–5 is 4 batches; drop 10 → 105, run 3–5 is 3 batches, not shorter; drop 60 → 45, stop. Add 30 → 75. The answer is {"start": 1, "length": 3}.
The trap: reading 'fill the file' as 'total equals 100'. In this case no run sums to exactly 100, so an equality check returns None for a stream that clearly fills files.
What this tests
The shrinking sliding window — LeetCode 'Minimum Size Subarray Sum' in compaction clothing. The target is O(n) time and O(1) space; trying every start and extending it is O(n²). It only works because sizes are positive, so shrinking never raises the total. Data engineers meet this sizing compaction and small-file merges, and finding the shortest stretch of a stream that reached a volume threshold. This exact problem is not named in the data engineering reports we could find; it is the standard Minimum Size Subarray Sum shape and covers the shrink-while-valid variant of the pattern.
shortest_run(batch_sizes: list[int], threshold: int) -> dict | NoneSubmit 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.