A service seeds a dispatch heap for a million pending payments with a one-by-one insert loop — do you flag it in review?

## The reviewer's actual problem The diff seeds a priority structure by looping over a million pending payment records and inserting each one. It works. It is not the cheapest thing available. The interview question is not "which is faster" — you already know that — it is whether you can turn a complexity fact into a proportionate review decision. ## Fact one: is the bulk build even applicable? The linear build needs the entire collection present, in storage you are permitted to rearrange, before any extraction begins. Three situations rule it out: - **Streaming arrival.** Records trickling in from a queue or a paged cursor cannot be heapified; there is no complete array. Insertion is correct and the review comment is wrong. - **A borrowed collection.** If the caller's array must keep its order, you need a copy, which costs O(n) anyway and may be the real cost driver. - **Interleaved reads.** If the dispatcher starts pulling from the top while the loader is still adding, the collection is never complete and only insertion makes sense. If none of these apply — records are read in a batch, then dispatch begins — the bulk build applies cleanly. ## Fact two: how big is the build inside the job? A million-element heap build is on the order of tens of milliseconds; a million-element insertion build is on the order of a few hundred. If the job then makes a million outbound payment dispatches, that difference is invisible and no amount of asymptotic correctness makes it a release blocker. If the same construction happens inside a request path, or once per shard per minute across a fleet, the same milliseconds become a real line item. This is the discipline that separates a senior review from a reflexive one: the complexity fact is certain, its *importance* is not, and stating both is the answer. What tips it here is cost of the fix. Swapping an insert loop for a bulk build is one call, no new data structures, no new failure modes, and the change is trivially testable by asserting the heap invariant and the extraction order. When a strictly better option costs one line, you take it even at low stakes — and you say plainly that you are taking it for craft reasons, not because you measured a regression. ## Fact three: what does the input order do? This is the part most candidates miss, and it is where the real risk hides. For uniformly random input, the insertion build averages linear time — a random arrival usually loses to its parent immediately and stops. So a benchmark on shuffled fixtures shows the two builds nearly tied, and someone will use that benchmark to reject your comment. The worst case is input arriving in extreme-first order: for a min-heap keyed on deadline, records in strictly decreasing key order make every arrival the new minimum, sending it all the way to the root and costing the full log n every time. Pending payments read from an ordered query arrive sorted, and whether that sorted order is the cheap direction or the catastrophic one depends on which way the ordering runs relative to the heap's polarity — a detail nobody controls deliberately, and which flips the day someone changes the ordering clause. The bulk build has no such sensitivity: its linear bound holds for every input. So the argument to make in review is not "it is 20x faster." It is "it removes a worst case that our input order can wander into." ## Fact four: allocation behaviour The insert loop typically grows a container as it goes, reallocating and copying at each growth step, and those copies are on top of the sift-up work. The bulk build runs in place over the array the records were already read into, with O(1) auxiliary space for an iterative sift-down. On a million records the difference in peak footprint and in allocator pressure can matter more than the comparison count. ## What to write in the comment Something short and falsifiable: "All records are in hand before dispatch starts, so this can be a single bulk heap build — linear instead of log-linear worst case, in place, and it removes the dependency on the order the query returns rows in. If the loader ever becomes streaming, revert to inserts." That names the change, the benefit, the property it protects, and the condition under which the decision reverses. ## The failure modes on both sides Blocking a merge over a build that is 0.1% of the job is over-reach. Waving it through because "n log n and n are both fine at this size" ignores that the cheaper option costs nothing to adopt and removes an input-order landmine. The defensible position sits between them: request the change, do not gate the release on it, and record why.