Implement `mapWithConcurrency(items, limit, worker)`, which keeps at most `limit` calls to the async `worker` running at once and resolves to an array of results in the original `items` order. How does your implementation work?

## The shape of the problem You want three things at once: never more than `limit` operations in flight, results in input order, and no promise created before there is a slot for it. The last point rules out `items.map(worker)` entirely — that starts everything. What you need is a small number of long-lived loops that each pull work. ## The pool ```js async function mapWithConcurrency(items, limit, worker) { const results = new Array(items.length); let next = 0; async function runner() { while (next < items.length) { const i = next++; results[i] = await worker(items[i], i); } } const runners = Array.from({ length: Math.min(limit, items.length) }, runner); await Promise.all(runners); return results; } ``` That is the whole thing. Walk an interviewer through it in four beats. **One cursor, many consumers.** `next` lives in the closure shared by every runner. Each iteration claims exactly one index. Because the claim and the increment happen in the same expression, two runners can never claim the same item. **Why no lock is needed.** `const i = next++` is a synchronous read-modify-write. JavaScript finishes the current job before running anything else, and there is no `await` between the read and the write, so no other runner can observe a stale `next`. This is the one place where single-threaded semantics genuinely simplify the code: the identical loop in a threaded language would need a mutex or an atomic counter. **Why order survives.** Results are assigned by index, never pushed. Item 0 may finish last; it still lands at position 0. If you wrote `results.push(await worker(...))` you would get completion order, which is a classic bug because it looks correct whenever the fixture happens to have uniform durations. **Why concurrency is exactly `limit`.** A runner has at most one outstanding `await` at a time, and there are `limit` runners. When one finishes it immediately claims the next index — there is no barrier, no waiting for peers, so the pool stays saturated until the queue empties. ## Edge cases worth naming - `Math.min(limit, items.length)` avoids spawning idle runners; without it a limit of 100 over 3 items creates 97 loops that exit on their first condition check. Harmless but sloppy. - Empty `items` produces zero runners, `Promise.all([])` fulfils, and you get `[]`. - `new Array(n)` gives a sparse array; every slot is written before you return, so the holes never escape. If that makes you uneasy, `new Array(n).fill(undefined)` costs nothing. - Passing the index through as `worker(items[i], i)` matters when the worker needs to label its output — and it is the reason to avoid `chunk.map(worker)` style shortcuts elsewhere, where the index would be chunk-local. ## Failure behaviour If `worker` rejects, the `await` inside that runner throws, the runner's promise rejects, and `Promise.all` rejects with the first error. The other runners are not cancelled — they are sitting on their own `await` and will complete their current item (and then keep pulling, since nothing told them to stop). If you want the pool to wind down on first failure, set a shared `failed` flag and check it in the loop condition. If you want every item attempted regardless, wrap the call so it cannot reject: ```js results[i] = await worker(items[i], i).then( (value) => ({ ok: true, value }), (error) => ({ ok: false, error }), ); ``` ## The semaphore variant A pool is the right shape when you own the loop. When calls are scattered across a codebase, you want a limiter object instead: a function that accepts a thunk, runs it if a slot is free, and otherwise queues it. Callers then write `limiter(() => fetchUser(id))` anywhere, and the cap is global across all call sites because they share one limiter instance. With that in hand, `await Promise.all(ids.map((id) => limiter(() => fetchUser(id))))` is correct and bounded — the `map` creates queue entries, not requests, and `Promise.all` still gives you input order for free. ## Bugs interviewers watch for - Recomputing the index as `items.indexOf(item)` — quadratic, and wrong with duplicate values. - Reading `next` and incrementing it on separate lines *across an await*, which reintroduces the double-claim. - Starting the runners inside a loop that awaits each one, which silently makes concurrency 1. - Building the promise array first and "limiting" afterwards, which limits nothing.