Top 14 Machine coding Interview Questions
Browse 14 real-world technical and behavioral interview questions about Machine coding. Review scenarios, edge cases, and architectural best practices.
Build an in-memory pub-sub with topics, many subscribers per topic and at-least-once delivery. How does a message get redelivered?
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.
Design a food-ordering system: customers place orders with restaurants, and the system assigns a delivery partner. Walk me through the classes.
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.
Design an elevator system for a building with N lifts. When someone presses the call button, which lift answers, and where in your code is that decided?
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.
Design an in-memory job scheduler that runs one-off, delayed and recurring jobs. Write the core classes.
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.
Build a digital wallet with transfers where a balance can never go negative, even when many transfers run at the same moment.
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.
Build an in-memory key-value store with per-key TTL, plus a snapshot operation that gives a consistent copy while writes keep coming in.
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.
Design a movie ticket booking system with shows, seats and a temporary hold that expires if the user does not pay. Write the classes.
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.
You may use an AI coding assistant in the machine-coding round. What do you still write yourself, and what do you ask it for?
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.
You are given a paragraph of requirements, not a problem statement. What do you write first, and what do you deliberately not build?
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.
Two candidates write the same class and one passes. What did the other one not say in the ten seconds before typing?
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.
Write a game where two players take turns and either of them can win. What do you model, and where does the win check belong?
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.
Design a parking lot system — you have 90 minutes, working code at the end.
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.
Design a rate limiter that allows N requests per client per minute. Write the class.
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.
Build a shared-expense tracker. Three people split a bill of ten pounds evenly - write the classes, and tell me where the missing penny goes.
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.