What Is the Swiggy Android System Design Interview Like?
Candidates report a machine coding round early in the Swiggy Android process. One report describes a two hour session: call an API, show the results in a list, and add sorting. A client focused design round and an Android depth round follow.
The design round asks you to design one feature of a food delivery app. The server side is described as already built. Your job is the client.
Quick Overview
| Stage | Format | What is evaluated |
|---|---|---|
| Machine coding | Candidates report a timed session, one report says two hours | A running app, layers, error handling, image loading |
| Code review | The interviewer reads your code with you | Why each line exists, what you would change |
| Android depth | Discussion | ViewModel state, fragments, coroutines, lifecycle |
| Client design | Open ended design conversation | Requirements, layers, offline behaviour, failure |
| Managerial | Discussion | Ownership, scope, working with other teams |
Round names and counts differ across reports and levels. Use this as the common shape, not a promise.
The Machine Coding Round
Machine coding is a timed session where you write code that compiles and runs. The output is a small working application, not a design document. Candidates describe it as a gate before the later rounds.
One reported task was a list screen fed by an API, with sorting. Others describe optional extras, such as dependency injection or paging. Finish the required part before touching an optional one.
Candidates report that the interviewer watches quietly, then reads the code with you. They ask why each line is there. So write code you can defend, not code you copied by habit.
Reported follow up questions stay close to Android basics. How a ViewModel keeps state across a configuration change. Why fragments use a newInstance method.
Live Order Tracking Is the Design Question
Food delivery gives the interviewer one very good question. The user has placed an order and is watching it arrive. Keep that screen correct while the phone is locked, on a weak network, and with a limited battery.
Start with what the screen must show. Order state, a map position, and an arrival estimate. Each one updates at a different rate, so do not treat them as one stream.
Order state changes a handful of times per order. Position changes every few seconds. So a single fast polling loop wastes battery and data.
Say how updates reach the app in each state. Hold a connection open while the screen is visible. Use a push message when the app is in the background, and a fetch when the app opens.
Then say why the app still fetches on open. Push delivery is not guaranteed. A message can be delayed or dropped, so the screen must be able to rebuild its own state.
Android limits background work, and that limit is the interesting part. Doze mode and app standby restrict what a backgrounded app may do. WorkManager schedules deferrable work and survives process death.
An ongoing user visible task is different. Android expects that work to run as a foreground service with a notification the user can see. Say which one your feature needs and why.
Cover the reconnect path. The connection drops in a lift or a basement. On reconnect, ask for state since the last known update rather than replaying everything.
Menus, Stock, and the Cart
A menu is large, read often, and changes without warning. Cache it on the device and show the cached copy at once. Then revalidate with the server using a version or an entity tag.
Handle the gap between what the user saw and what is true now. An item can sell out between render and tap. So revalidate the cart at checkout and show a clear message naming the item that changed.
Restaurant availability behaves the same way. A closed restaurant must not accept an order. Let the server decide, and design the screen for the moment it says no.
Rendering Speed Is a Graded Topic
Swiggy published a performance case study with Google. Engineering write ups describe work on jank, which is a skipped frame the user sees as stutter. The reported focus was the path from home to menu to cart.
The published numbers are large. Slow cold starts fell by about half. Slow frames fell by about 59 percent, and bounce rate fell by about 28 percent.
The listed tools are worth naming in your round. Perfetto and gfxinfo for frame timing. Android vitals in Play Console for the released app.
The client techniques matter more than the tools. Decode images to the size of the view, because a full size photo can use tens of megabytes. Cancel image requests when a row scrolls away.
How to Prepare
- Prepare the design round. Grokking Modern Mobile System Design Interview covers live order tracking, background execution, and menu caching as worked case studies.
- Practise a timed list screen. Two hours, one API, a list, sorting, images, errors, and retry. Then explain every class out loud.
- Write the background rules down. Doze, WorkManager, foreground services, and push. What Is the Android System Design Interview Like? covers how these appear in a design round.
- Rehearse one tracking design end to end. How Do You Prepare for a Mobile System Design Interview? gives the step order and a time budget.
- Learn the server vocabulary for background. Grokking System Design Fundamentals explains queues, caching, and consistency on the server, which is useful background for the tracking half.
- Practise explaining a design out loud. Mock interviews are useful because this round is a conversation, not a document.
- Compare the neighbouring processes. Flipkart and Zomato run a similar pair of rounds.
GET YOUR FREE
Coding Questions Catalog
$99
$197
$72
