What to Expect in the Zepto System Design Interview

Design is tested in two separate rounds at Zepto, and the first one is about classes and schema. Candidates report a low level design round of about 60 minutes for every level, and senior candidates report a second round of about 60 minutes on system design.

The reported questions come from Zepto's own problems and from the standard design catalog. Reported design questions include a simplified inventory and order assignment system, a ride hailing service, a customer order system, and a calendar application.

The Low Level Design Round Comes First

Low level design means classes, their responsibilities, and the relationships between them. Candidates report about 60 minutes, and some reports include writing working code during the round.

Reported questions include a database schema for a ride hailing service, a chess game with move validation, and a simplified inventory and order assignment system. A coupon creation service and a calendar application also appear in reports. The discussion covers the classes, the design patterns, the database schema, the API design, and whether a new requirement can be added without rewriting.

The difference between this round and the senior design round is explained in system design versus low level design.

The Frontend Machine Coding Round

Frontend candidates report a machine coding round instead of a schema discussion, which is a timed session where you build a small working program from a written requirement.

Reported tasks include a custom hook for local storage, a data fetching hook with loading and error states, polling for updated data, and a tabs component. The grading covers whether the interface works and how cleanly the parts are separated, and one candidate reports that slow work here left no time for the discussion that follows.

The System Design Question Types

Inventory across dark stores. This is the closest question to Zepto's own work, and a simplified version of it is reported in the design round. Stock counts must be correct while many orders compete for the same units, so reservations, locks, and transactions are the main part of the discussion.

Order routing and assignment. Decide which dark store serves an address and then assign a delivery partner, where the difficulty comes from availability, distance, and the handling of a decline or a timeout.

Catalog and search. Products, prices, and availability change all day, each store carries a different set, and the question tests heavy reads against frequent writes.

Rate limiting and traffic peaks. Demand increases sharply during promotions, so expect questions about limits, queues, and graceful degradation.

Standard catalog questions. Reports also include designs for well known products such as a ride hailing service or a calendar, so prepare the classic problems as well as the quick commerce ones.

A Walkthrough: Dark Store Inventory and Order Routing

1. Requirements (5 minutes). State that there are many dark stores, each holding its own stock, that a customer address maps to one serving store, and that the target is a correct order dispatched within a few minutes.

2. The data model. Keep one stock record for each product in each store, with an available count and a reserved count, and store the durable record in a relational database, because the correctness rules need transactions.

3. Store selection. On checkout, find the stores that serve the address, then filter to those holding every item. If no single store holds the full cart, decide openly whether to split the order or to remove an item.

4. Reservation. Reserve stock inside one transaction before payment, using row level locks or a conditional update that fails when the available count is too low. Make the reservation idempotent, so a retried request never holds units twice.

5. Release and correction. Release reserved units when payment fails, when the order is canceled, and when the reservation times out. Store staff also correct counts by hand, so record every change as an event that you can replay later.

6. Dispatch. Publish an order event to a log such as Kafka, because picking, partner assignment, notifications, and analytics all read from that log, so the customer never waits for them.

7. Peaks. Cache catalog reads aggressively, and limit requests for each customer during promotions. Widen the serving radius when the nearest store is out of stock, and degrade the estimated time rather than failing the order.

What the Interviewer Grades

State the requirements before you draw anything, and name the trade-off in each choice out loud, especially between strict correctness and speed.

Connect every decision to the customer result, because an oversold item means a canceled order. Answer the concurrency questions directly, because correctness under many simultaneous orders is the hardest part of this design.

Common Mistakes in This Round

• Treating stock as a simple counter. Reservations, releases, and retries are what the interviewer asks about.
• Ignoring manual corrections. Real stores are counted by people, and the design must handle those corrections.
• Designing for the average rate. A system that works on a quiet afternoon fails during a promotion.
• Skipping the schema in the design round. The low level round is graded on classes and tables, not on boxes and arrows.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, caches, and databases, which every one of these designs uses.
• Practice class design under a timer. Grokking the Object Oriented Design Interview covers the schema and pattern questions reported here.
• Rehearse the walkthrough. Say the seven steps above out loud in under 40 minutes.
• Study the full loop. Check the Zepto interview process, and prepare the motivation question for the later rounds.
• Plan for the gaps between rounds. The reported wait after each round is collected in how long it takes to hear back, so you can keep practicing on a schedule.