PhonePe SDE-2 October 2025: Cleared LLD and DSA, Then the Shazam HLD Killed the Loop

TL;DR. Backend engineer with production experience on large-scale payment systems. Applied to PhonePe SDE-2 multiple times via LinkedIn and the career site before getting scheduled. Cleared the LLD round (1.5-hour implementation plus a 30-minute follow-up on concurrency and thread safety). Cleared the DSA round (Word Search in a Grid plus a multi-word search follow-up). Then came the HLD round: design a system similar to Shazam, audio recognition without any ML model. The candidate used hashing plus sliding window to generate 1-second audio fingerprints, designed APIs and database schema, covered scalability. Technically sound, the interviewer said. But the candidate over-engineered the write flow without first clarifying requirements, and the rejection came before the hiring manager round ever happened. Source linked at the bottom.

This is not an article about how PhonePe interviews are unfair. The candidate himself identifies the failure mode: he started designing before asking what the system actually needed to do. That one procedural error cost him the entire loop. If you are preparing for HLD rounds at any Indian product company in 2025, the lesson here is worth more than a list of 50 system design questions.

The candidate

Arpit Chauhan was not a first-time applicant. He had applied to PhonePe multiple times through both LinkedIn and the careers page before getting an interview slot. This detail matters because it tells you that PhonePe's inbound application funnel is heavily gated. A single rejected application does not mean your profile is permanently out; it means the recruiter did not pick your resume from that particular batch. Persistent reapplication, especially after upgrading your profile with new projects or a promotion, can eventually break through.

The candidate's background in payment systems is directly relevant to PhonePe's domain. He was not stretching to fit the job description. He was a domain match who lost on interview technique, not on capability.

Round 1: Low-Level Design (2 hours total)

PhonePe's LLD round for SDE-2 is split into two parts. Part one is a take-home-style implementation task, although it is done live under observation. The candidate has 1.5 hours to build a working solution to a design problem, package it as a ZIP file, and submit. Part two is a 30-minute follow-up call with a Senior SDE who reviews the code, asks about design decisions, and probes concurrency and thread-safety concerns.

The specific problem statement from this loop is not disclosed in the source, but the follow-up topics reveal the calibration: concurrency and thread safety are the primary evaluation axes. A correct solution with single-threaded logic will not score as well as a solution that anticipates multi-threaded access, uses proper synchronization, and can articulate why a particular concurrency strategy was chosen.

Common patterns in PhonePe's LLD rounds at the SDE-2 level include: in-memory caches with eviction policies and thread-safe access, payment state machines with concurrent transaction handling, rate limiters with sliding window counters, and event-driven notification systems.

The 30-minute follow-up is where the interviewer separates candidates who wrote correct code from candidates who understand their code. Questions typically include: what happens if two threads call this method simultaneously? How would you handle a deadlock in this structure? Why did you choose a ConcurrentHashMap over a synchronized HashMap? What design pattern is this, and what are its trade-offs?

Arpit cleared this round, which means his implementation was solid and his concurrency reasoning passed the bar.

Round 2: DSA (1 hour)

The first problem is LeetCode 79 (Word Search): given an m x n grid of characters and a string, determine if the word exists in the grid by traversing adjacent cells (up, down, left, right) without reusing the same cell. Standard approach: DFS/backtracking from every cell that matches the first character, marking visited cells, and unwinding on failure.

The follow-up escalates the problem: instead of searching for one word, search for multiple words simultaneously. This is LeetCode 212 (Word Search II), and the standard approach shifts from simple backtracking to a Trie-based solution. You build a Trie from the word list, then run DFS from each cell, traversing the Trie in parallel with the grid traversal. The Trie prunes the search space: if no word in the Trie starts with the current prefix, you backtrack immediately.

The interviewer asked for explicit time and space complexity analysis for both variants. For the single-word version, the complexity is O(m * n * 3^L) where L is the word length (3 because you cannot revisit the cell you came from, so at most 3 directions per step). For the multi-word Trie version, the complexity depends on the total number of characters in the word list and the grid dimensions.

Arpit passed this round, confirming that his DSA fundamentals were at the SDE-2 bar.

Round 3: HLD, the Shazam problem, and the failure

This is the round that ended the loop. The problem: design a system like Shazam that can identify a song from an audio clip, but without using any machine learning model.

The "without ML" constraint forces the design toward audio fingerprinting. The standard approach is:

1. Fingerprint generation: Divide the audio into small windows (1 to 5 seconds). For each window, compute a spectrogram, identify peaks in the frequency domain, and hash the peak constellation into a compact fingerprint.
2. Storage: Store fingerprints in a database keyed by hash value, with metadata pointing to the song ID and the time offset within the song.
3. Matching: When a query audio clip arrives, generate fingerprints from the clip, look up each fingerprint hash in the database, and use time-offset alignment to determine which song has the most consistent matches.

Arpit's approach was technically correct. He used hashing plus a sliding window to generate 1-second audio signatures, designed APIs for ingestion and query, laid out the database schema, and discussed scalability.

