Spinny-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
A full-stack used-car retailer owns the car between buying it and selling it, which turns the backend into a workflow engine over physical assets. Each vehicle moves through inspection, reconditioning, photography, listing, test drives, and sale, and it can only be sold once — by exactly one customer, after exactly the right gates have passed. Machine coding rounds in the style of Spinny build on that pipeline.
What makes the round interesting is the combination of a strict per-asset state machine with a reservation problem where quantity is always one. This page covers the commonly reported format, the evaluation criteria, and Gronex repositories that train the same workflow and reservation mechanics.
What a Spinny-style machine coding round looks like
A representative statement asks for a vehicle lifecycle service: move a vehicle through stages where each stage has entry conditions (reconditioning cannot start before inspection is complete; listing requires photographs and a price), allow a customer to reserve a listed vehicle with a deposit and an expiry, and handle sale or release. Some variants focus on test-drive scheduling across hubs instead.
Gated transitions are graded on where the gate lives. A single transition method that consults a table of allowed moves and their entry conditions is the shape that survives the follow-up — "now a vehicle cannot be listed until the registration transfer is initiated" — whereas per-stage conditionals scattered across service methods require touching five places. Reviewers reliably ask for a new gate, precisely to see this.
The reservation half is a single-unit claim with an expiry. Two customers reserving the same vehicle, a reservation expiring while payment is in progress, and a reservation released back to listed status are the three probes. Because the asset is unique, the correct answer is a compare-and-set on the vehicle’s state rather than a counter decrement, and saying that out loud is usually worth more than the code.
How you’re evaluated
Table-driven transitions
One transition method, a table of legal moves, and entry conditions as data — so a new gate is a data change.
Single-unit reservation
Compare-and-set on the vehicle state, with an expiry and a release path, so only one customer can ever hold it.
Stage history
A record of when each stage was entered and by whom, making the current state explainable and auditable.
Defensible rejections
Blocked transitions return the specific unmet condition rather than a generic failure.
Common mistakes that fail this round
- Spreading entry conditions across per-stage methods, so a new gate means editing everything.
- Using a quantity counter for a unique asset, which invites the wrong concurrency fix.
- Reservations with no expiry, leaving vehicles unsellable after an abandoned checkout.
- Overwriting the stage field directly in one code path, bypassing the transition validation entirely.
- Keeping only the current stage with no history, so the demo cannot answer when or why a vehicle moved.
Quick tips for the room
- Put transitions and entry conditions in a table; never in scattered ifs.
- Use compare-and-set on the vehicle state for reservations.
- Record stage history with timestamps from the start.
- Return the unmet condition on every rejected transition.
How to prepare
Write the transition table and entry conditions first, as data, with one transition() that validates and records history. Then add reservation as a compare-and-set with an expiry and a release. Ask yourself what happens if a vehicle is reserved while reconditioning reopens — that interaction between two state dimensions is a favourite probe.
The repositories below cover the ground: the task dependency problem is gated progression with prerequisites, the expiring-holds problem is single-unit reservation with timeouts, the RMA problem is a non-skippable workflow with atomic side effects, the free seat-reservation problem is the claim baseline, and the Kanban problem drills stage transitions with limits.
Practice problems in the Spinny-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Task Dependency Manager
Gated progression as a graph: prerequisites, cycle detection, and deterministic ordering.
Open the challenge →Reservation with Expiring Holds
Single-unit holds with expiry, released exactly once, safe when two customers claim simultaneously.
Open the challenge →Return Authorization & Restock
A non-skippable workflow with atomic side effects — the shape every asset pipeline needs.
Open the challenge →Kanban Board with WIP Limits
Stage transitions with per-column limits and validated moves — workflow mechanics in miniature.
Open the challenge →Seat Reservation System
Reserve, cancel, and list availability deterministically — the claim-and-release baseline. Free to try.
Open the challenge →FAQ
Were these problems asked at Spinny?
No. They are Gronex originals in the style of owned-inventory marketplace rounds — the kind of problem asked in rounds like Spinny’s. Gronex is not affiliated with Spinny.
Why is a transition table better than conditionals?
Because the round will add a gate. With a table, the change is one entry; with conditionals, it is an audit of every service method — and the interviewer watches which one you have.
How is this different from an auction-style round?
Auction rounds grade bid ordering and closing. Owned-inventory rounds grade the workflow gates and a single-unit reservation, so state-machine discipline matters more than competitive ordering.
Should the deposit and payment be modelled?
Lightly. A deposit that is held with the reservation and released or applied on outcome is enough to show the money path; a full payments implementation is usually scope you cannot afford inside the clock.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Spinny. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Spinny.