Rapido-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Bike-taxi dispatch differs from cab dispatch in one operationally huge way: supply is enormous, individually unreliable, and answers in seconds. The system does not assign a captain; it offers a ride, waits, and moves on. Machine coding rounds in the style of Rapido are therefore built around the offer-timeout-reassign loop rather than a single allocation decision.
That loop drags in time as a first-class concern and makes the round unusually good at exposing candidates who call the system clock inline. Add incentive and earnings tracking on the captain side, and you have a domain where scheduling, expiry, and idempotent accrual all appear in the same hour. This page covers the format, the evaluation criteria, and Gronex repositories that train it.
What a Rapido-style machine coding round looks like
A representative statement: a ride request fans an offer to the best candidate captain, who has N seconds to accept. On timeout or rejection, offer the next candidate, up to a maximum number of attempts, then fail the request. Track which captains were already offered so none is asked twice for the same ride, and record the reason a request ultimately failed.
Timeout handling is the whole exercise. The clean design is an offer object with an expiry, a scheduler step that the test can advance deterministically, and a single method that resolves an expired offer by moving to the next candidate. The failing design starts a real timer per offer, which is untestable in the round and impossible to reason about when a captain accepts at the same instant the offer expires — a race the interviewer will name explicitly.
The second surface is incentive accrual: complete N rides in a window to earn a bonus, with the window and the counting rule stated. This is an idempotency problem dressed as a growth feature, because the ride-completed event can arrive twice and the bonus must be granted once. Expect a follow-up that changes the incentive rule, checking whether it lived in data.
How you’re evaluated
Offer lifecycle correctness
Exactly one outcome per offer — accepted, rejected, or expired — with a captain never offered the same ride twice.
Deterministic time control
Expiry driven by an injected clock and an explicit tick step, so timeout behaviour is testable and race outcomes are defined.
Reassignment policy
Candidate ordering, attempt limits, and the terminal failure reason all explicit rather than emergent.
Idempotent accrual
Ride-completed events counted once toward incentives, with window rules held as data the follow-up can change.
Common mistakes that fail this round
- Spawning a real timer or thread per offer, which cannot be tested and behaves unpredictably under the accept-at-expiry race.
- Allowing an accept to succeed after the offer expired because the expiry check and the accept were not one operation.
- Re-offering a ride to a captain who already rejected it, because the offered set was never tracked.
- Failing a request with no reason recorded, leaving the demo unable to answer why it failed.
- Counting incentive progress on every received event, so a redelivered completion grants a duplicate bonus.
Quick tips for the room
- Never start a real timer; model expiry as data plus an advanced clock.
- Validate expiry inside accept(), not before calling it.
- Keep the set of already-offered captains on the request object.
- Record a terminal failure reason — demos are judged on explainability.
How to prepare
Build the offer loop with an injected clock and a tick() the test drives, and make accept() validate expiry inside the same guarded operation. Then implement candidate ordering with attempt limits and a recorded failure reason. Finally add an incentive counter keyed on ride id so redelivery is a no-op. This sequence is also the right build order in the room.
The repositories below map to each piece: the driver-matching problem is candidate selection and release, the assignment-race problem is the accept-versus-expiry race at full concurrency, the delayed-and-priority job queue (free) is the deterministic scheduling kata, the SLA problem is clock-driven deadline evaluation, and the loyalty problem is capped, idempotent accrual.
Practice problems in the Rapido-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
Candidate selection and release-on-cancel — the supply side of the offer loop.
Open the challenge →Driver Assignment Race Resolution
Accept versus expiry, and two requests racing one captain: exactly one winner, no deadlock.
Open the challenge →Job Queue: Delayed & Priority
The deterministic scheduling kata behind offer timeouts: due-time dispatch with priority and FIFO ties. Free to try.
Open the challenge →Support Ticket SLA System
Clock-driven deadlines and breach evaluation with an injected clock — time handling done testably.
Open the challenge →Loyalty Points & Tier Management
Incentive accrual mechanics: windowed counting, caps, expiry order, and idempotent earn events.
Open the challenge →FAQ
Are these actual Rapido interview questions?
No. They are Gronex originals in the style of dispatch-heavy mobility rounds — the kind of problem asked in rounds like Rapido’s. Gronex is not affiliated with Rapido.
Why is the offer model better than direct assignment?
Because supply can decline or ignore a request. An offer with an expiry makes rejection, timeout, and reassignment ordinary transitions instead of exceptional cases, and it gives the reviewer something concrete to probe.
How do I handle the accept-at-expiry race?
Decide the rule and enforce it in one place: check expiry against the injected clock inside the accept operation while holding the offer, so an accept either wins cleanly or is rejected as expired. Saying the rule out loud matters as much as the code.
Is the incentive part usually required?
It is a frequent extension rather than the core. Keeping the counting rule in a data structure means you can add it in ten minutes if asked, which is the point of the question.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Rapido. 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 Rapido.