Where it went wrong: He over-engineered the write flow (the ingestion pipeline for adding new songs to the database) without first asking the interviewer what the system's primary use case was. In a real Shazam-like system, the write path (adding songs) is infrequent and batch-oriented, while the read path (identifying songs from clips) is latency-sensitive and high-throughput. By spending significant time optimizing the write flow, Arpit allocated design effort to the wrong dimension of the problem.

The interviewer's feedback was specific: the design was technically sound, but the candidate "lacked requirement clarification." He assumed the system needed a high-throughput write pipeline when the interviewer wanted a discussion focused on the read path, matching latency, and how to handle noisy audio clips.

This is the failure mode that kills more HLD rounds than any technical gap: designing before understanding the problem. The candidate did not ask: How many songs are in the catalog? How often are new songs added? What is the acceptable latency for a match query? What happens when the audio clip is noisy or partial? These questions determine where the design effort should go. Without them, you are optimizing blind.

What the Shazam problem reveals about HLD rounds

The Shazam problem is unusually creative for an Indian product company HLD round. Most SDE-2 HLD questions draw from a standard set: URL shortener, chat system, notification service, news feed, rate limiter. Shazam breaks the mold because it requires domain-specific knowledge (audio processing, frequency analysis) that most candidates have never studied.

PhonePe's choice of this problem serves two purposes:

1. It tests reasoning under uncertainty. If you have never designed an audio recognition system, can you still break the problem into ingestion, storage, and retrieval, and make reasonable assumptions about each component?
2. It forces requirement clarification. The problem is ambiguous enough that you cannot start designing without asking questions. A URL shortener has well-known constraints. A Shazam clone does not. The interviewer is watching whether you ask "what are the constraints?" or whether you start drawing boxes.

If you encounter an unfamiliar HLD problem, the first 5 minutes should be entirely questions: what is the scale (users, data volume)? What is the latency SLA? What are the access patterns (read-heavy, write-heavy, mixed)? What is the data model (structured, semi-structured, blob)? Only after you have these answers should you propose an architecture.

Arpit's reflection on this failure is instructive: "Clarify requirements before designing." Five words that would have changed the outcome.

The rejection and the missing Round 4

PhonePe's SDE-2 loop has four rounds: LLD, DSA, HLD, and Hiring Manager. The hiring manager round is the final checkpoint and covers behavioral questions, project discussion, and a lighter system design problem.

Arpit never reached Round 4. The HLD rejection was terminal. This is standard at PhonePe: each round is pass/fail, and a failure at any point ends the process. There is no "let's see how the HM round goes" buffer if the HLD feedback is negative.

The implication for candidates: every round matters equally. You cannot bank on a strong LLD and DSA to offset a weak HLD. PhonePe's committee evaluates each round independently, and a single fail results in a reject regardless of the other rounds' scores.

Reading the rejection correctly

1. Over-engineering is a failure mode, not a strength. At the SDE-2 level, the interviewer does not want you to design the most complex system possible. They want you to design the right system for the stated constraints. If you do not know the constraints, ask.

2. Multiple applications can work. Arpit applied to PhonePe multiple times before getting an interview. The rejection of one application does not blacklist your profile. Reapply after meaningful profile changes (new project, promotion, stronger LinkedIn).

3. LLD and DSA clears do not guarantee an offer. PhonePe's loop is pass/fail per round. Two strong rounds plus one weak round equals rejection. There is no averaging.

4. Audio fingerprinting is a real HLD topic now. If you are interviewing at PhonePe, Spotify, JioSaavn, or any media-adjacent product company, prepare at least one HLD problem in the audio/video domain. The standard playbook of URL shortener, chat system, and notification service is not enough.

5. The first 5 minutes of any HLD round should be questions. If you start drawing architecture before asking about scale, latency, and access patterns, you are making the same mistake Arpit made. The interviewer has a mental model of the system. Your job is to discover that model through questions, not to impose your own.

Where this comes from

PapersAdda's verification standard requires a publicly accessible post, per-round detail, and a stated outcome. This post meets all three. Arpit Chauhan published his full 3-round experience on Medium in October 2025, including the LLD follow-up topics, the Word Search problem and its multi-word follow-up, the Shazam HLD problem, and the specific feedback about over-engineering. The failure analysis is the candidate's own, not our interpretation.

Source: Arpit Chauhan, "My PhonePe Interview Experience: A Journey of Learning and Reflection," Medium, October 12, 2025

Read next on PapersAdda

• PhonePe SDE (Android) 2025: Nearly Failed Round 1, Then 5 Rounds to Offer, same company, different role and level, the opposite outcome
• Uber SDE-1 India 2025: All OA Solved, Rejected at Google Sheets LLD, another rejection driven by a design communication gap, not a technical gap
• Flipkart SDE-2 Bangalore 2024: Wallet Machine Coding to Offer, a machine coding round at a different product company for comparison
• CRED SDE-2 Bangalore 2024: Payment Processor Machine Coding to Offer, another fintech interview loop with a different outcome

Sourcing and accuracy: the figures here are candidate-reported estimates, not official numbers. Confirm on the official portal before you make decisions, since vacancy counts, cut-offs, and patterns vary by cycle and by role.