Interview experience
Dunzo Interview Questions and Answers (2026)
Real Dunzo interview questions - candidate interview experiences and HR round prep, kept as a historical reference now that the company has shut down.
Dunzo interview process at a glance (historical)
Section titled “Dunzo interview process at a glance (historical)”| Round | Duration | What they test |
|---|---|---|
| Online Assessment | 90 min | 2-3 coding problems |
| Technical Round 1 | 45-60 min | DSA + project discussion |
| Technical Round 2 | 45-60 min | System design (orders / logistics) |
| HR | 20-30 min | Behavioural + culture fit |
Common HR questions historically asked at Dunzo
Section titled “Common HR questions historically asked at Dunzo”- Tell me about yourself?
- Why Dunzo?
- How would you handle a customer escalation when a delivery partner is stuck and an order is running late?
- Tell me about a time you solved a problem quickly with limited resources or under a tight deadline?
These are kept for historical reference only - Dunzo is not conducting interviews. For live HR-question prep in the same domain, see Blinkit’s HR interview questions or Swiggy’s HR interview questions.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How would you find the shortest route between two points on a city road network?
The standard answer is Dijkstra’s algorithm on a weighted graph whose nodes are intersections and whose edge weights are travel time rather than raw distance, so traffic can be modelled. With a binary heap it runs in O((V + E) log V), and it is correct as long as no edge weight is negative, which holds for travel times. For city-scale graphs, A* with a straight-line-distance heuristic explores far fewer nodes while remaining optimal, because that heuristic never overestimates true travel time; bidirectional search from both origin and destination roughly halves the explored area again. Dunzo’s online assessment historically leaned on route-flavoured graph problems like this - kept here as archive, since the company shut down in January 2025.
Q: How would you batch several delivery orders onto one rider?
Batching is a vehicle-routing problem, which is NP-hard, so production systems use heuristics rather than exact solutions. A practical approach is to cluster nearby pickups and drop-offs geographically, order the stops within a batch using a nearest-neighbour or cheapest-insertion heuristic, then improve the sequence with 2-opt local search. Every candidate batch is scored against the promised delivery window: the batch is rejected if adding a stop pushes any order past its SLA, and a pickup must always precede its own drop-off. Real systems also cap batch size and re-evaluate as new orders arrive rather than solving once. Archive reference only.
Q: How would you find the nearest available delivery partners to a pickup point?
Scanning every partner’s latitude and longitude is O(n) per lookup and does not scale, so use a spatial index. Geohash encodes a location as a short string where a shared prefix means geographic proximity, so you can fetch candidates with a prefix query in a key-value store, then also check the eight neighbouring cells so you do not miss a partner just across a cell boundary. Uber’s H3 hexagonal grid solves the same problem with uniform neighbour distances, and a quadtree adapts cell size to partner density. Redis geospatial commands such as GEOADD and GEOSEARCH give this out of the box, backed by a sorted set of geohash scores. Filter the candidate set by availability and current load, then rank by estimated travel time.
Q: How would you design real-time order tracking for the customer app?
The rider app emits a location ping every few seconds over a persistent connection, written to a low-latency store such as Redis keyed by order id rather than to the primary database, since the value is overwritten constantly and stale pings have little value. Customers receive updates over a WebSocket where a live connection is worth the cost, with short polling as a cheaper fallback on poor networks. Location history worth keeping for audit or ETA modelling goes to a queue and then a time-series or object store asynchronously. ETA is recomputed on the server from the current position and remaining route rather than on the client, so every surface agrees. Historical reference - Dunzo no longer operates.
Q: Why does an order service need an idempotency key, and how does the order state machine work?
Mobile clients on flaky networks retry requests, so the same place-order call can arrive twice. An idempotency key is a client-generated unique id stored with the order; the server checks it before creating anything and returns the original result on a repeat, so a retry never creates a duplicate order or a duplicate payment capture. The order itself is best modelled as an explicit state machine - created, accepted, picked up, in transit, delivered, cancelled - where only legal transitions are permitted and each transition is written in a transaction alongside its side effect. That makes an illegal jump, such as delivered back to accepted, impossible, and makes crash recovery a matter of resuming from the last persisted state.
Q: How do you rate limit an API, and which algorithm would you pick during a demand surge?
The token bucket algorithm is the usual choice: tokens refill at a fixed rate up to a bucket capacity, each request consumes one, and a request arriving with no token is rejected with HTTP 429. It allows short bursts up to the bucket size while capping the sustained rate, which suits real user traffic better than a fixed window - a fixed window lets roughly double the limit through at a window boundary. Sliding window log is more accurate but stores a timestamp per request, so sliding window counter is the common compromise. In a distributed setup the counters live in Redis with atomic increments so every API instance shares one limit, and limits are usually keyed per user or per API key rather than per IP.
Frequently asked questions about Dunzo
Section titled “Frequently asked questions about Dunzo”Is Dunzo still hiring? Is Dunzo shut down?
No - Dunzo has completely shut down. The app and website went offline in January 2025 following the departure of cofounder and CEO Kabeer Biswas (who joined Flipkart), after 12-18 months of steep decline. Reliance Retail, which had invested roughly $200 million in Dunzo in January 2022, wrote off its entire stake - one of the largest individual startup write-offs in India’s history. There are no revival plans as of 2025-2026, so there is no current Dunzo hiring process to prepare for.
What was the Dunzo interview process like when it was operating?
Historically, Dunzo’s fresher SDE process ran 4-5 stages: an Online Assessment (90 min, 2-3 coding problems, often route-optimization/logistics-flavoured), one or two Technical Interviews (DSA plus a system-design round scoped to delivery/logistics - real-time tracking, route optimization), a Managerial round, and an HR round. This is kept here as a historical/archival reference, not as live prep material, since the company no longer operates.
Why did Dunzo fail?
Dunzo pivoted into quick commerce in 2021 and ended up competing against much better-capitalised rivals - Blinkit, Zepto, and Swiggy Instamart - who could sustain far greater dark-store density. Dunzo was unable to raise the funding needed to keep pace, accumulated unpaid vendor and employee obligations, and lost three of its four cofounders before shutting down entirely in January 2025.
Should I still apply to or prepare for Dunzo?
No - Dunzo is not accepting applications or conducting interviews, since the company has shut down. If you’re preparing for quick-commerce/hyperlocal-delivery interviews generally, the still-operating players in that space (Blinkit, Zepto, Swiggy Instamart) are the more useful targets - see the Blinkit and Swiggy pages on this site for current, live interview processes with the same domain flavour (routing, inventory sync, delivery SLAs).