Delhivery-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
A parcel network is an event-sourced system whether or not anyone designed it that way. Every physical action — picked up, bagged, in transit, arrived at hub, out for delivery, undelivered, returned — is a scan, and the shipment’s state is whatever those scans add up to. Machine coding rounds in the style of Delhivery are built on that stream, and they are noticeably harder than they look.
The difficulty is that scans arrive late, twice, and out of order, from devices that were offline in a truck for two hours. A tracking system that applies each scan as it arrives will happily move a delivered parcel back to in-transit. This page covers the commonly reported format, the evaluation lens, and Gronex repositories that train the same event-application discipline.
What a Delhivery-style machine coding round looks like
Typical statements ask for a shipment tracking service that ingests scan events and exposes current status and history, or a routing component that computes the hub path for a shipment given a network of lanes with costs and cut-off times. The tracking version is the more common and the more instructive, because the statement always says, somewhere, that events may be duplicated or delayed.
The correct mental model is last-write-wins by event time with a monotonic status guard, not by arrival order. Each scan carries a device timestamp; applying an older scan must not regress the status, applying a duplicate must not append a second history entry, and applying a scan that is newer but illegal — delivered after returned — must be rejected and recorded as an exception rather than silently dropped. Rounds in this style test all three within minutes of the demo starting.
The routing variant is a graph problem with operational constraints: lanes between hubs with transit times, cut-offs that determine whether today’s truck is catchable, and a service-level target. What is graded is not Dijkstra but the modelling — that a lane has a departure schedule, that missing a cut-off adds a day, and that unreachable destinations produce a clear failure rather than an exception. Expect a follow-up adding a capacity constraint or a prohibited lane.
How you’re evaluated
Event-time application
Status decided by event timestamp with a monotonic guard, so late scans never regress a shipment.
Duplicate immunity
The same scan id applied repeatedly leaves one history entry and one status, however many times it arrives.
Illegal-transition handling
Impossible sequences rejected and recorded as exceptions, with the shipment left in a defensible state.
Route modelling with cut-offs
Lanes with schedules and transit times, cut-off arithmetic that adds a day when missed, and explicit unreachable results.
Common mistakes that fail this round
- Applying scans in arrival order, so a delayed in-transit scan overwrites a delivered status.
- Appending to history without deduplicating on scan id, producing a tracking page with repeated rows.
- Silently ignoring illegal transitions instead of surfacing them, which hides real operational problems.
- Computing routes on a graph that has no notion of departure times, so every cut-off question is unanswerable.
- Modelling NDR and RTO as flags rather than states, which makes re-attempt counting and terminal returns ambiguous.
Quick tips for the room
- Decide status by event time, never by arrival order.
- Deduplicate on scan id before touching state or history.
- Reject illegal transitions loudly and record them as exceptions.
- Put schedules and cut-offs on lanes; a plain edge weight is not enough.
How to prepare
Build the scan applier as a pure function of (current state, event) with three rejection reasons — duplicate, stale, illegal — and test each. Then add the NDR and RTO states with a re-attempt limit, because undelivered flows are where logistics rounds like to go once the happy path works. If the statement is the routing variant, put schedules on lanes from the first line.
The repositories below rehearse the mechanics: the out-of-order event problem is stale application made concrete, the order tracker is the transition table, the DLQ replay problem is what a re-sent batch of old scans does to current state, the task dependency problem is the graph modelling muscle, and the free duplicate-effects problem is deduplication at its cleanest.
Practice problems in the Delhivery-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.
Stale Inventory After Reordered Events
The late-scan failure exactly: an older event overwriting newer state, and the version guard that stops it.
Open the challenge →Order Status Tracker
The transition table as a repository problem: legal moves only, cancellation rules, full status history.
Open the challenge →Replayed Updates Roll State Back
What happens when a batch of old scans is replayed into a live stream, and how to make replay safe.
Open the challenge →Task Dependency Manager
Graph modelling with real constraints: dependency ordering, cycle detection, and deterministic traversal.
Open the challenge →Duplicate Effects After a Restart
Deduplication at its cleanest: at-least-once delivery, exactly one effect. Free to try.
Open the challenge →FAQ
Were these problems asked at Delhivery?
No. They are Gronex originals in the style of logistics-network rounds — the kind of problem asked in rounds like Delhivery’s. Gronex is not affiliated with Delhivery.
Why does event ordering matter more here than elsewhere?
Because the events come from handheld devices in vehicles with intermittent connectivity, so late and duplicated scans are the normal case rather than an edge case. Any design that trusts arrival order is wrong before it is written.
Should I implement a shortest-path algorithm?
Only if routing is the statement, and even then the algorithm is the easy half. The graded part is whether your lanes carry departure schedules and transit times so cut-off behaviour is expressible.
What are NDR and RTO, and do I need them?
Undelivered attempts and return-to-origin. They appear as extension requirements often enough that modelling them as real states with a re-attempt limit, rather than boolean flags, is worth the five minutes it costs.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Delhivery. 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 Delhivery.