Machine coding round questions such as parking lot, rate limiter, Splitwise, elevator, vending machine, and other timed build-it problems.
14 questions in Low-Level Design & OOD.
A food ordering design has two lifecycles: the order moves from placed to delivered, while delivery partner assignment runs alongside and can fail and restart. Keep them separate, claim a partner atomically, rank candidates behind a strategy, and write cancellation windows as rules keyed on order state.
A digital wallet stays non-negative only if the balance check and the debit happen in one critical section. Lock both wallets in a fixed order by id so concurrent transfers cannot deadlock, record every movement as a pair of entries, and make each transfer idempotent on a client key so a retry cannot pay twice.
Write the domain model, the interfaces and the code enforcing each invariant yourself, because the grader scores them and a mid-round change tests them. Hand the assistant bounded boilerplate such as records, an in-memory repository, a driver and test scaffolding, and review every line it returns.
Write the paragraph back as a numbered list of testable rules, mark each as build, stub or out, and turn the rule with the most interacting parts into the first test. Leave out the nouns that are only context, the features introduced with 'eventually', and every side channel the rules do not depend on.
The passing candidate said, before typing, which approach they chose, which alternative they rejected and what that choice costs. Identical code then reads as a decision rather than recall, the interviewer can redirect before the time is spent, and later follow-ups confirm rather than interrogate.
Model a Board that only stores marks and rejects illegal squares, and a Game that owns the turn and a status of in progress, won or drawn. The win check belongs inside the Game's move method, testing only lines through the square just played and running before the draw check, so a finished game refuses further moves.
A rate limiter machine coding solution should reject fixed-window boundary bursts, usually with a token bucket. It needs no per-request history and stores two numbers per client, but only if refill is computed lazily from a timestamp rather than by running a background thread. Use this rate limiting answer to show the decision, trade-off, and evidence rather than a memorised definition.
A Splitwise-style machine coding answer turns on one invariant: the shares of an expense must sum to the expense total exactly, in every currency, forever. That forces money into integer minor units and forces a stated rule for allocating the remainder.
An in-memory pub-sub with at-least-once delivery stores each topic as an append-only log and gives every subscriber its own cursor and in-flight set. A message stays in flight until acknowledged and is redelivered after an ack timeout, so a slow subscriber only delays itself and every handler must tolerate duplicates.
An elevator system splits into a state machine per lift that decides its own next floor, and a dispatcher that assigns each hall call to one lift through a pluggable strategy such as a nearest-suitable-car cost. Car buttons go straight to their lift, and one control loop owns all state, so no god class and no locks.
An in-memory job scheduler keeps one queue ordered by next run time, such as a DelayQueue, and one dispatcher thread that hands due entries to a worker pool. Recurring jobs are re-queued after each run, cancellation is a generation check on dequeue, and missed runs need a stated skip or catch-up policy.
Expire keys lazily on read and actively with a background sweep, both through the write path. For a consistent snapshot of a key-value store, copying the live map is not enough: take a brief cut, have each writer save a key's old value before changing it, and merge those saved values into the scan.
A ticket booking design models a Show that owns its seat states and a Hold with an owner, seat set and expiry. Holds are taken all-or-nothing under a per-show lock, expiry is checked lazily so no timer decides correctness, and starting payment moves the hold to a state the timer can no longer release.
In a parking lot machine coding round, scope one deterministic flow of park, unpark and charge, model Vehicle, Slot, Level, Ticket and a ParkingLot facade, then push slot allocation and pricing behind strategy interfaces so review-time variants are configuration rather than surgery.