What to Expect in the Zomato System Design Interview

Expect design work inside a technical interview, not on a separate design day. Candidates report design questions in the second technical round, which also covers operating systems, databases, and networking. Reported questions include a rate limiter, a URL shortener, end to end delivery tracking, and Zomato's own restaurant and menu services, while one report describes a geo based problem answered with geohashing and quad trees. Experienced candidates report a further round with a manager that returns to their projects and design decisions.

Is There a Machine Coding Round?

Candidates do not report a separate timed machine coding round at Zomato, meaning a 90 to 120 minute session where you build a small working program and are graded on whether it runs. Several Indian product companies use one, so many candidates arrive expecting it here as well.

At Zomato the same skills are tested inside the technical rounds instead, where candidates report a low level design discussion, a hands-on concurrency coding task, and object design questions. One reported question asks you to build a playlist that plays every song once in random order and also supports a previous song action. The difference between the two round types is explained in system design versus low level design.

The Reported Question Types

Live order tracking. Design the path that moves a delivery partner's location to a waiting customer, where the hard parts are update frequency, battery use on the partner's phone, and an arrival estimate that stays stable.

Restaurant and menu services. Design how menus, prices, and availability are stored and served, where the hard parts are frequent updates, cached copies that go stale, and items that sell out during an order.

Nearby search and geo indexing. One candidate reports a geo based design problem that used geohashing and quad trees. Geohashing turns a latitude and longitude into a short string, so nearby places share a prefix, while a quad tree splits a map into four squares repeatedly, which keeps dense areas small.

Rate limiting and shared infrastructure. Candidates report a rate limiter design question, where a rate limiter caps how many requests a client may send in a period, so expect follow-up questions about counting those requests across many servers.

Classic design questions. Reported examples include a URL shortener and a file storage service, which test the building blocks rather than the food delivery domain.

The Low Level Design Part

Low level design means the classes, their responsibilities, and the interfaces between them. The graded question is whether a new requirement fits without rewriting the existing classes, and candidates report this work in the same round as the broader design discussion. Prepare it as a separate skill, because the common question formats are listed in what a low level design interview involves and they repeat across companies.

A Walkthrough: Live Order Tracking

Here is a high level plan for the signature question.

1. Requirements (5 minutes). Customers see the partner's position and an arrival estimate. Support ordinary meal time peaks, and accept a few seconds of delay, but never show a position that moves backward.

2. Ingesting locations. The partner's app sends a position every few seconds while an order is active, and sends less often when the partner is stationary. Write these updates to a stream rather than straight to a database.

3. Serving the customer. The customer's app subscribes to one order, so push updates over a persistent connection and fall back to polling when that connection fails. Smooth the path on the client so the marker does not jump between readings.

4. The arrival estimate. Compute it from road distance, recent speeds on that route, and the restaurant's own preparation time, then recompute on a fixed schedule and never let a displayed estimate move earlier without a reason.

5. Storage. Keep live positions in an in-memory store keyed by order, write a reduced history to durable storage for support and analysis, and delete the live state once the order completes.

6. Failure and scale. Partition the streams by city, because demand rises at local meal times. Degrade to a slower update rate under pressure rather than dropping orders, and say what the customer sees when tracking fails.

What the Interviewer Grades

State the requirements before you name any component, and name your trade-offs out loud, including the options you rejected and the reason for rejecting them. Connect each choice to a customer consequence, because a wrong arrival estimate produces a support call. Candidates report interviewers who ask repeated follow-up questions, so defend every choice with a reason.

Common Mistakes in This Round

• Ignoring the mobile client. Location tracking runs on a phone with a battery and an unreliable network, so a design that assumes a perfect connection fails immediately.
• Skipping stale data. Menus, prices, and availability all change during an order, so say how the caches are invalidated.
• Treating load as uniform. Traffic concentrates around meal times in each city, so a design built for even load does not solve the real problem.
• Only drawing boxes. The low level design part asks for classes and responsibilities, so bring that level of detail as well.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers the queues, caches, and databases that every one of these questions uses.
• Prepare class design separately. Grokking the Object Oriented Design Interview trains the low level part of this round.
• Rehearse the walkthrough above. Practice the six steps out loud in under 30 minutes, with a timer running.
• See where the round sits. The design interview is one stage of the Zomato interview process, next to the motivation question.
• Plan the calendar too. How long it takes to hear back shows how much time you have between the rounds.