"Two users add the last packet of bread to their cart at the same time. What happens?" He said the second one would get an error at checkout. The interviewer asked how long the first user might sit in their cart before paying. Four minutes, maybe. And in those four minutes, is that bread available to anyone else? He started to say yes, then heard himself, and stopped.
That question — who owns the last unit, and for how long — is the centre of Zepto backend interview questions. Quick commerce runs on small dark stores with genuinely finite stock and a promise measured in minutes, which makes inventory accuracy and latency the two constraints that shape every design round. The loop itself is a familiar Indian product-company shape. I built Greenroom after freezing in an interview I had prepared hard for, so this guide covers each round and how to reason through it aloud.
The Zepto backend engineer interview process
- Recruiter screen — level calibration and org: catalogue, inventory, orders, delivery, pricing or a platform team.
- DSA rounds — one or two at LeetCode medium: graphs, heaps and top-K, intervals, hashing, sliding window.
- Low-level design round — a cart with reservations, an inventory model, or an order state machine.
- System design round — dark-store inventory, delivery-partner assignment, or the ETA promise itself.
- Hiring manager round — ownership, an incident during peak hours, and genuine comfort with fast iteration.
Our Zepto interview questions guide covers the company-wide process and the Zepto data engineer guide covers the analytics side.
The DSA rounds
Medium difficulty, often with a logistics flavour: nearest store to a location, assigning riders to orders, merging delivery time windows, top-K products by demand, shortest path on a road graph.
Practise stating complexity precisely and finishing each problem with a production follow-up spoken aloud — what if this runs on every order, what if the graph updates continuously. Our DSA coding interview preparation guide covers the list.
The low-level design round
Prompts stay close to the product: a cart with time-limited reservations, an inventory model across stores, an order state machine, or a promotions engine.
- Model the reservation explicitly. A unit of stock is available, reserved with an expiry, or sold. The transitions and the timeout are the design.
- State machines declared, not implied. Order lifecycle — created, accepted, picked, packed, out for delivery, delivered, cancelled, refunded — with legal transitions in one place rather than conditionals scattered across services.
- Interfaces for what varies: pricing rules, allocation policy, promotion types.
- Idempotency, because every call in this system gets retried.
- Extensibility live — expect a requirement added halfway.
Our low level design interview questions guide covers the five-step method for this round.
System design: inventory is the hard part
The reservation problem. Answer the opening question properly: adding to cart should either reserve the unit with a short expiry or not reserve at all, and both are defensible — but you must say which and why. Reserving prevents a bad checkout experience and reduces effective availability; not reserving maximises availability and risks failures at payment. The strong answer proposes reserving at checkout initiation rather than at add-to-cart, with a short TTL and explicit release, and names the tradeoff.
Preventing overselling. Atomic decrement with a conditional check, not read-then-write. Say why optimistic concurrency or a database-level constraint is safer than an application-level check, and what happens when the decrement succeeds but the payment then fails — a compensating release, with a timeout so a stuck order does not hold stock forever.
Store-level inventory, not global. Each dark store has its own stock, and the user's location determines which store serves them. Availability is a function of location, which makes the catalogue read path more complicated than a conventional e-commerce one and is worth calling out.
The ETA promise. A ten-minute promise is a prediction, and the design question is what inputs it uses — store load, picker availability, rider availability, distance, traffic, weather — and what happens when it is wrong. Discuss showing a conservative estimate, updating it live, and the business consequence of a missed promise.
Delivery assignment. Matching riders to orders is an assignment problem under time pressure. Discuss batching nearby orders, the tradeoff between waiting to batch and delivering immediately, and why a greedy nearest-rider assignment degrades at peak.
Peak load. Demand is spiky — evenings, weekends, rain. Say what scales, what queues, and what degrades. Rain is a genuinely good example to raise because it increases demand and decreases delivery speed simultaneously.
Consistency per feature. A product listing can be a second stale; a stock decrement cannot. Say which is which. Our distributed systems interview questions and caching strategies guides cover the vocabulary.
Backend fundamentals they probe
- Concurrency and locking — the reservation race, optimistic versus pessimistic, and idempotent retries.
- Databases — index selection for location-based queries, isolation levels, and when to denormalise for the read path. Our DBMS interview questions guide covers it.
- Caching — what is safe to cache when stock changes by the second, and stampede protection at peak.
- Queues — order events, consumer lag during a demand spike, and back-pressure. Our Kafka interview questions guide covers this.
- Geospatial basics — geohashing or similar for "stores near me", which comes up often enough to be worth preparing.
The hiring manager round
Expect an incident during peak, a time you shipped something fast and what you traded away, a disagreement with a product manager, and how you operate with limited information.
Zepto interviews explicitly for comfort with speed, so a story where you shipped a deliberately simple version and iterated is stronger here than one about a six-month perfect build — provided you can say what you knowingly deferred and what you would revisit. Our behavioral interview questions guide covers the structure.
Where each prep option actually helps
- LeetCode — mediums with a logistics framing, each closed out with a production follow-up.
- Designing Data-Intensive Applications — consistency, concurrency and failure vocabulary.
- Low-level design practice — a cart with reservations and an order state machine as real code, extended mid-way.
- Any public writing on quick commerce operations — even shallow reading gives you dark stores, picking time and batching as vocabulary, which very few candidates arrive with.
- ChatGPT — good for generating requirement changes mid-design. It will not ask how long that bread sits in someone's cart.
- Greenroom — the spoken layer. Ari, the AI interviewer runs the design round out loud and pushes on the failure path. Honest tradeoff: Ari will not review your code, so pair it with real practice.
Interviewing across comparable loops? The Swiggy backend engineer guide covers dispatch at larger scale, the Zomato backend engineer guide covers order flow and logistics, and the Meesho backend engineer guide covers commerce under cost constraints.
Frequently asked questions
What is the Zepto backend engineer interview process?
Candidates report a recruiter screen for level and org calibration, one or two DSA rounds at LeetCode medium, a low-level design round on something like a cart with reservations or an order state machine, a system design round covering dark-store inventory, delivery assignment or the ETA promise, and a hiring manager round on ownership and comfort with fast iteration. The structure is standard for an Indian product company; the distinguishing constraint is real-time inventory accuracy.
How do you prevent overselling in a quick commerce system?
Use an atomic conditional decrement rather than reading the stock level and then writing it back, so two concurrent orders cannot both succeed on the last unit. Handle the payment-failure path with a compensating release, and give every reservation a time-to-live with explicit release so a stuck or abandoned order cannot hold stock indefinitely. It is also worth saying that a database-level constraint or optimistic concurrency check is safer than an application-level check.
Should adding an item to the cart reserve stock?
Both answers are defensible and the interviewer wants the tradeoff, not a rule. Reserving at add-to-cart prevents a bad experience at checkout but reduces effective availability, since items sit reserved while users browse. Not reserving maximises availability but risks failures at payment. The strongest common answer is to reserve at checkout initiation rather than at add-to-cart, with a short expiry and an explicit release, and to say why that balance suits a product where stock per store is genuinely small.
What system design questions does Zepto ask?
Prompts centre on dark-store inventory across many small stores where availability depends on the user's location, delivery-partner assignment as a time-pressured matching problem including whether to batch nearby orders, and the ETA promise itself — what inputs predict it, how it updates live, and what happens when it is missed. Peak demand is also a common thread, and raising rain as a scenario that simultaneously increases demand and slows delivery is a strong, specific signal.
What is asked in Zepto's low-level design round?
Prompts stay close to the product: a cart with time-limited reservations, an inventory model across stores, an order state machine, or a promotions engine. You are graded on modelling reservation states and their expiry explicitly, declaring legal order-lifecycle transitions in one place rather than scattering conditionals, defining interfaces for anything that varies such as pricing or allocation, making operations idempotent, and absorbing a requirement added halfway through the round.
What does the Zepto hiring manager round ask?
Expect an incident during peak hours, a time you shipped something fast and what you knowingly traded away, a disagreement with a product manager, and how you operate with incomplete information. Because the company interviews explicitly for comfort with speed, a story about shipping a deliberately simple version and iterating tends to land better than a six-month perfect build — provided you can name what you deferred and what you would revisit.