PhonePe SDE (Android) 2025: Nearly Failed Round 1, Then Cleared 5 Rounds to Offer

TL;DR. 1.5 years at InMobi-Glance, a ShareChat offer already in hand, and a DSA round that went so badly the candidate was "almost certain" he would not hear back. He did hear back. Four more rounds later, the last one a bar-raiser with min-heap and string pattern problems, PhonePe called the same evening with the offer. Five rounds total: DSA, Android platform, machine coding (build an e-commerce app in 90 minutes), hiring manager (design a map-based app from scratch), and a bar-raiser that tested whether the DSA stumble in Round 1 was a fluke or a ceiling. Source post linked at the bottom.

This is not a generic "PhonePe interview preparation guide." This is one specific 2025 candidate's specific 5-round loop for the Android SDE role, with the actual graph problem that nearly ended his chances, the actual machine coding task, and the actual bar-raiser questions that sealed the deal. If you think a weak opening round means the loop is over, this post says otherwise.

Who interviewed

Shubham Singh was not a fresher walking into PhonePe blind. He had 1.5 years of production Android work at InMobi-Glance, one of the stronger Android-first companies in Bangalore, and a competing ShareChat offer that gave him a fallback. The PhonePe loop was a deliberate bet for a better role, not a spray-and-pray job search.

The notable detail: he almost lost the bet in Round 1.

Round 1: DSA, the near-failure

"Loud and Rich" is LeetCode 851. You are given a directed graph of people where an edge from person A to person B means A has more money than B. For each person, find the quietest person who has equal or more money. The standard approach is topological sort with propagation: compute the ordering, then for each person in reverse topological order, propagate the quietest ancestor downward.

Jump Game II (LeetCode 45) is the classic greedy BFS on array indices: from index 0, find the minimum number of jumps to reach the last index, where each index tells you the maximum jump distance.

Both are medium-difficulty by LeetCode standards, but "Loud and Rich" is graph-heavy, and the candidate's own assessment was that he did not perform well. He left the round certain he would be rejected. In his words, he "was almost certain I wouldn't hear back."

What this reveals about PhonePe's calibration: PhonePe's bar for advancing from Round 1 is not a perfect score. It is a demonstration that you can reason through graph problems and arrive at a correct (or near-correct) approach, even if the execution is messy. The candidate advanced despite his own doubts, which means the interviewer saw enough signal in the approach, the articulation of the graph traversal, and the Jump Game greedy solution to push forward.

If you are in a PhonePe DSA round and feel it went badly, do not assume it is over. Complete every problem to the best of your ability, articulate your thought process out loud, and wait for the actual verdict.

Round 2: Android Platform Knowledge

This round is unique to Android SDE roles at PhonePe. It does not exist in the backend or full-stack loops. The interviewer tests whether you actually understand the platform you will be building on, not just algorithms.

The topics reported in this loop:

ViewModel: How does ViewModel survive configuration changes? What happens when the Activity is destroyed and recreated? How does ViewModelProvider scope the ViewModel to the Activity vs. the Fragment? What is the difference between viewModels() and activityViewModels() in Kotlin extensions?

Fragments: Fragment lifecycle vs. Activity lifecycle. Fragment transactions, the back stack, and why commitAllowingStateLoss() exists. The FragmentFactory pattern for dependency injection in Fragments.

Services: Foreground services vs. bound services. When does a foreground service get killed? What are the notification requirements for foreground services post-Android 12?

Jetpack Compose: Recomposition triggers, remember vs. rememberSaveable, side effects (LaunchedEffect, DisposableEffect), and how Compose interoperates with the existing View system.

For backend engineers reading this: PhonePe treats Android as a systems problem, not a UI problem. The platform round is closer to an OS internals discussion than a "build a RecyclerView" exercise. If you are interviewing for PhonePe Android, you need to know the lifecycle state machine as precisely as you know your graph algorithms.

Round 3: Machine Coding, 90 minutes

The machine coding round is the most PhonePe-specific round in the Android loop. You are not whiteboarding. You are opening Android Studio and building a working app in 90 minutes. The app must have 4 to 5 core features (product listing, cart, checkout flow, search, and at minimum one form of data persistence or backend sync), proper screen navigation, and a clean architecture.

Shubham used MVVM with Clean Architecture, which is the safest bet for PhonePe Android machine coding. The interviewer expects:

1. Separation of concerns: UI layer (Composables or XML), domain layer (use cases), data layer (repository pattern). If your Activity is making direct network calls, you have already lost points.
2. Navigation: Jetpack Navigation Component or equivalent. Manual Fragment transactions without a navigation graph will cost you time.
3. Backend sync: Retrofit + Coroutines is the standard. The interviewer does not care if the backend is real; they care if your network layer is decoupled from the UI layer.
4. Testability: If your architecture makes it easy to write unit tests (even if you do not write them in the 90 minutes), the interviewer notices.

The 90-minute clock is aggressive. Most candidates who fail this round fail because they spend 30 minutes on architecture without writing code, then rush the features. The candidate completed all requirements, which means he allocated time correctly: architecture scaffold in the first 15 minutes, then feature implementation for the remaining 75.

