Backend coding interview
Auction Bidding System Coding Interview Problem
What this interview round tests
The auction is the concurrency interview problem with a scoreboard: many bidders race to outbid each other, the highest valid bid must win, and at some moment the auction closes — even as more bids are still in flight. The eBay-style round looks like a comparison and an if-statement, and that is exactly the trap.
Interviewers ask it because it stages two races on one object. The first is bid-versus-bid: two bidders both read the current high bid of 100 and both submit 110, and only one may become the leader. The second is bid-versus-close: a bid and the closing operation interleave, and the system must decide the winner exactly once, with no bid accepted after the close and no accepted bid ignored by it. Solving the first race and missing the second is the most common way strong candidates lose this round.
The scenario
You are handed the bidding service of an auction backend: bidders place bids against open auctions, the current high bid is tracked, and a close operation picks the winner. Single-threaded, everything works.
Under the test suite’s concurrent bidders it collapses: two racing bids both get accepted as the new highest, a bid sneaks in after closing and silently becomes the winner, closing twice crowns two different winners, and the recorded bid history disagrees with the winner it produced. Your job is to make bidding and closing correct under contention.
What you’ll practice
- The read-compare-write race: why "if bid > highest" is not atomic
- Per-auction critical sections instead of one global lock across all auctions
- Close-versus-bid interleavings: a terminal transition that wins every race
- Exactly-once closing: idempotent close with a single, stable winner
- Bid validation: rejecting bids on closed, unknown, or expired auctions cleanly
- A bid history that always reconciles with the declared winner
How to approach it
Make the auction the unit of protection: validating a bid against the current high and installing it as the new high must be one atomic step per auction, so two 110-bids serialize and exactly one wins. Locking per auction keeps unrelated auctions concurrent — the global-lock answer is correct and costs you the design discussion.
Treat closing as a state transition inside the same critical section, not a separate code path: once the auction flips to closed, any bid that serializes after the flip is rejected, and the winner is whatever the state said at that instant. Making close idempotent — a second close returns the same winner rather than recomputing one — closes the last gap the tests probe.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
How is the auction different from the flash sale problem?
Flash sale is a race for a decrementing counter — stock. The auction is a race for a monotonically improving value — the high bid — plus a terminal event that must beat every in-flight update. The closing race is the part with no flash-sale equivalent, and it is where this problem earns its place.
Why is "if bid > highestBid" wrong?
Because two threads can both evaluate it against the same stale value and both pass. The comparison and the assignment must be one atomic unit per auction; otherwise the second writer overwrites the first and the losing bidder is recorded as the winner.
How do the tests grade the close operation?
They race close against a burst of concurrent bids and then audit: exactly one winner, no accepted bid timestamped after the close, no winning bid missing from the history, and a repeated close returning the same result. It is the interleaving audit an interviewer runs in their head, automated.