MakeMyTrip-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Online travel agents own almost nothing they sell. Seats, rooms, and fares belong to suppliers, and the agent’s backend exists to search across them, hold what it can, take payment, and then convert that hold into a real ticket — a sequence with a payment in the middle and a supplier that can say no at the end. Machine coding rounds in the style of MakeMyTrip live in that gap.
The result is a round obsessed with an ugly, realistic failure: money has been captured and the supplier confirmation failed. Around it sit fare caching, multi-passenger bookings, and cancellation policies with time-banded penalties. This page covers the reported format, the evaluation lens, and Gronex repositories with the same mechanics.
What a MakeMyTrip-style machine coding round looks like
A typical build is a booking flow: search across supplier inventory with cached fares, create a booking hold with a short expiry, collect payment, then confirm with the supplier and issue a ticket. The statement usually specifies the hold duration, a fare-change rule (if the supplier fare changed, re-quote rather than silently charge), and a cancellation policy table with penalties by time before departure.
The payment-then-confirmation ordering is the design question. A correct answer treats the booking as a state machine with an intermediate state — held, paid, confirmed, failed-after-payment — and defines a compensating action for the last one: refund automatically, or park it for manual resolution with the money accounted for. Candidates who model booking as a boolean confirmed flag cannot represent the state the business cares most about.
Fare caching then supplies the second trap. A cached fare that is stale must not be charged; the expected behaviour is to re-validate before payment and re-quote if it moved, with a tolerance that the statement sets. The cancellation policy is the extensibility surface — bands with penalties, a non-refundable component, and a partial-cancellation case for one passenger out of four, which tests whether your booking was per-passenger or per-booking.
How you’re evaluated
Hold-then-confirm modelling
An expiring hold, a paid-but-unconfirmed state, and a defined compensating action when supplier confirmation fails after capture.
Fare freshness
Cached fares revalidated before payment with a stated tolerance, and a re-quote path rather than a silent charge.
Policy-driven refunds
Cancellation penalties as a band table applied exactly, with non-refundable components and partial cancellation supported.
Per-passenger granularity
Traveller-level records so one passenger can be cancelled or amended without disturbing the rest of the booking.
Common mistakes that fail this round
- Modelling the booking as confirmed or not, which erases the paid-but-unconfirmed state the whole domain revolves around.
- Charging the cached fare without revalidation, so a supplier price change silently becomes a loss or a dispute.
- Holding supplier inventory with no expiry, which leaks availability on every abandoned checkout.
- Computing refund penalties in floats over a percentage table, then failing the exact-amount assertions.
- Storing passengers as a count, making partial cancellation impossible to express.
Quick tips for the room
- Name the paid-but-unconfirmed state out loud in the first five minutes.
- Give every hold an expiry and a release path used by all exits.
- Revalidate the fare immediately before capture, not after.
- Make passengers records, not a count.
How to prepare
Draw the booking state machine including the failure-after-payment state, then implement it with an explicit compensating action. Next implement the cancellation policy as a band table with a pure function from (booking, cancellation time) to refund amount, in integer paise. Finally make passengers first-class records. Those three decisions answer nearly every probe in this round style.
The repositories below rehearse the same mechanics: the expiring-holds problem is the hold with a timeout, the seat-reservation problem (free) is the claim-and-release baseline, the escrow problem is money held and released around a confirmation step, the wallet problem is refund caps and idempotency, and the TTL-cache extension is fare caching with expiry done correctly.
Practice problems in the MakeMyTrip-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.
Reservation with Expiring Holds
The hold between selection and payment: expiry, release exactly once, and no double-booking under contention.
Open the challenge →Seat Reservation System
Reserve, cancel, and list availability deterministically — the booking baseline. Free to try.
Open the challenge →Escrow Hold & Release
Money held across a confirmation step, released or refunded exactly once, with terminal-state guards.
Open the challenge →Wallet Transaction & Refund System
Refund discipline: cumulative caps, idempotent credits, and a ledger that explains every rupee returned.
Open the challenge →Cache: TTL Expiry & LRU Eviction
Fare caching mechanics: correct TTL expiry, LRU eviction, and no stale reads after invalidation.
Open the challenge →FAQ
Were these problems asked at MakeMyTrip?
No. They are Gronex originals in the style of online travel booking rounds — the kind of problem asked in rounds like MakeMyTrip’s. Gronex is not affiliated with MakeMyTrip.
What should happen when payment succeeds but ticketing fails?
Whatever you say happens, provided the state exists and the money is accounted for. Automatic refund with a recorded reason and a manual-resolution queue are both defensible; silently marking the booking failed while keeping the payment is not.
Do I need to integrate with real supplier APIs?
No. A supplier interface with a fake implementation that can be made to fail is better than a real integration, because it lets you demonstrate the failure path — which is the part being graded.
How detailed should the cancellation policy be?
Implement the table in the statement exactly, as data. Bands by hours before departure with a percentage and a fixed non-refundable component is the common shape, and a pure refund function makes the partial-cancellation follow-up trivial.
Related
Gronex is not affiliated with, endorsed by, or sponsored by MakeMyTrip. 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 MakeMyTrip.