Why are six slots assigned when only five are available?
A small job planner divides five whole slots between two equal queues. Each share looks reasonable on its own, but the result cannot be used.
The question
Fictional exercise. The supplied code, data and outcomes are authored teaching examples, not an employer question or model output.
function allocate(total, weights) {
const sum = weights.reduce((a, b) => a + b, 0);
return weights.map(weight => Math.round(total * weight / sum));
}| Total | First weight | Second weight | |
|---|---|---|---|
| Equal queues | 5 | 1 | 1 |
| Unequal queues | 7 | 2 | 1 |
| Zero total | 0 | 0 | 0 |
| No positive weight | 5 | 0 | 0 |
Authored domain: total and weights are integers from 0 to 1,000; no more than twenty ordered queues.
Counts are nonnegative integers and sum to total. Zero-weight queues receive zero. For total zero return one zero per queue. Positive total with zero total weight is invalid and returns no allocation. Otherwise floor each share and assign remaining slots by descending fractional remainder, breaking ties by original queue order. An empty queue list is valid only for total zero.
“Find the conservation failure, choose a repair and state what happens for zero total weight.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Check the whole result
What would you do here? Open the move you’d make.
Check nonnegativity only
Tempting, but it misses something. Six nonnegative allocated slots still exceed five available.
Check the output sum against the input total
The strong move. That directly exposes the violated whole-result invariant.
Treat the extra slot as harmless rounding
Tempting, but it misses something. The output cannot allocate capacity that does not exist.
See how a strong candidate says it
“Each equal share is 2.5, rounded to 3. The output [3,3] totals 6, not 5. Reasonable-looking individual shares do not establish the conservation rule.”
Why it works: The caller needs one feasible whole result.
Step 2: Use the stated tie rule
What would you do here? Open the move you’d make.
Floor, then assign the remainder by the supplied rule
The strong move. This preserves the total and the tie behavior.
Always add the remainder to the last queue
Tempting, but it misses something. That changes the explicit tie rule.
Round independently again
Tempting, but it misses something. That repeats the same conservation defect.
See how a strong candidate says it
“Floor both equal shares to [2,2]. One slot remains; equal fractional remainders use the original queue order, so the result is [3,2]. For total 7 and weights [2,1], the result is [5,2].”
Why it works: Rounding correction needs a deterministic recipient.
Step 3: Handle zero before division
What would you do here? Open the move you’d make.
Return zeros for every zero-weight input
Tempting, but it misses something. For a positive total that would violate conservation.
Let NaN stand for a pending allocation
Tempting, but it misses something. The contract requires a clear invalid input outcome.
Separate zero total from invalid positive total
The strong move. Both boundary cases now have an explicit result.
See how a strong candidate says it
“Total zero yields one zero per queue, including [0,0] weights. A positive total with zero total weight is invalid; there is no allocation. I would not divide by zero or silently return zeros and discard positive slots.”
Why it works: The zero-weight rule was fixed before the answer.
Step 4: Choose independent checks
What would you do here? Open the move you’d make.
Approve the repair from one equal-share example
Tempting, but it misses something. Zero total weight and non-tie cases remain unchecked.
Check the contract and independent boundary examples
The strong move. These checks can expose plausible but incorrect repairs.
Claim a general mathematical proof from a few rows
Tempting, but it misses something. The finite packet does not prove every possible input.
See how a strong candidate says it
“Check sum preservation, integer/nonnegative outputs, zero-weight queues, deterministic ties and the two zero-total-weight outcomes. The small stated domain lets integer numerators and remainders avoid an unnecessary floating-point comparison.”
Why it works: Checking [3,2] alone does not cover the whole contract.
The answer, in short
- Decision
- Preserve the whole total and make zero-weight behavior explicit.
- Because
- Independent rounding can create a slot that the caller does not have.
- What would change it
- A different fairness rule or numeric domain would require a revised contract and evidence.
Common traps
- Treating a plausible result as proof of the full contract.
- Claiming more than the shown inputs and checks establish.
Check your answer
- Did you calculate the six-slot defect?
- Did you preserve the total and original-order tie rule?
- Did you distinguish zero total from invalid positive total weight?
- Did you state the finite numeric-domain limit?
Last reviewed Nov 10, 2026