Paytm-Style Machine Coding Round: Format, Tips & Practice Problems
A super-app interviews like a super-app: the machine coding round may hand you a wallet one loop and a movie-ticket booking system the next, because the company operates payments, ticketing, commerce, and recurring services under one roof. Rounds in the style of Paytm are therefore less predictable in domain than a pure fintech or pure e-commerce round — and more consistent in what they grade underneath.
That underneath is resource claiming and money correctness. A wallet debit, a seat lock, a sale-price checkout, and a subscription charge are all the same two questions wearing different clothes: can two actors claim the same resource at once, and what happens when this request is retried? This page covers the commonly reported format of Paytm-style rounds, the evaluation criteria, and Gronex repository problems across the same spread of domains.
What a Paytm-style machine coding round looks like
The typical shape is 90–120 minutes, solo, building one working slice from the super-app surface: a wallet service with credits, debits, and refunds; a seat- or slot-booking system with holds and cancellations; a checkout with stacked offers and cashback; or a recurring-charge engine for subscriptions. The statement is precise about rules and quiet about structure — how you layer the service is yours to defend in the follow-up.
Whatever the domain, the money-and-claiming core is graded the same way. Booking scenarios probe the hold: what happens between "seat selected" and "payment confirmed", who else can take that seat, and when does an unpaid hold expire? Wallet and checkout scenarios probe retries and exactness: a double-submitted payment must charge once, offer math must come out to the exact rupee, and a refund can never exceed what was paid. Expect at least one requirement that forces a state machine with an expiring intermediate state.
The demo matters, and so does breadth-readiness: because the domain could be any of several, candidates who prepared one memorised solution struggle. The discussion phase typically extends the scenario across the super-app boundary — add a cashback offer to the booking flow, add a wallet payment to checkout — testing whether your entities were modelled cleanly enough to compose.
How you’re evaluated
Resource claiming done right
Seats, stock, and balances are claimed atomically, holds expire and release, and no two buyers ever own the same unit at the same time.
Exact money math
Offers, cashback, and refunds computed in integer minor units with defined rounding — totals reconcile to the exact rupee under any combination.
Retry and double-submit safety
The double-clicked pay button and the replayed callback charge exactly once; repeated cancellation releases exactly once.
Composable entity modelling
Orders, payments, holds, and offers as clean, separable concepts — because the follow-up will bolt one domain onto another and watch what breaks.
Common mistakes that fail this round
- Confirming a booking at selection time instead of modelling an expiring hold between selection and payment.
- Letting a cancelled or expired hold keep its seat because release lives on only one of three exit paths.
- Computing offer and cashback math in floats, then reverse-engineering a one-rupee discrepancy on stage.
- Charging on every submit because the pay endpoint has no idempotency story for double-clicks and gateway retries.
- Hard-coding the first offer type so "now stack a bank offer with cashback" requires a rewrite mid-round.
Quick tips for the room
- Model the hold as its own state with an expiry from the first minute.
- Put claim-and-decrement in one atomic step; never check then take.
- Keep every rupee in integer paise and round at one defined point.
- Name your entities early — clean nouns are what survive the composition follow-up.
How to prepare
Prepare two katas, not one. First the wallet: ledger entries, idempotent mutations, refund caps — the fintech half. Second the booking hold: claim atomically, hold with expiry, confirm or release on every exit path — the ticketing half. Between them they cover the majority of reported Paytm-style statements, and each transfers to the other’s follow-up questions.
The repositories below span the same breadth: the wallet system is the payments centrepiece, the seat-reservation problem (free) is the ticket-booking hold made concrete, the coupon engine covers checkout offer math, the billing engine covers recurring charges and proration, and the flash-sale problem is the sale-day version of claiming — the last unit under maximum concurrency. Practising across all five rehearses the round’s unpredictability itself.
Practice problems in the Paytm-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.
Wallet Transaction & Refund System
The payments centrepiece: idempotent credits, debits, and refunds over a ledger that always reconciles.
Open the challenge →Seat Reservation System
The ticket-booking round: reserve, hold, confirm, and cancel seats with deterministic availability. Free to try.
Open the challenge →E-Commerce Coupon Application Engine
Checkout offer math: eligibility, stacking, caps, exact rounding, and redemption that never double-burns.
Open the challenge →Subscription Billing & Proration Engine
The recurring-payments flavour: lifecycle states, mid-cycle proration, idempotent invoicing, and dunning.
Open the challenge →Flash Sale Inventory Purchase System
Sale-day claiming: sell exactly the stock you have when thousands race the same item.
Open the challenge →FAQ
Were these problems actually asked at Paytm?
No. Every problem is a Gronex original in the same style — wallet, booking, offer, and recurring-payment mechanics with working-code grading. We never republish any company’s actual interview questions, and Gronex is not affiliated with Paytm.
Which domain should I expect in a Paytm-style round?
Treat it as genuinely uncertain across payments, booking, checkout offers, and recurring charges — that breadth is the round’s character. The good news is the grading core repeats: atomic claiming, expiring holds, exact money math, and retry safety carry every one of these domains.
How should I handle the seat-hold requirement if it appears?
Model the hold explicitly: selection atomically claims the seat into a held state with an expiry; payment confirms it; cancellation, timeout, and failure all release it. The classic failure is releasing on only one of those exit paths — enumerate all of them before coding.
Is a wallet round here different from a bank-style wallet round?
The invariants are identical — no negative balances, idempotent mutations, refund caps. What the super-app context adds is composition: expect the follow-up to connect the wallet to a booking or checkout flow, which is why clean entity boundaries are graded as heavily as correctness.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Paytm. 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 Paytm.