PhonePe Interview Guide (2026)

1Snapshot, read this first#

Read the comp line correctly.

• PhonePe is a global-India company, so comp is INR-denominated. There is no separate US band here.

The one thing to understand about PhonePe.

• They run something north of a billion UPI transactions a month, so correctness under load is the whole product.
• They care less about obscure algorithms and more about whether your code runs correctly, handles retries, and fails safely.
• Machine coding and real engineering judgment carry more weight than trivia.
• When you are deciding where to spend your last prep hours, spend them making code run, not reading about red-black trees.

2Getting the call (the part most guides skip)#

PhonePe sources candidates three ways.

• Internal referrals.
• Direct applications through the careers page.
• Campus and off-campus drives for freshers.

A referral is the single highest-leverage move.

• A referred resume gets a human read instead of a keyword filter.
• It usually lands a recruiter call within a week instead of sitting in a queue for a month.
• No one inside? Find a second-degree LinkedIn connection who works there and ask for a 15-minute call before you ask for the referral. People refer humans, not resumes.

Resume rules that matter here.

• One page under about 6 years of experience. Two pages past that, never three.
• Lead every bullet with impact, not responsibility. "Worked on the payments service" tells the screener nothing.
• Put your biggest number in your top three bullets. A screener spends maybe 20 seconds on the first pass.

A concrete quantified bullet that works:

Redesigned the transaction-reconciliation job from a nightly batch to an incremental stream, cutting end-of-day settlement lag from 40 minutes to under 3 minutes and removing ~12 manual ops tickets per week.

Why that line gets a call.

• It shows scale, latency awareness, and ownership in one sentence, exactly the signals a payments company screens for.
• Compare it to "responsible for reconciliation." One gets you a call, the other gets skimmed past.

ATS keywords to include naturally (only if true).

• Java, Go, Kotlin, data structures, distributed systems, microservices, Kafka, MySQL/Postgres, Redis, REST/gRPC, concurrency, low-level design, high availability.
• Plus your actual QPS and data-volume numbers. "Handled 8k QPS at p99 under 50ms" beats "experienced with high-scale systems" every time.

How people actually get shortlisted.

• Freshers: a timed online assessment (2-3 DSA problems plus CS MCQs) on a platform like HackerRank or Codility, auto-graded against hidden test cases.
• Experienced hires: a recruiter screen or a referral kicks off the loop directly.
• Shipped anything at genuine scale, even a side project handling real traffic? Put the numbers on the page. PhonePe reads numbers.

3The loop at a glance#

How the loop shifts by level.

• Freshers lean toward more DSA and fewer design rounds.
• Experienced candidates get the machine-coding and system-design rounds plus a manager deep-dive.

Do not underrate the bar-raiser.

• A senior engineer from outside the hiring team whose one job is to protect the hiring quality of the company, not fill this specific seat.
• They can veto.
• Treat that round as seriously as any coding round, because a lukewarm bar-raiser write-up sinks an otherwise clean loop.

4The coding rounds, patterns, not problems#

Do not try to memorize a thousand problems. PhonePe (like most strong engineering orgs) reuses a small set of patterns at Medium-Hard difficulty. Master these and most problems become recognizable:

• Arrays & two pointers / sliding window: subarray sums, longest-substring variants, container problems.
• Hashing: frequency maps, grouping, two-sum families, dedup at scale.
• Binary search: on sorted arrays and on the answer space (minimize max, allocate books, rate limiting).
• Trees & graphs: BFS/DFS, topological sort, shortest paths, lowest common ancestor.
• Heaps / priority queues: top-K, merge-K-sorted, scheduling.
• Dynamic programming: knapsack, longest common subsequence, grid paths, interval DP (expect at least one DP question at SDE-2+).
• Intervals: merge, insert, meeting-rooms.
• Stacks: next-greater-element, valid-parentheses, monotonic-stack problems.

Difficulty, set your expectations.

• Think solid LeetCode Medium with one Hard thrown in for senior roles.
• They care more about a correct, well-reasoned Medium than a half-finished Hard.
• Optimize a Medium cleanly, state the complexity, and test it: you pass.
• Get 70% into a Hard and run out of time: you usually do not.

How to practice.

• Do problems in timed 35-minute blocks.
• After each one, write one sentence naming the pattern, for example "sliding window with a shrinking left pointer when the window breaks a constraint."
• Review by pattern, not by random order.
• Aim for ~120-150 quality problems across the list above, not 500 skimmed ones. Quality means you can re-derive the solution cold a week later, not that you saw it once.

How to win the round, the four Cs.

