What Is the Zomato Android System Design Interview Like?
Candidates report a coding exercise and a client design round for Android roles at Zomato. Reports differ on whether the coding exercise is a separate timed machine coding round or part of a technical round. One report describes implementing functions in an existing codebase that render image bitmaps across threads.
The design round is described as designing a small feature of the Zomato app. Android internals come up throughout. Expect follow up questions on why a mechanism works, not only on which class to use.
Quick Overview
| Stage | Format | What is evaluated |
|---|---|---|
| Android and coding | Reports vary: a timed exercise or a technical discussion with code | Working code, threading, correctness, clarity |
| Data structures | Medium difficulty questions | Approach, complexity, edge cases |
| Client design | Design one feature of the app | Layers, offline behaviour, memory, failure |
| Hiring manager | Discussion | Scope, expectations, ownership |
Reports differ more here than for other companies. Ask your recruiter for the round list. Treat the table as a starting point.
The Coding Exercise
One public report describes an existing codebase and three functions to implement. The subject was decoding and rendering image bitmaps concurrently. The graded points were correctness, efficiency, and readable code.
That subject is not random. A bitmap is an image decoded into memory, and it is large. A photo that is a few hundred kilobytes on disk can use tens of megabytes once decoded.
So talk about threading and memory together. Decode away from the main thread. Decode to the size of the view, never at full size.
Then talk about cancellation. A list scrolls fast, and rows are reused. Cancel the request for a row that has scrolled away, or the wrong image appears in the wrong row.
Add the two caches. A memory cache for the current screen and a disk cache for repeat visits. Say how each one is bounded and what is removed first.
App Size and Startup Are Public Topics Here
Zomato has written publicly about app size and speed. That makes both fair material for your round. It also means vague answers stand out.
Engineering blog posts describe converting images to WebP wherever it was smaller. They describe publishing as an app bundle, which cut download sizes for users by around a fifth. They also describe asking the server for the exact image size a device needs, which depends on screen density.
Bring the delivery mechanism into the answer. Android App Bundle lets Google Play build a smaller file per device. Play Feature Delivery can hold a rarely used feature out of the first install and download it on demand.
Name the cost as well. An on demand module can fail to download on a weak connection. So the design needs a retry and a usable screen while the download is missing.
The published speed work is just as usable. A case study with Google reports about 30 percent faster startup on low and mid range devices. It reports removing legacy SDKs and unused libraries as the largest single gain.
Two more reported techniques are easy to reuse in a design answer. Initialise libraries when first needed rather than at launch. Use a view stub so a rarely shown layout is only built when it is required.
The reported business effect is why interviewers care. The case study links faster startup to a large improvement in first day retention. Speed is a product decision, not only an engineering one.
The Design Round Shape
Zomato is discovery, reviews, and ordering in one app. That gives the interviewer three different design questions. Ask which one before you draw anything.
A discovery feed is an image heavy scrolling list. Use cursor pagination, because new restaurants appear while the user scrolls. Make the local database the source of truth and treat the network as a sync source.
A review or a photo upload is a write. Queue it with a client generated ID, so a tap made offline is not lost and is not applied twice. Show the user the pending state and any failure.
Order tracking is the third. Push is not guaranteed delivery, so the app must also fetch when it opens. Background work is limited by Doze, so say which work is deferrable and which needs a visible foreground service.
Close on shipping. An app release cannot be rolled back like a server deploy. So feature flags, a staged rollout, and a way to turn the feature off belong in the design.
How to Prepare
- Prepare the design round. Grokking Modern Mobile System Design Interview covers startup time, app size, memory, and live tracking as worked case studies.
- Write an image loader by hand once. Threading, decoding to the view size, cancellation, memory cache, disk cache. This one exercise covers most of what is reported here.
- Read Zomato's public engineering posts. Their app size and startup posts give you concrete numbers to reason with in the round.
- Learn the five step design order. How Do You Prepare for a Mobile System Design Interview? sets out the steps and a time budget.
- Know how this round differs from the server one. Mobile vs Backend System Design Interview: What Changes? makes the split clear.
- Use server side courses for background. Grokking the System Design Interview teaches the server half of a delivery product, which is useful background for the API half.
- Compare the two closest processes. Flipkart and Swiggy both run a machine coding round before the design round.

GET YOUR FREE
Coding Questions Catalog

$99

$197

$72