What to Expect in the PhonePe System Design Interview

PhonePe tests design twice, in two different rounds. The first is a machine coding round of about 90 minutes, where you write a small working program and then explain it to an interviewer for about 15 to 30 minutes. The second is a system design round of about 60 minutes for mid and senior candidates.

Reported design questions include a flight aggregator, a question and answer platform, and a crawler and query service for a search engine. Prepare both rounds separately, because one is graded on code that runs and the other on the discussion.

The Machine Coding Round Comes First

This is the round that candidates from IT services companies are least prepared for. You receive a problem statement and a fixed time, reported as about 90 minutes and in some cases up to two hours.

You then write a console program with no user interface and no database, using in-memory data structures. An interviewer then reviews your code with you for about 15 to 30 minutes. Some reports describe the coding part as a take-home task rather than a live session, so confirm the format with your recruiter.

Reported problems include a snake and ladder game, a multilevel cache with least frequently used eviction, a task list with analytics for overdue and completed tasks, and a backend for product search with sponsored results. Candidates also report a vehicle rental service and a booking system.

The grading is consistent across reports: your program must compile and run on sample input, and your classes must separate duties clearly. A new requirement, such as another player type or another kind of obstacle, must fit without rewriting existing classes.

Write a small main method that demonstrates the features, because a demo is expected, and add test cases for the sample input, which several reports mention. For the general shape of these questions, see the machine coding round explained.

The Question Types in the Design Round

Aggregation systems. One candidate reports a flight aggregator that collects data from many airlines and supports search and booking, which tests external API calls, caching, stale data, and booking consistency.

Content platforms. One candidate reports a question and answer platform, first for internal use and later open to other organizations, which tests search, authorization, and communication between services.

Crawling and indexing. One candidate reports a search engine with a separate crawler service and query service, which tests queues, deduplication, and index design.

Distributed processing. One report places an open design question in the hiring manager round, for a compute cluster with job monitoring and health metrics.

Payments topics. PhonePe's own work is payments, so idempotency, ledgers, and reconciliation are worth preparing, though candidate reports do not confirm a named UPI design question. Treat payments as background knowledge rather than as a predicted question.

A Walkthrough: The Flight Aggregator

Here is a high level plan for the reported aggregator question.

1. Requirements, about 5 minutes. Users search by route and date, see live prices, and book a seat, while many airlines supply that data through slow and unreliable APIs.

2. Search path. Query the airline APIs for uncached routes and serve popular routes from a cache, with a short expiry because prices change often. Return partial results when one airline is slow, and label them as partial.

3. Storage. Keep static data, such as airports and schedules, in a relational database, search results in a fast cache, and bookings in a transactional store.

4. Booking path. Reserve the seat with the airline, confirm payment, then record the booking, and use an idempotency key so that a retried request never books twice. Idempotency means that the same request applied twice has the same result as applying it once.

5. Failures. Handle a timeout that occurs after the airline has already charged the customer, and add a reconciliation job that compares your bookings against airline records and repairs differences.

6. Scale. Shard by route or by airline, and add rate limits for each airline API. Queue booking confirmations so that one slow partner does not delay search traffic.

What the Interviewer Grades

Requirements come first, and candidates who begin by drawing boxes lose credit, so name your trade-offs plainly, especially consistency against latency. One report describes an interviewer pushing back when a candidate proposed a single relational database and could not scale beyond replication, so prepare sharding and partitioning answers. Failure handling is graded heavily, because payments and bookings must survive partial failures.

Common Mistakes in This Round

• Treating machine coding as an algorithm round. The grade is class design and working code, not asymptotic cleverness about the algorithm you chose.
• Skipping the demo. Code that cannot be run during the review discussion scores poorly, however clean it looks on the screen.
• Ignoring duplicate requests. In any money or booking flow, retries are certain, so mention idempotency before the interviewer asks about it.
• No reconciliation story. Systems that move money need a way to detect differences between records and repair them.
• Designing for a fixed scale. State your assumptions, then say what changes when volume grows ten times.

How to Prepare

• Build small systems under a timer. Grokking the Object Oriented Design Interview covers the class design that machine coding grades.
• Learn the building blocks. Grokking the System Design Interview covers caches, queues, sharding, and consistency.
• Rehearse the aggregator walkthrough. Practice the six steps above out loud in under 40 minutes.
• Place the round in the loop. The design round is one stage of the PhonePe interview process, which also asks the motivation question, and the reported waits between rounds are described in how long it takes to hear back.