What Is the Flipkart Android System Design Interview Like?

Candidates report two separate rounds for Android roles at Flipkart. A timed machine coding round comes first, where you write a small app that compiles and runs. A client focused design round follows, and the backend is described as already built.

Public interview write ups describe the machine coding round as about 90 minutes. The design round is open ended. You turn product requirements into a client design.

Quick Overview

The order and the count vary by level and by team. Treat this table as the common shape candidates report. It is not a fixed script.

The Machine Coding Round

Machine coding is a timed session where you build a small working application. Your code must compile and run when time ends. Candidates report a window of about 90 minutes here.

Graders look for working code first. A partial app that runs scores better than a full app that does not. After that they read your class boundaries.

Split the work into four layers. UI, presentation, domain, and data. The UI layer never calls the network directly.

Handle the states a real screen has. Loading, empty, error, and retry. Leave code you can explain line by line.

Candidates describe this round as a gate. A weak result here usually ends the process. The design round is described in What Is the Android System Design Interview Like?.

App Size Is the First Constraint

Flipkart sells into a market where storage and mobile data are scarce. Many shoppers use low end phones with little free space. A large app loses installs and gets removed first.

So app size is a design topic, not a build setting. Expect the interviewer to ask what your feature adds to the download. Have a number and a method ready.

Android App Bundle is the publishing format. You upload one bundle. Google Play then builds a smaller file per device, carrying only the screen density, language, and CPU architecture that phone needs.

Play Feature Delivery splits an app into modules. A module can install with the app, install on a condition, or install on demand. On demand means the module downloads when the user first opens that feature.

Name the cost of that choice. An on demand module can fail to download on a weak network. So the design needs a loading state, a retry, and a path back to a basic screen.

R8 removes unused code and shortens names. Resource shrinking removes unused resources. Both run at build time, and both need testing, because code loaded by reflection can break.

Images are usually the largest part of a shopping app. Use WebP or AVIF instead of PNG. Ask the server for the exact pixel size the view needs, per screen density.

Then say what you would measure after shipping. Track download size per device class. Track module install success rate, and uninstall rate on phones with low free storage.

Server Driven UI and the Home Page

The Flipkart home page changes constantly. Sale events change it many times a day. A design that needs an app release for every change is wrong here.

So the server sends a list of widgets. The client keeps a registry of widget types and renders the ones it knows. This is called server driven UI.

The part that decides your grade is the unknown widget type. Old app versions will receive widgets they cannot draw. Skip those quietly and never crash.

Flipkart open sourced Proteus, a JSON based layout inflater for Android. It builds layouts at runtime instead of from compiled XML files. The code is public on GitHub, so you can read it before your interview.

Cart, Search, and Sale Traffic

Make the local database the source of truth. The network is only a sync source. Offline behaviour then follows from the design instead of being added later.

Queue pending writes with client generated IDs. An item added to the cart with no network is not lost. It is also not added twice when the retry succeeds.

Use cursor pagination for search results. Page numbers break when new items arrive while the user scrolls. Cursors do not.

For typeahead search, delay the request after each keystroke and cancel the previous one. Cache recent queries on the device.

Sale events change client behaviour too. Retry with growing delays and random jitter, so millions of apps do not retry at once. Respect any wait hint the server returns.

Plan the release as part of the design. An app version cannot be rolled back like a server deploy. So use feature flags, a staged rollout, and a way to switch the feature off.

How to Prepare

• Prepare the design round. Grokking Modern Mobile System Design Interview covers app size, server driven UI, cursor pagination, and cart durability as worked case studies.
• Build two small apps against the clock. Set 90 minutes. Fetch a list, show it, sort it, handle errors, and load images. Repeat until the structure is automatic.
• Practise the five step design method. Requirements, then API and data model, then client layers, then the hardest part in detail, then failure and rollout. How Do You Prepare for a Mobile System Design Interview? walks through it.
• Study the question families first. What Questions Are Asked in a Mobile System Design Interview? lists both app features and library questions.
• Use server side material as background only. Grokking System Design Fundamentals teaches caching, queues, and storage on the server, which is useful background for the API half.
• Keep algorithm practice running. The problem solving round is separate, and Grokking the Coding Interview covers the patterns it draws from.
• Read the wider set of question types. Our mobile system design interview questions post collects them in one place.
• Compare the two closest processes. Swiggy and Zomato run a similar pair of rounds.