Ola-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Ride-hailing is a two-sided allocation problem with a clock running on both sides. Riders want a cab now; drivers want the next trip; and the system in the middle must decide, in the presence of cancellations and simultaneous requests, who gets whom. Machine coding rounds in the style of Ola take their scenarios straight from that allocator.
The domain contributes three things a generic CRUD round does not: a trip state machine with real cancellation semantics, a matching policy that must be deterministic and explainable, and fare computation where surge multipliers and waiting charges have to come out to the exact rupee. This page covers the reported format, the evaluation lens, and Gronex repositories with the same mechanics.
What a Ola-style machine coding round looks like
Expect 90–120 minutes to build a dispatch slice: register drivers with locations and availability, accept ride requests, allocate the best driver by a stated policy, and drive the trip through its lifecycle. Fare rules usually arrive as a small table — base fare, per-kilometre, per-minute, surge multiplier by zone, waiting charge after N minutes — with the expectation that the total is computed exactly and can be itemised.
The matching policy is written to look simple and to punish sloppiness. Nearest available driver sounds unambiguous until two drivers are equidistant, one has a higher rating, and a third becomes available mid-search. The round wants a deterministic comparator with every tie-break named, and it wants the driver marked unavailable atomically at allocation — otherwise the same driver is offered to two riders, which is the defect this problem exists to produce.
Cancellation is the second graded surface, because it has more paths than candidates expect. A rider cancels before allocation, after allocation, after the driver arrives; a driver rejects or goes offline mid-trip. Each path must release the driver exactly once and must set a correct terminal state with a cancellation fee where the rules say so. Rounds in this style walk all of them, and the usual failure is a release that exists on only one path.
How you’re evaluated
Deterministic allocation
A single comparator with distance, rating, and arrival-order tie-breaks made explicit — same inputs, same driver, every run.
Atomic claim of a driver
Selecting and reserving the driver is one operation, so no driver is ever offered to two riders simultaneously.
Trip lifecycle completeness
Every cancellation and rejection path reaches a correct terminal state and releases the driver exactly once.
Itemised fare exactness
Base, distance, time, surge, and waiting components computed in integer paise and summing to the quoted total.
Common mistakes that fail this round
- Searching drivers over a hash map and returning the first match, so the "nearest" driver changes between runs.
- Marking the driver busy after the trip object is created, leaving a window where two riders can claim them.
- Implementing only rider-cancels-after-allocation and missing driver-rejects and rider-cancels-before-allocation.
- Applying surge as a float multiplier over a float fare and producing totals that differ by a rupee from the itemisation.
- Recomputing the fare at trip end with a different surge value than the one quoted, which the reviewer will test.
Quick tips for the room
- Write one comparator for driver ranking and reuse it everywhere.
- Claim the driver in the same operation that selects them.
- Snapshot the surge multiplier on the trip at quote time.
- Build the cancellation matrix on paper before you code any path.
How to prepare
Practise the select-claim-release loop until it is reflexive, and write the cancellation matrix — who cancels, in which state, what the fee is, and who gets released — before any code. Then implement the fare as a list of components summed at the end, with the surge snapshot taken at quote time and stored on the trip.
The repositories below cover the round in pieces: the driver-matching problem is the allocator, the assignment-race problem is the same scenario at full concurrency, the order tracker is the trip state machine, the coupon engine covers promo and fare-discount rules, and the free bank-transfer problem drills the atomic claim pattern in its purest form.
Practice problems in the Ola-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 Matching
The allocator itself: candidate selection, deterministic tie-breaks, assignment, and release on cancel.
Open the challenge →Driver Assignment Race Resolution
Two riders race the same driver: make exactly one win, with ordered locking and no deadlock.
Open the challenge →Order Status Tracker
The trip lifecycle as a state machine: legal transitions, cancellation rules, and status history.
Open the challenge →Coupon Application Engine
Promo mechanics on a fare: eligibility, caps, stacking rules, and redemption that burns once.
Open the challenge →Bank Transfer & Deadlock Prevention
Ordered locking over two entities — the same pattern that stops a double-allocated driver. Free to try.
Open the challenge →FAQ
Were these problems asked at Ola?
No. Every problem is a Gronex original in the style of ride-hailing machine coding rounds — the kind of problem asked in rounds like Ola’s. Gronex is not affiliated with Ola.
Do I need geospatial indexing for the matching problem?
Not in the round. A linear scan with a clear distance function is accepted and expected; mentioning that production would use a geohash or quadtree index is the right amount of scale talk.
How much of the round is concurrency?
The build is often single-threaded, but the double-allocation question is guaranteed. Being able to point at your claim operation and explain why it is atomic is usually enough to pass it.
What is the most commonly missed requirement?
Release on every exit path. Candidates implement the happy cancellation and miss driver rejection or going offline mid-search, leaving drivers permanently marked busy — which the reviewer finds by cancelling twice.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Ola. 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 Ola.