Uber-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Uber-style machine coding rounds pull their scenarios from the hardest part of the business: matching supply to demand in real time. You get a dispatch-flavoured problem — driver assignment, trip lifecycle, surge windows — and a fixed window to hand back a service that runs and holds its invariants while events race.
The domain makes concurrency non-optional. Two riders requesting the same nearby driver, a trip cancellation racing an assignment, a location update arriving mid-match — these are the problem, not a footnote. This page breaks down the commonly reported shape of Uber-style rounds, how they’re graded, and Gronex problems in the same style you can rehearse in a real repository.
What a Uber-style machine coding round looks like
The typical shape is around 90 minutes, solo, on your own machine. You receive a dispatch-style problem — assign the best available driver, model a trip as a state machine, resolve two requests racing the same driver — with functional requirements and explicitly called-out race conditions. You produce a small, runnable service demoed at the end.
Working code is the entry ticket. Uber-style rounds are strict on the demo, then move fast to concurrency: "what if two riders match the same driver at once", "what if the driver cancels after assignment but before pickup". Your locking and state transitions are the real subject.
Expect a live requirement change — a driver-preference rule, a cancellation penalty, a re-matching path when a driver goes offline mid-trip. The round tests whether your trip and assignment model bends without breaking.
How you’re evaluated
A running demo
Requirements implemented and the assignment flow executable end to end without crashing while the interviewer drives it.
Race resolution
Two requests for one driver, cancel-versus-assign, offline-mid-trip — exactly one outcome wins and the state stays consistent.
Trip state modelling
Requested, matched, en route, ongoing, completed, cancelled as a real state machine with illegal transitions blocked, not guarded by scattered checks.
Extensibility under change
A new matching rule or cancellation path at minute 70 slots into a clean seam rather than forcing a rewrite of the dispatch loop.
Common mistakes that fail this round
- Treating driver matching as a simple lookup and ignoring the two-riders-one-driver race that defines the problem.
- Reaching the demo with a design but no runnable assignment flow.
- Modelling the trip as loose booleans instead of a state machine, so illegal transitions slip through.
- Forgetting the cancel-versus-assign race, so a cancelled trip still holds a driver.
- Hard-coding the matching rule so the inevitable "prefer higher-rated drivers" extension needs a rewrite.
Quick tips for the room
- Get an end-to-end skeleton running in the first 30 minutes, then iterate.
- Pick your locking granularity early — per-driver locks in a stable order keep unrelated matches concurrent.
- Model the trip as a state machine and make illegal transitions unrepresentable.
- Keep a two-minute buffer to rehearse the demo before you present it.
How to prepare
Practise the loop under a timer: take a dispatch or matching problem, set 90 minutes, and drive it to a runnable demo with the key race handled. The skill Uber-style rounds separate on is making exactly one request win a contested resource without deadlocking the rest.
The Gronex problems below mirror the format from the other side — real backend repositories with failing tests that race assignment and trip transitions, so you rehearse the exact concurrency muscle the round grades. Start free, then take the HARD race-resolution problem.
Practice problems in the Uber-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.
Ride Booking Driver Assignment Race Resolution
The two-riders-one-driver race: exactly one assignment wins, the losers re-match, and no driver is double-booked.
Open the challenge →Ride Booking Driver Matching System
Match the best available driver to a request with clear, extensible selection rules and a clean trip lifecycle.
Open the challenge →Food Delivery Order Status Tracker
An order lifecycle as a state machine: legal transitions only, with consistent status queries as events arrive.
Open the challenge →Distributed Job Scheduler (Singleton Execution)
Exactly-once scheduled execution across many workers — the backbone of surge windows and timed dispatch jobs.
Open the challenge →Notification Preference & Delivery
Preference-aware, idempotent delivery across channels without duplicate sends. Free to try.
Open the challenge →Seat Reservation System
Holds as a state machine: reserve, cancel, and list availability deterministically. Free to try.
Open the challenge →FAQ
Were these problems actually asked at Uber?
No. Every problem here is a Gronex original built in the same style — real-time dispatch, matching, and trip state with working-code grading. We never republish any company’s actual interview questions, and Gronex is not affiliated with Uber.
Why is concurrency so central to this round?
Because dispatch is a concurrency problem: contested drivers, racing cancellations, and mid-trip events all mutate shared state at once. A model that only handles the sequential happy path fails the first thing an Uber-style round probes.
Which language should I practise in?
The one you’ll interview in. Gronex repositories run the same racing test suites in Java, Python, and C++.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Uber. 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 Uber.