---
title: PhonePe Backend Engineer Interview Questions (2026)
description: Real PhonePe backend engineer interview questions — UPI idempotency, payment state machines, LLD and scale design — with answers and a four-week prep plan.
url: https://usegreenroom.app/blog/phonepe-backend-engineer-interview-questions
last_updated: 2026-07-31
---
← Back to blog
India · PhonePe
# PhonePe backend engineer interview questions and process
July 31, 2026 · 12 min read
"The user taps Pay," the interviewer said. "Your service calls the bank. The bank times out. What do you do?" The candidate said he'd retry. "Okay. The first call actually succeeded — the response just never came back. You've now retried it." And there it was: the interview had, in about eleven seconds, arrived at the only question a payments company really asks.
PhonePe backend engineer interview questions circle one idea relentlessly — what happens when things fail halfway. PhonePe processes UPI transactions at a volume where a one-in-a-million bug happens several times an hour, so the loop is built to find engineers who think in failure modes first and happy paths second. This guide covers the rounds, the questions, and what to say out loud.
## The PhonePe backend engineer interview process in 2026
PhonePe hires backend engineers into payments core, merchant and lending, and platform teams, mostly in Bengaluru. The reported PhonePe backend engineer interview process:
- Online assessment — two or three DSA problems, medium difficulty, usually on HackerEarth or a similar platform. Common for freshers and lateral hires alike.
- DSA round 1 — arrays, strings, hashmaps, trees, heaps. Clean working code is weighted more heavily than a clever optimal trick.
- DSA round 2 or machine coding — either a second algorithms round or a low-level design problem you build live.
- Low-level design round — model a payments primitive in classes: a wallet, a transaction ledger, a rate limiter, a notification service.
- System design round — the differentiator. Design UPI payments, a wallet service, or a webhook delivery system at PhonePe scale.
- Hiring manager round — an outage you owned, a tradeoff you regret, and how you behave on call.
The DSA bar is real but not FAANG-extreme; the design rounds are where offers are decided. A candidate who codes beautifully but cannot explain what happens when a downstream service is slow will not clear this loop.
The PhonePe backend loop: DSA gets you through the door, the design rounds decide the offer.
## PhonePe DSA interview questions
The PhonePe DSA round sits at LeetCode medium, occasionally nudging into hard. Reported topics cluster tightly: sliding-window and two-pointer array problems, hashmap frequency and grouping questions, binary tree traversal and lowest common ancestor, heaps for top-K and merge problems, stack-based problems like next-greater-element, and graph traversal (BFS/DFS) for connectivity.
Dynamic programming appears but rarely decides the round. What does decide it: narrating the brute force and its complexity before optimising, handling edge cases without being prompted, and writing code that compiles. Interviewers repeatedly report rejecting candidates who reached the optimal approach but produced code that would not run. Our data structures interview questions guide covers the topic list and the how to think out loud in interviews guide covers the narration.
## Idempotency: the question from the intro
This is the single most important concept in a PhonePe backend interview, and it comes up in the LLD round, the system design round, and sometimes in the DSA round as a follow-up. The scenario is always some version of: a request may be delivered more than once, and money must move exactly once.
The expected answer is an idempotency key. The client generates a unique key per logical operation and sends it with every retry of that operation. The server records the key with the result, so a repeat is recognised and the stored result is returned rather than the operation being performed again.
```
public PaymentResult pay(String idempotencyKey, PaymentRequest req) {
// Atomic claim: only the first caller with this key wins the insert.
boolean claimed = store.insertIfAbsent(idempotencyKey, Status.IN_PROGRESS);
if (!claimed) {
Record existing = store.get(idempotencyKey);
if (existing.status() == Status.IN_PROGRESS) {
// A retry arrived while the original is still running.
throw new ConflictException("in flight, retry later");
}
return existing.result(); // replay the stored outcome
}
PaymentResult result = ledger.execute(req);
store.complete(idempotencyKey, result);
return result;
}
```
Three follow-ups to have ready. What is the key scoped to — a user and an operation, so two genuinely different payments never collide? How long do you retain keys, and what happens after expiry? And what if the process dies between execute and complete, leaving the record stuck IN_PROGRESS? The answer to the last one is a reconciliation job that queries the downstream system for the true state — and volunteering it unprompted is a strong signal, because it shows you know the store and the ledger can disagree.
## PhonePe low-level design questions
The PhonePe LLD round asks you to model a payments primitive in classes, usually in 45 to 60 minutes. Reported problems: a digital wallet with balance and transaction history, a transaction ledger, a rate limiter, a notification/webhook dispatcher, a split-payment feature, and a coupon or cashback engine.
The wallet is the most common, and the scoring is specific:
- Money as integers. Store paise as a long or BigDecimal, never a double. A float in a currency field is an immediate flag.
- An append-only ledger, not a mutable balance. The balance is derived from entries (or a cached projection of them). "I'd have a balance column I update" invites the question about two concurrent debits.
- Concurrency stated explicitly. Optimistic locking with a version column, or a row lock, or a single-writer-per-account queue. Say which and why.
- State machine for the transaction. INITIATED → PENDING → SUCCESS / FAILED / REVERSED, with the illegal transitions named. Interviewers ask what stops a SUCCESS becoming PENDING again.
- Extension points. An interface for payment instrument (wallet, UPI, card) and one for fee or cashback rules, because those are what change.
Our machine coding round guide covers timeboxing, and the design patterns interview questions guide covers the patterns worth naming while you build.
## PhonePe system design questions
The PhonePe system design round is where the offer is decided. Reported prompts: design UPI payment flow, design a wallet service, design a webhook delivery system, design the transaction history feed, design a rate limiter for merchant APIs, design notification fan-out at 100M+ users.
A UPI-flavoured design answer should hit these beats, roughly in order:
- Clarify scale and SLA first. Peak TPS, read/write ratio, acceptable latency, and — the payments-specific one — what the consistency requirement is. Money is not eventually consistent.
- Draw the flow with the external dependency. App → PhonePe backend → NPCI/bank switch → back. The interesting part is that the external system is slow, flaky and authoritative.
- Two-phase state, not one. A payment is recorded as PENDING before the external call and resolved after. If you record only on success, a timeout loses money.
- Idempotency at every hop, as above.
- Reconciliation as a first-class component. A scheduled job that fetches the bank's view and settles disagreements. This is what real payment systems actually run on, and mentioning it separates you immediately.
- Async where it is allowed. Notifications, ledger projections and analytics go on a queue (Kafka); the debit itself does not.
- Failure drills. What if the bank is down? Circuit breaker plus queued retries with backoff. What if your DB primary fails mid-write? What if a consumer processes a message twice?
Our system design interview guide for India covers the general structure, the Kafka interview questions guide covers the messaging layer, and the Razorpay backend engineer guide covers the closest comparable payments loop.
## The hiring manager round
PhonePe's manager round leans hard on operational maturity. The recurring questions: tell me about an outage you owned; tell me about a technical decision you got wrong; how do you handle being paged at 3am; what would you do if you found a bug in production that had been silently mis-charging users.
That last one is a values question wearing a technical costume. The answer they want is: escalate immediately, quantify the blast radius, stop the bleeding, then make users whole — in that order, and without waiting to look good. Vague answers about "following the process" land badly. Our tell me about a time you failed guide has the structure.
## LeetCode, GeeksforGeeks, the NPCI docs, ChatGPT — where each fits
- LeetCode — correct tool for the DSA rounds. Medium band, breadth over depth; grinding hards is not where this loop is won.
- GeeksforGeeks and AmbitionBox interview experiences — useful for round order and recurring LLD prompts. Treat process details as approximate and dated.
- The NPCI and UPI public documentation — genuinely underrated. Understanding what a VPA is, how a collect request differs from a pay request, and what the switch actually guarantees lets you speak the interviewers' vocabulary instead of guessing.
- Designing Data-Intensive Applications — the chapters on consistency and delivery guarantees are the theory under every design answer above.
- Low-level design practice — build the wallet and the rate limiter end to end yourself under a timer. Reading solutions does not build the reflex.
- ChatGPT — fine for generating design prompts and reviewing a class diagram. It will not say "the first call actually succeeded" and then wait for you to work out what that means.
- Greenroom — the spoken layer. Ari, the AI interviewer, runs the design and manager rounds out loud, pushes the failure-mode follow-up when your answer only covers the happy path, and scores structure and clarity. Fair tradeoff: Ari will not compile your wallet.
> The core truth: PhonePe hires backend engineers who describe the failure before the feature. If your design answer reaches "and then it succeeds" without ever saying what happens on a timeout, you have answered a different question than the one you were asked.
## How to prepare for the PhonePe backend interview
- Week 1: LeetCode medium daily across arrays, hashmaps, trees, heaps and graphs — each solved out loud with the brute force stated first.
- Week 2: LLD under a timer. Build a wallet, a rate limiter and a notification dispatcher. After each, have someone add a requirement and see what you have to rewrite.
- Week 3: system design aloud, one per day, always ending with a failure drill: what breaks when the downstream is slow, down, or lying.
- Final week: rehearse idempotency and reconciliation until they are reflexive, prepare two on-call war stories in first person, and run two full spoken mocks with follow-ups.
Interviewing across Indian fintech and consumer tech? The general PhonePe interview questions guide covers the company-wide loop, the Razorpay backend engineer guide and Paytm interview questions guide cover the nearest payments comparisons, and the Zepto data engineer guide and Meesho frontend engineer guide cover other Indian consumer-tech loops.
## Frequently asked questions
### What is the PhonePe backend engineer interview process?
Candidates report an online assessment with two or three medium DSA problems, one or two DSA interview rounds, a low-level design round modelling a payments primitive such as a wallet or rate limiter, a system design round on UPI payments or a wallet service at scale, and a hiring manager round covering outages and on-call behaviour. The DSA bar is real but the design rounds decide most offers.
### What DSA questions does PhonePe ask backend engineers?
The DSA rounds sit at LeetCode medium, occasionally touching hard. Reported topics include sliding-window and two-pointer array problems, hashmap frequency and grouping questions, binary tree traversal and lowest common ancestor, heaps for top-K and merge problems, stack problems such as next greater element, and BFS or DFS graph traversal. Working, compiling code matters more than reaching the optimal trick.
### What is idempotency and why does PhonePe ask about it?
Idempotency means an operation produces the same result whether it is executed once or many times, which matters because a payment request can be retried after a timeout even though the original succeeded. The expected design is an idempotency key generated per logical operation, stored with its result, so repeats return the stored outcome instead of moving money twice. Expect follow-ups on key scope, retention, and what happens if the process dies mid-operation.
### What low-level design questions does PhonePe ask?
Commonly reported LLD problems are a digital wallet with balance and transaction history, a transaction ledger, a rate limiter, a notification or webhook dispatcher, a split-payment feature and a cashback engine. Scoring favours storing money as integers rather than floats, an append-only ledger rather than a mutable balance, an explicit concurrency strategy, a transaction state machine with illegal transitions named, and interfaces where requirements will change.
### What system design questions does PhonePe ask?
Reported prompts include designing the UPI payment flow, a wallet service, a webhook delivery system, the transaction history feed, a merchant API rate limiter, and notification fan-out to over 100 million users. Strong answers clarify scale and consistency requirements first, record a payment as pending before calling the external bank switch, apply idempotency at every hop, and treat reconciliation as a first-class component rather than an afterthought.
### Is the PhonePe backend engineer interview hard?
The algorithmic bar is solid but below FAANG-extreme — medium difficulty, weighted toward clean working code. The difficulty is domain rigour in the design rounds, where interviewers push relentlessly on failure modes: timeouts, duplicate delivery, partial failures and disagreements between your ledger and the bank. Candidates who only prepare the happy path find these rounds much harder than the coding ones.
PhonePe's loop is a failure-mode conversation, not a coding test. Greenroom runs mock backend and system design interviews out loud with Ari — timeout and idempotency pushback included — and scores structure, clarity and depth. Free to start. Curious how it works? See how AI mock interviews work.