Dream11-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Fantasy sports concentrates an enormous amount of traffic into the minutes before a match starts and the minutes after it ends. Before the deadline, millions of users build teams and join contests with finite capacity; after it, a scoring pipeline turns match events into points, ranks, and money. Machine coding rounds in the style of Dream11 take their scenarios from both spikes.
The domain supplies unusually crisp rules: a team has a credit budget, per-position minimums and maximums, and a cap on players from one side; a contest has a size and an entry fee; a prize structure must distribute exactly the prize pool, including when several users tie. This page covers the reported format, the evaluation lens, and Gronex repositories with the same mechanics.
What a Dream11-style machine coding round looks like
A common build is team validation plus contest joining: validate a team against the composition rules, join a contest atomically against its remaining capacity while debiting the entry fee, and handle the deadline after which no join or edit is allowed. The scoring variant instead ingests match events, applies a points scheme, and produces a ranked leaderboard with prize allocation.
Join is the concurrency core, and it is a two-resource atomic operation: a contest seat and the user’s wallet balance. Both must succeed or neither, and a contest must never exceed its size even when thousands of joins arrive simultaneously. Reviewers probe the last seat, a failed debit after a seat was taken, and a join arriving one millisecond after the deadline — all three of which have to be single guarded operations rather than sequences.
The scoring half is an idempotency problem. Match events arrive from a feed, can be corrected and redelivered, and points must be recomputable rather than accumulated — because a correction after the leaderboard was published is normal. Prize distribution then needs exactness: a tie for second place splits the combined prizes of the tied ranks, and the total distributed must equal the pool to the paisa, which forces a stated remainder rule.
How you’re evaluated
Rule-complete team validation
Credit budget, position bounds, and per-team caps evaluated together, returning every violation rather than the first.
Atomic two-resource join
Contest seat and entry-fee debit committed together, with the last seat never oversold and the deadline enforced in the same operation.
Recomputable scoring
Points derived from stored match events so a correction or redelivery converges instead of double-counting.
Exact prize distribution
Ties splitting combined prizes with a declared remainder rule, and the total distributed equalling the pool exactly.
Common mistakes that fail this round
- Validating composition rules in sequence and returning the first failure, so the user fixes one problem at a time.
- Taking the contest seat and debiting the wallet as two steps with no compensation between them.
- Accumulating points per event, which makes a corrected event impossible to undo.
- Distributing prizes by dividing and rounding per winner, leaving the pool short or over by a few paise.
- Checking the deadline before the join rather than inside it, admitting entries after lock.
Quick tips for the room
- Return all validation violations at once; users and reviewers both prefer it.
- Make join one atomic operation over seat plus balance plus deadline.
- Recompute points from events; never accumulate into a total.
- Declare the remainder rule for tie splits and assert the pool sums exactly.
How to prepare
Write the validator to collect all violations, then implement join as one atomic operation over seat and balance with the deadline checked inside it. Then build scoring as a recomputation from stored events and prize distribution as a function with an explicit remainder rule. Test a three-way tie; it is the case that exposes rounding bugs instantly.
The repositories below map the round: the flash-sale problem is the contest-capacity race, the escrow problem is entry-fee handling with release, the free bank-transfer problem is the atomic two-resource pattern, the exam grading engine is scoring and ranking with tie-breaks, and the webhook problem is the corrected-and-redelivered feed.
Practice problems in the Dream11-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.
Flash Sale Inventory Purchase
Contest capacity under a spike: allocate exactly the seats that exist when thousands join at once.
Open the challenge →Escrow Hold & Release
Entry fees held and released exactly once, with terminal-state guards and reconcilable balances.
Open the challenge →Bank Transfer & Deadlock Prevention
The atomic two-resource pattern with ordered locking — the join operation in its purest form. Free to try.
Open the challenge →Scoring & Ranking Engine
Scoring rules, deterministic ranking, and full tie-breaks — the leaderboard core.
Open the challenge →Event Idempotency & Ordering
Match-feed reality: duplicate and out-of-order events that must not double-count or regress state.
Open the challenge →FAQ
Were these problems asked at Dream11?
No. They are Gronex originals in the style of fantasy-sports rounds — the kind of problem asked in rounds like Dream11’s. Gronex is not affiliated with Dream11.
Why is joining a contest harder than it looks?
Because it touches two scarce resources at once — a seat and money — with a hard deadline. Any implementation that treats them as three sequential checks can be broken by an interleaving the reviewer will construct.
How should prize ties be handled?
Sum the prizes of the tied ranks and split them with a declared rule for the remainder — for example distribute the leftover paise to the earliest entrants. The requirement is that the pool sums exactly; the specific rule just has to be stated.
Is the scale part of the round?
In discussion, yes. Naming the hot spots — the contest seat counter and the leaderboard — and describing sharded counters or periodic recomputation is the expected depth. Building any of it inside the clock is not.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Dream11. 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 Dream11.