Sequential Progress Bars

Build a small feature where each click on Add appends a progress bar, and the bars fill one at a time — each taking about two seconds — with anything added mid-fill waiting its turn.

It reads like an animation exercise and is really a queueing exercise. The version most people write first gives every bar its own timer at the moment it is created, which fills them all simultaneously; no adjustment to the duration fixes that, because the bug is that nothing tells a new timer to wait.

Inverting the design solves it completely: a single interval that, on each tick, finds the one unfinished bar and advances only that. Because bars are appended and never reordered, the array is the queue — the first bar below 100% is its front — so no separate queue structure is needed at all.

What the interviewer is watching for is whether you notice the queue is already in your data, whether the interval stops when there is nothing to do, and whether your dependency array avoids rebuilding the timer on every tick. The natural follow-up is a concurrency limit: fill three at a time. That is a one-line change with a single driver, and a rewrite with a timer per bar.