Blinkit-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Ten-minute delivery is a serviceability question before it is an inventory question: for this pin code, right now, which store serves it, is that store open, does it have staff, and can it take another order without breaking its promise? Machine coding rounds in the style of Blinkit often start there rather than at the cart, which makes them noticeably different from a checkout-centric commerce round.
Once an order is accepted, the interesting work is batching: turning orders into picker tasks that group by aisle, respect the promise time, and never assign the same task twice. This page covers the commonly reported format, the evaluation lens, and Gronex repositories that train the same dispatch and availability mechanics.
What a Blinkit-style machine coding round looks like
A representative statement asks for a serviceability-and-acceptance service: map a pin code to candidate stores, filter by open hours and current load, compute a promise time, and accept or reject the order with a reason. The follow-up half is picker assignment: convert accepted orders into tasks, batch them by zone or aisle, and dispatch to the next available picker with an exactly-once claim.
Load-based rejection is the concept the round is really probing, and candidates often resist it. A store with a queue longer than its capacity must either extend its promise or refuse the order, and the statement will state which. This means acceptance is a policy evaluated against live load, not a formality — and the policy must produce a specific reason, because "not serviceable" is not an acceptable answer to a customer or a reviewer.
Task claiming brings the exactly-once requirement. Two pickers polling simultaneously must not receive the same task; a task abandoned mid-pick must return to the pool exactly once, and a task must not be lost if a picker goes offline. The strong answer is a claim with an owner and a lease that expires, which is the same pattern as a distributed scheduler — and rounds in this style ask about scale-out precisely there.
How you’re evaluated
Serviceability as policy
Store selection filtered by area, hours, and live load, producing an accept-or-reject decision with a named reason and a promise time.
Exactly-once task claiming
Concurrent pickers never receive the same task; abandonment returns it to the pool once, with an expiring lease as the mechanism.
Deterministic batching
Grouping and ordering rules — zone, promise time, priority — encoded in one comparator with explicit tie-breaks.
Availability truth
Per-store stock with reservation semantics, so an accepted order is one the store can actually fulfil.
Common mistakes that fail this round
- Accepting every order because acceptance was treated as validation rather than a capacity policy.
- Returning a generic rejection with no reason, which makes the demo unexplainable.
- Handing tasks out with a read-then-mark pattern, so two pickers get the same task.
- Losing abandoned tasks because release existed only on the explicit-abandon path and not on lease expiry.
- Batching by map iteration order, which makes the picker’s route change run to run for identical input.
Quick tips for the room
- Make acceptance return a reason object, never a bare boolean.
- Claim tasks with an owner plus a lease expiry, not a busy flag.
- Put every batching rule in one comparator and test its ties.
- Derive promise time from live load so the policy is visible in the demo.
How to prepare
Write the acceptance policy as a list of checks that each return a reason, and make the promise time a function of current load. Then implement task claiming with an owner and an expiring lease, and prove with a test that two claimants get different tasks and that an expired lease returns one to the pool. That pair is what this round is built to examine.
The repositories below map the mechanics: the distributed scheduler is exactly-once claiming with leases, the free job-queue extension is due-time and priority dispatch, the stock reservation problem is per-store availability, the flash-sale problem is the last-unit race, and the visibility-timeout problem is the lease-expiry failure seen in production form.
Practice problems in the Blinkit-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.
Distributed Job Scheduler
Exactly-once claiming when many workers race the same task, with leases and safe reclamation.
Open the challenge →Job Queue: Delayed & Priority
The dispatch kata: due-time gating, priority ordering, FIFO tie-breaks, fully deterministic. Free to try.
Open the challenge →Inventory Stock Reservation System
Per-store availability truth: reserve, release, and commit without corrupting on-hand counts.
Open the challenge →Flash Sale Inventory Purchase
The last-unit race at full concurrency: sell exactly what the store has, never one more.
Open the challenge →Two Workers Take The Same Task
Lease expiry gone wrong: why a slow handler causes duplicate work, and how to size and renew the lease.
Open the challenge →FAQ
Were these problems asked at Blinkit?
No. They are Gronex originals in the style of quick-commerce rounds — the kind of problem asked in rounds like Blinkit’s. Gronex is not affiliated with Blinkit.
Why is order rejection part of the design?
Because a ten-minute promise is only credible if the system can decline work it cannot do. Treating acceptance as a capacity policy with reasons is the single clearest signal that you understood the domain rather than the CRUD.
What is a lease and why use one?
A claim with an expiry. It makes a crashed or disconnected picker recoverable without anyone intervening: when the lease lapses, the task returns to the pool exactly once. A plain busy flag cannot do that.
How does this differ from other quick-commerce rounds?
Inventory-centred quick-commerce rounds focus on reservation correctness at the dark store. A serviceability-centred round puts store selection, load-based acceptance, and picker batching first — same domain, different graded surface.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Blinkit. 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 Blinkit.