PhonePe Onsite Interview: Every Round, What It Tests, and How to Prepare
- Machine coding (LLD) round is the first technical filter for SDE2+ — 90-120 minutes of writing and defending production-quality code, not whiteboarding
- DSA round runs 60-90 minutes with medium-to-hard problems; always state brute force before the optimal solution or lose the thinking signal
- System design round (SDE2+) penalizes candidates who design before clarifying requirements — one documented failure mode is scaling the wrong flow
- Hiring manager round scores on specifics — name latency numbers, team size, error rate reductions, not vibes
- Top rejection reasons: skipping tests in machine coding, jumping to optimal without brute force, and vague behavioral result sections
Most candidates preparing for a PhonePe onsite picture the usual setup: two DSA rounds back to back, maybe a system design, then you go home. That's approximately half the picture. The machine coding round is a genuine filter, not a warm-up, and for SDE2+ candidates it comes before the DSA round. Walk in expecting back-to-back LeetCode mediums and nothing else and you will be surprised. Unpleasantly.
What the Loop Looks Like
The number of rounds depends on your level.
SDE1 and new grad roles run three rounds: two DSA rounds and a hiring manager conversation. SDE2 and experienced hires (two to five years) get four rounds, adding a machine coding round and a high-level system design round.
| Round | Duration | Focus | Level |
|---|---|---|---|
| Machine Coding / LLD | 90-120 min | OOP, design patterns, clean code | SDE2+ |
| DSA | 60-90 min | Algorithms, graphs, DP | All |
| High-Level Design | 60 min | System architecture, trade-offs | SDE2+ |
| Hiring Manager | 45-60 min | Behavioral, past projects | All |
The machine coding round is what most candidates underestimate. You're not sketching a design on a whiteboard. You're writing production-quality code and then defending it under live questioning.
Round 1: Machine Coding (SDE2+)
This round runs 90-120 minutes. The problem statement is loose on purpose. You're expected to turn it into clean, working, testable code.
Problems candidates have seen: a multilevel cache with LFU eviction, a vehicle rental management system, a BookMyShow-style seat booking platform, and a Snake and Ladders game with dynamic obstacle support. In some formats you submit a ZIP of your code; in others you share a screen.
Most candidates feel relieved when the code compiles and the tests pass. That's when the actual interview starts. The debrief is where most offers are won or lost. A senior engineer walks through your design and asks about concurrency, thread safety, why you chose a particular data structure, and how the design scales under load. The code is table stakes. Explaining and defending the design is where offers get decided.
What PhonePe specifically evaluates:
- SOLID principles. A design that violates single responsibility or hardcodes dependencies gets flagged.
- Layer separation. Entity, service, and repository layers should be distinct.
- Test coverage. Candidates who implement only the happy path and skip edge case tests consistently report rejections.
- Naming and readability. PhonePe reviewers mention this explicitly. A teammate should be able to read your code without asking you what anything means.
The odds that your skipped edge case never triggers in production are low. But never zero. PhonePe interviewers know this too.
A common time management mistake: spending 100 of your 120 minutes on core logic, feeling very good about yourself, and leaving nothing for tests or cleanup. Aim for roughly 50% core logic, 20% modularization, and 30% tests and edge cases. This split feels wrong the first few times you practice. That's how you know it's right.
If you haven't practiced LRU and LFU cache implementation recently, do that now. The multilevel cache problem directly tests that knowledge. The LRU cache implementation pattern comes up repeatedly in PhonePe machine coding rounds.
Round 2: DSA
This round runs 60-90 minutes with two to three problems. For SDE1 candidates it's the primary technical filter. For SDE2+, it's the second hurdle after machine coding.
Difficulty sits at medium-to-hard LeetCode. Graphs, trees, binary search, and dynamic programming appear most often. Problems candidates have reported: word search in a 2D grid and multi-word variants, next greater element, finding tree roots that minimize overall height, binary search on the answer for arrival time minimization, and prefix-sum log analysis identifying peak usage windows.
The standard format is brute force first, then optimize. PhonePe interviewers explicitly ask for the naive approach before the optimal one. Jumping straight to optimal skips the part of the conversation the interviewer uses to assess your thinking. Every time you skip straight to the fancy solution, somewhere an interviewer writes "jumped to answer without demonstrating understanding." Don't be that candidate.
State time and space complexity for every solution, not just the final version. Being able to say "the brute force is O(n²) because we check every pair; the hash map approach is O(n) because we reduce that to a single pass" is expected at every step. Code must compile and run. Recent candidates have used CodeSignal or a shared online editor.
Round 3: High-Level System Design (SDE2+)
This round runs 60 minutes. The problems have a genuinely hard core.
Problems seen at PhonePe: a Shazam-like audio identification system (no ML allowed), a Quora-style Q&A forum, a flight aggregator pulling inventory from multiple airlines, and a parking lot with vehicle routing. Audio fingerprinting under high query load. Feed generation at scale. Inventory freshness across external APIs. Each one has a specific hard part you need to name before you start designing.
Some companies have relaxed interviews. PhonePe wants you to design Shazam from scratch, without machine learning, under 60 minutes.
Designing before you understand requirements is the documented failure mode. One candidate built a highly scalable write flow for the audio fingerprinting problem before asking what the actual write volume was. The interviewer's feedback: over-engineered before requirements were clear. That's a polite way of saying they built a distributed system to serve three users. This pattern shows up across PhonePe system design reports with remarkable consistency.
How to use the 60 minutes:
- Five to ten minutes on requirements. Functional questions first, then non-functional ones. What's the read-to-write ratio? Does this need to be real-time? What consistency guarantees matter?
- A rough capacity estimate before drawing boxes. Simple math tells you whether Postgres is fine or whether you need a distributed store.
- Name the hard problem before designing for it. For the flight aggregator, it's keeping airline inventory fresh under high read traffic. For Quora, it's feed generation and search. Design around the hard part first.
- SQL versus NoSQL trade-offs should be explicit. PhonePe interviewers expect you to justify the choice, not just pick one.
- Microservices boundaries are a discussion point. How you cut the system and why is as important as what you build.
For the four-stage system design framework, see the system design interview prep guide.
Round 4: Hiring Manager
This round runs 45-60 minutes. It covers behavioral questions, project depth, and whether you're someone the team actually wants to work with. For SDE1 candidates it sometimes includes a light schema design question.
PhonePe doesn't publish formal leadership principles the way Amazon does, but the themes across candidate reports are consistent:
- Ownership under ambiguity. Walk through a project where requirements changed after work started. What did you do and what was the measurable outcome?
- Depth on past work. Interviewers pick a line on your resume and probe it. Numbers are expected: team size, request volume, latency impact, error rate reduction.
- Why PhonePe. Every interviewer at every fintech company hears "fintech is exciting." The expected answer connects your background to a specific product area or engineering challenge at PhonePe, not fintech in general. Pick something specific. The interviewer knows what their own company does.
- Disagreement and resolution. How did you handle a technical disagreement with a teammate or manager? What was the process and what was the outcome?
The result section carries the most weight. "The project went well" is not a result. "Query latency dropped from 800ms to 120ms after we moved to read replicas" is a result. You want the interviewer writing something specific in their notes, because the hiring committee reads the write-up, not the vibe.
For a full breakdown of how interviewers score behavioral answers, see technical interview communication.
How to Prepare for the PhonePe Onsite Interview
For SDE1 and new grad (three rounds): Spend roughly 70% of prep on DSA. Prioritize graphs (BFS, DFS, topological sort), binary search on the answer, and DP patterns covering 1D and 2D problems. Practice narrating brute force before optimal on every problem. Spend the remaining 30% preparing two to three strong behavioral stories covering ownership, conflict, and a time you learned something the hard way.
For SDE2+ (four rounds): Split prep roughly 35% DSA, 40% machine coding, and 25% system design.
For machine coding specifically, reading about SOLID principles is not sufficient. Pick three to four problems from the canonical list (cache eviction, booking systems, rental systems, game logic) and implement each in a timed 90-minute session. Review your code the next day and ask: is every class doing one thing? Would a teammate understand this without asking? Are there tests for the edge cases?
For system design, build the clarification habit explicitly. Before you draw a single component, force yourself to ask at least two clarifying questions out loud.
SpaceComplexity runs voice-based mock interviews with rubric-based feedback, which gives you a faster feedback loop on communication and reasoning than grinding problems alone. One timed machine coding mock with structured feedback is worth a week of reading design articles.
If your fundamentals are solid and you can solve medium LeetCode problems consistently, six to eight weeks is realistic: two weeks on DSA patterns, two on machine coding practice, one to two on system design, one on behavioral stories, and a final week of full mock interviews. If you're starting from scratch on DSA, plan for three months.
Where Candidates Get Rejected
Call this the rejection greatest hits. Different rounds, different problems, same outcome.
- Jumping to optimal without stating brute force. The interviewer is evaluating your thinking, not just the answer.
- Skipping tests in machine coding. This is an explicit evaluation criterion. Incomplete test coverage is a documented rejection reason.
- Designing before clarifying in system design. The documented failure mode: building a perfectly scalable system for the wrong requirements.
- Vague behavioral results. "We handled it well" is not a result. Name the specific outcome.
- Under-preparing the hiring manager round. Most candidates spend zero time on this. For experienced hires especially, it's a real gate.
For a broader overview of the full PhonePe hiring process including the online assessment and phone screen stages, see the PhonePe software engineer interview guide.