Round 4: Hiring Manager

The hiring manager round at PhonePe is not purely behavioral. It starts with a system design problem that tests whether you can think about a product end-to-end, then transitions into behavioral questions about leadership, conflict resolution, and decision-making.

The design problem in this loop was: design a map-based app from scratch. This is broader than the typical "design Google Maps" system design question. The "from scratch" framing means the interviewer wants you to start with product requirements (what does the user need?), then move to architecture (client-server split, offline support, caching strategy for map tiles), and then scalability (how do you serve map data to 100 million users without latency spikes?).

For Android SDE candidates specifically, the interviewer also probes the mobile-specific constraints: battery consumption from continuous location polling, how the app behaves when network connectivity drops, progressive loading of map tiles, and how you handle permissions for location services across different Android versions.

The behavioral portion covers standard hiring manager territory: why PhonePe, what was a technically difficult decision you made and how did you resolve it, how do you handle disagreements with teammates, and what is a project where you took ownership of something outside your immediate scope.

Round 5: Bar-Raiser, the closer

PhonePe's bar-raiser round is an additional DSA round that serves as a calibration check. It exists because the DSA signal from Round 1 alone is sometimes ambiguous (as it was in Shubham's case, where Round 1 was shaky). The bar-raiser gives the hiring committee a second data point.

The two problems:

Min-heap problem. The exact statement is not disclosed in the source, but min-heap problems at PhonePe's difficulty band typically involve one of: merge K sorted lists using a min-heap, find the Kth smallest element in a sorted matrix, or a task scheduler with cooldown intervals using a max-heap (inverted problem). The technique is always the same: maintain a heap of size K, process elements in priority order, and handle the extraction and re-insertion logic cleanly.

String patterns problem. Again, the exact statement is not in the source. At the SDE level, string pattern problems at PhonePe typically involve one of: KMP or Rabin-Karp for substring matching, regular expression matching with DP, or wildcard pattern matching. The technique depends on the constraint: if the pattern has fixed characters plus wildcards, DP is standard; if the pattern is a full regex, finite automaton simulation is sometimes needed.

Shubham solved both problems cleanly. The offer call came the same evening, which means the hiring committee had enough positive signal from Rounds 2 through 5 to override the weak Round 1. The bar-raiser did its job: it confirmed that Round 1 was a bad day, not a skill gap.

How to prep for PhonePe's 5-round Android loop

1. DSA is not optional. "Loud and Rich" is a legitimate graph problem, not a warm-up. PhonePe's DSA difficulty for Android is at parity with backend roles. Do not assume the Android loop is softer on algorithms.

2. Know your platform cold. The Android platform round is the differentiator. If you cannot explain ViewModel scoping, Fragment lifecycle edge cases, and Compose recomposition triggers from memory, you will fail this round regardless of your DSA performance.

3. Practice timed machine coding. 90 minutes for a full app with navigation, network layer, and architecture is tight. Do at least 3 practice runs before the interview: set a timer, build an app from scratch, and see what you can ship in 90 minutes. If you are consistently finishing at 100+ minutes, simplify your architecture.

4. The bar-raiser exists because Round 1 is noisy. If you bomb Round 1, do not mentally check out. The committee can override a weak DSA round if the rest of the loop is strong. Conversely, if you ace Round 1 but stumble in subsequent rounds, the bar-raiser will not save you.

5. System design at the HM level means product thinking. The map app question is not about distributed systems. It is about product constraints, mobile-specific trade-offs, and whether you can think beyond the code to the user experience. Prepare 2 to 3 mobile system design problems (map app, messaging app, payment app) and practice articulating the product requirements first, architecture second.

Source post

PapersAdda's verification standard requires a publicly accessible post URL, per-round detail from the candidate, and a stated outcome. This post meets all three. Shubham Singh published his full 5-round experience on Medium in July 2025, including the near-failure in Round 1, the machine coding task, and the bar-raiser problems. The ShareChat competing offer is mentioned in the article, providing additional context for the candidate's position during the loop.

Source: Shubham Singh, "I Almost Failed the First Round. Here's How I Cracked PhonePe's Toughest SDE Interview," Medium, July 6, 2025

Also on PapersAdda

• Uber SDE-2 L4 India 2025: Job Scheduler Machine Coding to 6-Round Offer, another 6-round loop with machine coding and bar-raiser at a product company
• Flipkart SDE-2 Bangalore 2024: Wallet Machine Coding to Offer, machine coding as the opening round, followed by DSA hards
• CRED SDE-2 Bangalore 2024: Payment Processor Machine Coding to Offer, another fintech machine coding round with payment-domain problems
• PhonePe SDE-2 October 2025: Shazam HLD, Over-Engineered, Rejected, the same company, different role, opposite outcome

A note on sourcing: details on this page are candidate-reported and assembled from public preparation resources, so exact numbers shift between drives. Always verify the live notification on the official site before you apply or make a decision.