1. Communicate: narrate your approach before you type. Say "my first instinct is a hash map for O(n), let me confirm that handles duplicates." Silence reads as "stuck," and the interviewer scores what they hear, not what is in your head.
2. Clarify: restate the problem, confirm input ranges, ask about duplicates, empty input, negatives, and overflow. At a payments company, "can the amount be negative?" earns a nod.
3. Complexity: state time and space for your approach and say whether it can be improved before you commit to coding. "This brute force is O(n squared); I think we can get O(n) with hashing, let me do that."
4. Check: dry-run your code on one normal case and one edge case, out loud, tracing the variables. Interviewers at a payments company love candidates who test their own code before saying "done."

Two habits that push you into SDE-2 signal.

• Write code that compiles. Use real variable names, remainingBalance, not x.
• Finish early? Discuss how it behaves at scale: what breaks at 10 million inputs, where the memory goes.

5Machine coding / low-level design (the round that decides it)#

This is PhonePe's signature round and where many strong DSA candidates stumble.

• You get a problem like "build a parking lot," "design an in-memory cache with TTL and LRU eviction," "model a Splitwise-style expense splitter," or "build a rate limiter."
• You get roughly 90-120 minutes to deliver compiling, runnable, extensible code, not pseudocode.
• At the end, the interviewer often says "add this new requirement," and watches how cleanly your design absorbs it.
• If your design was a single God class, that moment exposes it.

A framework that scores well.

1. Clarify scope (5 min). Nail down must-have vs. nice-to-have. Say explicitly: "I'll build X and Y fully; Z I'll stub with a clean interface." Scoping out loud is itself a signal; it shows you ship under a deadline instead of gold-plating.
2. Model the entities (10 min). Identify the core classes and objects and their relationships. Prefer composition over deep inheritance. For a parking lot that is ParkingLot, Level, Spot, Vehicle, Ticket, not a five-level class hierarchy.
3. Define interfaces first. Program to interfaces so behaviors like eviction policy or discount strategy are swappable. This single move signals senior design maturity and makes the "now add a new rule" twist a two-minute change instead of a rewrite.
4. Apply the right patterns: Strategy for interchangeable rules (eviction, pricing), Factory for object creation, Observer for notifications, Singleton sparingly. Do not force patterns; naming a pattern you do not need reads worse than clean plain code. Use them where they genuinely reduce coupling.
5. Make it run. Write a small driver/main or tests that demonstrate the happy path and one edge case. Working code beats elegant-but-broken code every time. Leave the last 15 minutes to compile and run; a build error at minute 119 can sink the whole round.
6. Keep it clean. Meaningful names, small methods, no God class, basic thread-safety if the prompt implies concurrency (a shared cache or rate limiter almost always does, so reach for a ConcurrentHashMap or a lock and say why).

Classic prompts they reuse.

• Parking lot, elevator system, LRU/LFU cache, rate limiter (token bucket), Splitwise, movie-ticket booking, logging framework, a simplified payment/wallet module.
• Practice two or three of these end-to-end on a clock before your loop.
• The first time you build one you will blow past 120 minutes. By the third you will have a reusable skeleton (entities, interfaces, a main method) that you adapt on the fly.

For SDE-2 and above, add a system design round. Use a consistent structure:

• Requirements: functional + non-functional (latency, availability, consistency, QPS). Pin down numbers early; "100k writes/sec peak during a sale" changes every later decision.
• Capacity estimate: back-of-envelope reads/writes, storage, bandwidth. Show the arithmetic.
• High-level design: API, data model, core services. Draw the boxes before you dive into any one of them.
• Deep dive: one component in detail, for example idempotent payment processing, exactly-once semantics, or sharding by user ID.
• Trade-offs: CAP choices, SQL vs. NoSQL, caching, queueing. For money, lean toward strong consistency on the write path and say so.

Here's a minimal payment flow to anchor the conversation:

What the design round is really listening for.

• Expect payments-flavored prompts: a UPI-style payment flow, an idempotent transaction service, a notification system, a rate limiter, or a distributed ID generator.
• Always raise idempotency, consistency, and failure handling unprompted. In fintech those are the whole game.
• An interviewer who has to prompt you for "what happens if the retry arrives twice" has already half-decided.
• Lead with an idempotency key on every write, and explain how a replayed request returns the original result instead of charging again.

6Behavioral & culture fit#

The culture themes that come up again and again.

• Extreme ownership.
• Customer obsession.
• High trust with high accountability.
• Bias for action.
• First-principles thinking.

What interviewers probe for.

• Engineers own problems end to end, not hand them off at the team boundary.
• Times you took initiative, dealt with ambiguity, recovered from a failure you caused, and decided without complete information.
• "I escalated it" is a weak answer here. "I owned it until it was fixed" is the bar.

How to prepare the stories.

