What to expect
Two buyers submit bids near an auction deadline. One browser displays success after the deadline, while the server recorded the request just before it. Which bid is valid, and what evidence explains the outcome? This is a useful ACV Auctions preparation case because concurrency and time have visible consequences for marketplace trust.
ACV's marketplace description explains wholesale vehicle buying and selling. Its buyer page highlights condition reports and inspection technology. These facts support auction, listing, and media examples. They do not establish the company's internal bidding rules, service architecture, or engineering interview sequence.
All auction rules below are explicitly invented for practice. Do not confuse them with ACV's commercial terms or assume that a successful toy auction implementation models its real marketplace. Confirm the product area, seniority, and assessment format with your recruiter.
Prepare for correctness under contention
Practise explaining the difference between receiving a request, accepting a bid, publishing an update, and closing an auction. A WebSocket message is a presentation of state, not automatically the authoritative state itself. A robust answer identifies where ordering and acceptance are decided.
For a backend role, focus on atomic acceptance and repeat requests. For frontend work, show reconnect behaviour and recovery from missed updates. For data or inspection tooling, practise versioned listing content, media-processing failures, and data-quality checks. These are suggested emphases based on product context, not guaranteed interview categories.
Coding case: evaluate a stream of bids
Original practice exercise: an auction closes at integer server time T. Input bids are ordered by server acceptance sequence and contain an identifier, bidder, amount in cents, and received time. A bid is eligible only when its time is strictly less than T and its amount exceeds the current best by at least a fixed increment. Identical retries return the existing outcome.
Suppose the initial best is 1,000 cents, the increment is 100, and T = 10. A 1,100 bid at time 8 succeeds; 1,150 at time 9 fails the increment rule; 1,200 at time 10 is too late. These rules make the exact deadline and increment test unambiguous.
Process bids in the supplied sequence, retain the current best, and maintain outcomes by identifier. A repeated identifier with changed content is an error, not a second bid. Expected time is O(n), while remembering all retry outcomes uses O(n) space. State that outcome retention is part of the exercise rather than claiming constant-memory operation.
Test deadline equality, a zero or negative increment rejected at configuration time, unchanged retries, conflicting identifier reuse, bids below the current best, and ties. If asked about client timestamps, explain why this exercise uses server receipt time and what clock or sequencing guarantee the authoritative component must provide.
This sequential function does not solve distributed concurrency. Two workers can both read an old best bid and accept incompatible updates unless the shared state has an atomic rule. Use that limitation as the bridge into the design discussion rather than hiding it behind the word “real-time.”
SQL case: highest accepted amount per auction
Assume auctions(id) and bids(id, auction_id, amount_cents, accepted). Include auctions with no accepted bid and leave their highest amount null.
SELECT a.id,
MAX(b.amount_cents)
AS highest_accepted
FROM auctions AS a
LEFT JOIN bids AS b
ON b.auction_id = a.id
AND b.accepted = 1
GROUP BY a.id
ORDER BY a.id;
This query reports an amount; it does not identify a winner or establish settlement. If multiple bids have the same amount, an accepted ordering rule is still needed. Do not select an arbitrary bidder alongside MAX and assume the database associates them correctly.
Test an auction with accepted and rejected bids, one with only rejected bids, and one with none. A null result means no accepted bid under the query, not a zero-dollar bid. Add currency and auction-state dimensions only after stating how they affect interpretation.
Design case: authoritative bidding with reconnectable clients
Authenticate a bidder and validate auction eligibility before attempting acceptance. Give each logical bid an idempotency identifier. The acceptance operation must compare current state, deadline, and increment atomically with recording the new bid. A database transaction or a single sequenced owner can be a starting design; explain its failure and recovery model.
Store accepted outcomes durably before telling the client the bid succeeded. A connection failure after commit should be recoverable by looking up the bid identifier. Do not ask the user to create a new logical bid just because the response was lost.
Publish updates with a sequence number. A reconnecting client can fetch the current snapshot and discover whether it missed events. The displayed countdown should be treated as user guidance; the authoritative close decision belongs to the server-side contract. Explain how the interface presents a rejected or uncertain request without confusing it with acceptance.
Close the auction using the same authoritative state boundary that governs acceptance. Prevent a close operation and a late acceptance from both succeeding under contradictory assumptions. Settlement and notifications are separate workflows; an accepted highest bid is not automatically evidence that every subsequent business step completed.
For listing media, link inspection reports and images to a version. A changed condition report can affect user understanding even if the bidding service is correct. In this exercise, preserve which listing version was visible around a bid and provide a controlled way to trace revisions. Actual disclosure and marketplace policy should come from the business owner.
Debugging: two users believe they won
Compare durable accepted bids and the authoritative close record before looking at screenshots. Screens may have missed updates or displayed optimistic state. Trace each bid identifier, its sequence, the response returned, and the final snapshot the client received.
Determine whether the defect is contradictory server acceptance or misleading client presentation. The former requires fixing an atomicity boundary; the latter may require sequence-aware reconnect and clearer pending states. Both matter, but they are not repaired by the same cache invalidation.
Add a contention test around closure and a client test that drops several updates before reconnecting. Test a lost response after a successful acceptance. Explain what audit evidence lets support describe the outcome without relying on one browser's clock.
Behavioral examples and questions for ACV
Prepare a story about a race condition, a marketplace or customer-trust issue, or a system that needed a clear audit trail. Explain the smallest reproduction, the invariant that failed, and how the user experience changed after the fix. Avoid inventing high-scale numbers if your evidence comes from a smaller system.
Ask which product area the role owns, how correctness under load is tested, how clients recover from missed events, and how engineers collaborate with operational teams. A condition-reporting team and a bidding team may need quite different preparation.
Your practice deliverables
Build the deterministic bid evaluator, test the accepted-amount query, and draw the atomic acceptance boundary. Add a reconnect scenario and a deadline race. Be able to explain why a fast update channel and a correct marketplace are related but separate goals.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of ACV Auctions's hiring timeline. Adjust it to the current job description and the time you actually have. If the recruiter confirms a different emphasis, move time toward that assessment instead of completing every exercise mechanically.
Days 1–3: turn the coding case into an executable contract
Implement the bid evaluation exercise in your strongest interview language. Before coding, write the input shape, invalid-input policy, tie-breaking rule, and expected output. Keep one deliberately small example that you can trace by hand. Add a test for each boundary described in the exercise rather than relying on a large random input to discover mistakes.
After the first working version, explain why your chosen data structure fits the operations you need. State both time and space costs, including retained retry history or copied state where relevant. Then change one requirement and identify which assumption breaks. Your goal is to demonstrate controlled reasoning when a problem changes, not to memorise one implementation.
Days 4–5: prove the SQL result on a tiny dataset
Create the tables used in the SQL case and insert a normal record, a missing-related-record case, and a duplicate or irrelevant record. Predict the output before executing the query. Check whether the result is one row per entity or one row per event, and whether null means missing data, unknown state, or a legitimate business value.
Explain how a join can multiply rows and why filtering a joined table in the wrong place can remove the very records you are looking for. For performance, begin with the lookup keys and expected access pattern; inspect an execution plan before promising that an index will solve the problem. Keep correctness and performance as separate review questions.
Days 6–9: draw the state boundary and break it
Use the architecture diagram as a starting point, then mark the operation that must be atomic. Write down what the caller is entitled to believe after a success response. For this case, make the durable bid sequence and authoritative close record visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate a bid arriving exactly at closure while a client reconnects. Record the state before the failure, the durable evidence after it, and the next action each component takes. A useful recovery story explains how the system distinguishes an incomplete operation from a completed operation whose response was lost. It also states what an operator can inspect without making the incident worse.
Days 10–12: practise diagnosis and communication
Rehearse the incident where two browsers display different winners. Give yourself a short log extract or a handful of records rather than omniscient knowledge of the bug. Separate observations from hypotheses. Name the first query or trace you would inspect and explain which competing explanations its result would rule out.
Prepare one experience from your own work that demonstrates similar judgment. Describe the constraint, the decision you personally made, and the evidence that the change helped. If you do not have production experience, use a course or personal project honestly and explain the additional controls a production deployment would require.
Days 13–14: run a mock and repair the weakest answer
Spend one session on coding and another on design. Ask your mock interviewer to challenge a hidden assumption rather than only checking the final answer. Afterward, choose one specific weakness: unclear failure semantics, an untested boundary, an ambiguous schema, or an explanation that begins with tools before requirements. Revise that artifact and run the same scenario again.
Frequently asked questions
Are these verified ACV Auctions interview questions?
No. The coding, SQL, and design cases are original preparation exercises informed by the company's public business context. The linked sources establish that context; they do not verify that these prompts appeared in an interview. Use any current recruiter instructions as the authority for your actual assessment format.
Which language should I use?
Use a language in which you can implement and test the exercise clearly, unless the current role or assessment specifies one. Practise explaining your standard library choices and failure handling. A company product page is not enough evidence to infer the language required in an interview.
What should I prioritise if I have only a weekend?
Complete one tested coding solution, run the SQL example against a tiny fixture, and walk through the failure scenario above. Then prepare two concise project stories and questions about the actual team. A small set of defensible answers is more useful than superficial familiarity with every possible technology.
For broader practice, use the PracHub Software Engineer question bank. Its questions are general role practice and should not be treated as verified questions from ACV Auctions.