Section 1: The Bid That Is Not a Price - Problem Understanding & Clarifications

Executive Summary: This section opens a Staff/Principal interview on a system everyone has used and almost nobody has examined: the auction engine behind eBay. We decompose the prompt four ways, name the two symmetric ways strong candidates fail it - the Price Clicker, who models a bid as the number on the screen, and the Consensus Cathedral, who hears "the winner must be correct" and reaches for Paxos - and run five clarifying exchanges that each delete a category of work: proxy bidding, hard close, no payments or search, what "hot" means in numbers, and whose clock decides. The prompt ends as committed assumptions, each with the condition that would reverse it, and a running example - auction #7731, a sealed Pokémon booster box ending Sunday at 19:00:00 PT - that the next twelve sections follow to the gavel.

The interviewer hands you a sentence you could have written yourself:

"Design the auction system behind eBay. A seller lists an item with a starting price and an end time. Buyers bid until the clock runs out, and the highest bid at close wins. Two things are non-negotiable: the winner must always be the person who genuinely bid the most, and a hot auction must not fall over in its last ten seconds."

You have used this product. That is the trap. "Highest bid at close wins" reads like a specification and hides the only question that matters in the first ten minutes: what is a bid? When Elena types $9,500 on Thursday, she is not naming a price. She is telling the system the most she will pay and asking it to bid for her, one increment at a time, against people she cannot see. The number on the screen is an output; her bid is an input. Two symmetric failures live in that confusion.

The Price Clicker. You model a bid as the displayed price: every click sets a new number, the highest number at the end wins. It is simple, demoable, and not eBay. It cannot represent Marcus's $12,000 standing silently behind a $4,350 price, and it hands the item to whoever clicks last - exactly the behaviour proxy bidding exists to blunt. Signal recorded: never asked what was being submitted.

The Consensus Cathedral. You hear "the winner must always be the person who genuinely bid the most" and reach for the heaviest machinery you know - Paxos, Spanner, a blockchain-style ledger - for a problem whose entire contention is one database row receiving 200 bids per second in its worst ten seconds. Signal recorded: never found the unit of consistency, which is a single auction.

Key Insight: The prompt's two non-negotiables are about different things. Correctness is a property of one auction at a time; survival is a property of the hottest one. Merge them and you build a global machine for a local problem.

Decomposing the Prompt Four Ways

Map the territory before asking a question.

• What it does. Strip it to verbs: list, bid, watch, close, notify. Only bid and close can be wrong in a way that costs money, and both must be provably right afterwards, because losers dispute.
• Who uses it. Five audiences, not "users". Buyers want to know, right now, whether they are winning. Sellers want the highest honest price. Watchers outnumber bidders ten to one on a hot item - 50,000 watching, 5,000 bidding - and never write anything. Trust and safety ops need the full history to catch a seller bidding on their own item. Third-party sniping tools, firing two seconds before the end for a paying customer, are adversarial and entirely legitimate.
• Why it exists. Final value fees. The marketplace earns a percentage of the close price, so bid integrity is revenue, and a lost bid is not a bug ticket but a dispute, a refund, and a trust story in the press.
• How it is reached. Web, native apps, and API clients - including those sniping services, whose timing sets the shape of the final second in Section 8.