• Write 5-6 STAR stories (Situation, Task, Action, Result) in advance and attach a number to every Result.
• Have at least one each for: a hard technical decision, a conflict you resolved, a failure you owned, and a time you shipped under pressure.
• Keep each to about two minutes spoken; rambling reads as unprepared.

One full worked STAR example:

• Situation: Our checkout service started timing out during a festival sale, and failed payments were spiking at ~4% against a <0.5% SLA.
• Task: As the on-call owner, I had to stop the bleeding and prevent revenue loss without a full rewrite.
• Action: I traced the latency to a synchronous call to a third-party bank API inside the request path. I moved it behind an async queue with a retry-and-reconcile worker, added idempotency keys so retries couldn't double-charge, and put a circuit breaker on the downstream call so one slow bank didn't take down checkout.
• Result: Payment failure rate dropped from 4% to 0.3% within the sale window, we recovered an estimated ₹60 lakh in otherwise-abandoned transactions, and the async pattern became the team standard for all external integrations.

Why that story lands.

• The result has a number and a lasting impact.
• The action is mine, not "the team's."
• If your story ends with "and then we fixed it," rewrite it so the interviewer can tell exactly what you did.

7Your prep plan#

4-week plan

• Week 1: Lock the DSA patterns in Section 4. ~40 problems across arrays, hashing, two pointers, binary search. Name the pattern after each.
• Week 2: Trees, graphs, heaps, DP. ~40 more problems. Start one machine-coding problem end to end, even if it takes you three hours the first time.
• Week 3: Two full machine-coding builds on a timer. For SDE-2+, do 4-5 system design prompts out loud, recorded if you can. Write your STAR stories.
• Week 4: Mock interviews (DSA + machine coding) with a real person, not just yourself. Redo your weakest problems. Polish resume and project talking points so you can defend every line.

2-week plan

• Days 1-5: Patterns sprint, ~8 problems/day, reviewed by pattern.
• Days 6-9: One machine-coding build per day; one system design per day (if senior).
• Days 10-12: Mocks and edge-case drills. Make yourself narrate out loud.
• Days 13-14: STAR stories, project deep-dive prep, light review. No cramming the night before; a tired brain fails the dry-run step.

2-day crash plan

• Day 1: Re-solve the two most common problems per pattern (arrays, hashing, binary search, trees, graphs, DP). Do one machine-coding build end to end on a clock.
• Day 2: One system design walkthrough, write three STAR stories, re-read your own resume and prepare to defend every line. Sleep.

8Why people get rejected at PhonePe#

1. Code that doesn't run. In the machine-coding round, elegant pseudocode that never compiles loses to simpler code that works. This is the single most common rejection reason.
2. Silent solving. Interviewers can't score reasoning they can't hear. No narration, no signal, no matter how good the final answer is.
3. Ignoring idempotency and failure modes. For a payments company, not handling retries, duplicates, or partial failures is a red flag that outweighs a clever algorithm.
4. No complexity analysis. Shipping a brute-force solution without acknowledging the optimal one reads as a gap, even when the brute force passes the test cases.
5. God-class design. Dumping everything into one class with no interfaces signals weak OOP judgment, and it falls apart the moment the interviewer adds a requirement in the LLD round.
6. Flat behavioral answers. "We fixed it as a team" with no personal action or metric fails the ownership bar, which is the one bar PhonePe never flexes on.

9The offer, comp & negotiation#

How the offer is structured.

• Base salary + joining/retention bonus + RSUs (vesting over ~4 years) + performance bonus.
• The equity component grows meaningfully at SDE-2 and above.
• PhonePe RSUs are real equity in a company on a public-listing path, so treat the grant as part of the number, not as monopoly money.
• Expect the overall ranges in Section 1, with the exact split depending on team, level, and your current comp.

Negotiation tips for PhonePe's context.

1. Anchor on total comp, not base. Ask for the base/bonus/equity breakdown in writing, then negotiate the lever with the most room, often the joining bonus or the RSU grant rather than base, which tends to be band-constrained.
2. Use competing offers honestly. A real, comparable offer is the strongest lever. Share the actual number and the breakdown, not just the claim. Recruiters discount vague "I have other offers."
3. Negotiate the level, not just the money. If your scope matches SDE-2 but you were slotted SDE-1, make that case with evidence from your past work. The level difference compounds over every future raise and refresh, so it is worth far more than a one-off bump.

Set the tone right.

• Be direct and professional.
• Indian product companies respect a candidate who negotiates with data and specifics, and they expect the ask.
• Not negotiating leaves money on the table and signals nothing.

When you're ready, map these steps onto your actual calendar and build a personalized, dated prep plan so you walk into each round knowing exactly what to practice next.