What to Expect in the Meesho System Design Interview

Design at Meesho is tested in two different rounds. The first is a machine coding round, where you build a small working program in about 60 to 120 minutes. The second is a high level design round, which experienced candidates report far more often than junior candidates do.

Machine coding is graded on code that actually runs, while the design round is graded on the quality of the discussion. Both rounds use Meesho's own problems: catalog, orders, payments, and delivery.

The Machine Coding Round Comes First

A machine coding round gives you a written requirement and a time limit, and it asks for a working program that is usually a console application, with no user interface and no database needed. Candidates report problems such as a car pooling system, a parking lot system, and two features of a ride-sharing application.

Some candidates also report low-level design questions modeled on Uber, and reports name HackerEarth and HackerRank as the platforms used for these sessions.

Spend the first 10 to 15 minutes on clarifying questions, which several candidates recommend. Agree on the scope out loud before you type, then build the smallest complete version and extend it only if time remains. This round differs from a design discussion, as explained in the difference between system design and LLD.

What the Machine Coding Grader Checks

Four things decide this round, and the first is that the program must run and produce correct output for the stated cases. Second, the classes must match the domain, with responsibilities that are clear enough to name in one phrase.

Third, a new requirement should be easy to add without a rewrite, and fourth, you must explain your choices afterward. Unfinished but clean code scores better than a large submission that does not compile. For the general shape of this round, see what a machine coding round is.

The High Level Design Round

Experienced candidates report a design round built on Meesho's own systems, and the reported themes include the product catalog and search, order management, and payment flows. Related topics follow naturally: caching, database sharding, and traffic spikes during sale events. Sharding means splitting one logical database across many machines by a key, and you should expect questions about what happens when one of those machines fails.

A Worked Example: Order Management

Here is a high level plan for an order system at marketplace scale, in the order that an interviewer expects to hear it.

1. Requirements (5 minutes). Assume millions of low-value orders per day, from many sellers to many buyers, with delivery handled by partner networks. Traffic increases sharply during sale events, and correctness matters more than speed wherever a payment is involved.

2. The order state machine. An order moves through created, payment pending, confirmed, packed, shipped, delivered, returned, and refunded, so model these states explicitly and reject any transition that the rules do not allow.

3. Write path. The order service writes the order record and then publishes an event, and a queue carries that event to inventory, payments, seller notification, and delivery, which keeps the buyer-facing write fast and short.

4. Idempotency. Payment callbacks and delivery updates arrive more than once, and idempotency means that repeating a request does not change the result a second time. Give every request a key, store the keys, and ignore the repeats.

5. Storage and sharding. Shard orders by buyer identifier for buyer queries, and keep a separate read model for seller queries, built from the same events. Then move the older orders to cheaper storage on a fixed schedule.

6. Sale event traffic. Queue the work that is not urgent, such as notifications and analytics, and protect the database with caches for catalog reads. Add rate limits, and reduce service in steps rather than failing completely.

7. Cost. State the money cost of your choices, because a zero commission marketplace earns little per order. A design that triples the storage cost therefore needs a reason that you can defend.

What the Interviewer Grades

Give the requirements first, then a simple design, and then the trade-offs between the options you considered. Name the failure cases before the interviewer asks about them, and say what you would measure in production, such as failed payments and stuck orders.

Candidates report interviewers who ask for more depth, so defend each choice with a reason. A generic social network answer scores poorly here, because the domain is commerce.

Common Mistakes in These Rounds

• Coding before clarifying. In machine coding, silence for the first ten minutes usually produces the wrong program, because the written requirement is rarely complete enough to code from directly.
• Over-designing the small program. Applying many design patterns in one hour usually produces unfinished code, so build the simple version that runs.
• Ignoring returns and refunds. Returns are a large part of Indian e-commerce, and an order design that omits them is incomplete.
• Skipping idempotency. Payment and delivery events arrive more than once, so a design without repeat handling has a serious weakness.
• Forgetting sale events. Steady traffic is the easy case, and the interview is usually about the spike that a sale event creates.

How to Prepare

• Practice building under a timer. Write a parking lot or car pooling program end to end in 90 minutes, then extend it with one new requirement.
• Learn class design properly. Grokking the Object Oriented Design Interview covers the structure that this round grades.
• Study the building blocks. Grokking the System Design Interview covers queues, caches, sharding, and replication.
• Place the round in the loop. See where design sits in the Meesho interview process, and prepare the motivation question with how to answer why Meesho.
• Know the waits. Plan your other applications using how long it takes to hear back after a Meesho interview.