Ninety seconds into his PhonePe system design round, a candidate I'll call Arjun was cruising — he'd rehearsed "design a digital wallet" so many times he could draw the boxes in his sleep. Then the interviewer leaned in: "Your user is on a train outside Lonavala. She scans a chai stall's UPI QR for ₹40, the debit succeeds, the confirmation times out, and she taps Pay again. Walk me through every system that has to notice." That one follow-up is the whole story of PhonePe interview questions: standard-looking prompts, payments-grade consequences.
At most companies a dropped request is a retry. At a company processing a large share of India's UPI volume, a dropped request is either someone's money debited twice or a merchant not paid — and the interview is built to find out whether you feel that difference. I built Greenroom after freezing in interviews exactly like Arjun's, where I knew the material and still couldn't reorganize it out loud under pressure. This guide covers the real PhonePe interview process, the machine coding round it inherited from its Flipkart roots, and the payments system design questions that decide the loop.
The PhonePe interview process
Reported loops for SDE roles at PhonePe consistently look like this:
- Online assessment or DSA screen — timed coding problems, easy-to-medium, judged on working code.
- Machine coding round — roughly 90 minutes to build a small working system (not pseudocode) with clean, extensible object-oriented design.
- Problem solving / DSA round — one or two problems solved live, with your reasoning spoken out loud.
- System design round — payments-flavored design for SDE-2 and above: transaction status, ledgers, reconciliation.
- Hiring manager + HR rounds — project depth and ownership, then compensation and notice period.
Most candidates report 4–5 rounds total. PhonePe was incubated inside Flipkart before it was spun out, and the interview culture shows it — the machine coding round is treated as a serious filter, not a formality, exactly as it is in the Flipkart interview loop.
PhonePe machine coding round
You get a prompt like build a Splitwise-style expense sharer, a parking lot system, or an in-memory wallet with transaction history, and about 90 minutes to produce code that runs, handles edge cases, and could absorb a new requirement without a rewrite. Evaluators look at:
- Working demo first — a partially complete system that runs beats a beautiful design that doesn't.
- Separation of concerns — models, services, and storage cleanly split; no God classes.
- Extensibility probes — "now add a second payment mode" should be a small change, not surgery.
- Naming and readability — they will read your code with you and ask why.
Payments system design at UPI scale
This is where PhonePe's loop genuinely diverges from generic prep. Real reported prompt shapes:
- Design the payment status system — a transaction has a debit leg and a credit leg through banks that respond slowly, out of order, or not at all. Model the states.
- Handle the double-tap — the user retries a payment whose first attempt may or may not have succeeded. Where does the idempotency key live, and who checks it?
- Design a reconciliation system that compares your ledger against bank settlement files and surfaces mismatches.
- Design a ledger — append-only entries, double-entry bookkeeping, and why you never UPDATE a balance in place.
- Rate-limit and degrade gracefully when a partner bank starts timing out during a festival-sale traffic spike.
The frameworks are the ones in our system design interview guide — but the grading rubric shifts. Availability answers that would pass at a social media company fail here; interviewers push until you talk about exactly-once semantics, idempotency, and what the user sees while money is in limbo. If you've never said the sentence "the transaction stays in PENDING until the reconciliation job resolves it" out loud, say it a few times before the real round.
Behavioral and hiring manager questions
PhonePe's hiring manager round probes ownership under ambiguity — reported questions include:
- Tell me about a production incident you owned end to end. What broke, what you did in the first ten minutes, what changed afterward.
- Describe a time you pushed back on a requirement and what evidence you used.
- Walk me through the most complex system you've worked on — expect three levels of "why" on every decision.
- A teammate's change corrupted data. What do you do in the first hour?
Structure these with STAR — our behavioral interview questions guide covers the format — and where your real experience allows, anchor stories in correctness and reliability rather than shipping speed. This is a company where "we moved fast" lands worse than "we didn't lose a rupee."
LeetCode, GeeksforGeeks, ChatGPT — where each fits
An honest map of the usual prep stack against this specific loop:
- LeetCode — right tool for the DSA screen and problem-solving round; PhonePe's coding problems are standard patterns asked under time pressure.
- GeeksforGeeks interview experiences — good for calibrating recent PhonePe questions and machine coding prompts; treat individual entries as anecdotes, not a syllabus.
- A system design course or textbook — teaches the skeleton, but canonical examples (URL shortener, news feed) never make you model a two-legged transaction through an unreliable bank. You'll have to adapt live.
- ChatGPT — useful for generating payments design prompts and critiquing a written answer; it won't interrupt you mid-sentence with "the bank just timed out — now what?" the way a real interviewer will.
- Greenroom — the spoken layer. Ari, the AI interviewer, runs machine-coding walkthroughs and system design rounds out loud, and can be steered to inject exactly these payment failure modes mid-answer, so you practice re-deriving a design instead of reciting one.
How to prepare for the PhonePe interview
- Week 1: DSA speed work — arrays, strings, trees, graphs, heaps — timed, since both coding rounds reward fast correct code. Our DSA preparation guide for India has the drill order.
- Week 2: machine coding — build Splitwise, a parking lot, and an in-memory wallet, 90 minutes each, then refactor one to absorb a new requirement and narrate the change.
- Week 3: payments system design — design payment status, reconciliation, and a ledger; for each, write down the failure modes (retry, duplicate, partial failure) before the happy path.
- Final week: one full spoken mock where the interviewer (or Ari) injects a mid-design curveball, plus a behavioral pass anchored in reliability stories.
If you're interviewing across Indian fintech, the skeleton rhymes but the emphasis shifts — our Paytm interview questions guide covers the neighboring loop, and the Flipkart guide covers the machine-coding-heavy e-commerce parent culture PhonePe grew out of.
Frequently asked questions
What questions does PhonePe ask in a technical interview?
Expect timed DSA problems (arrays, strings, trees, graphs) in the screen, a 90-minute machine coding round building a small working system with clean OOP, and payments system design for SDE-2 and above — transaction status modeling, idempotent retries, ledgers, and reconciliation against bank settlement files.
How many rounds are in the PhonePe interview process?
Most reported SDE loops run 4–5 rounds: an online assessment or DSA screen, a machine coding round, a problem-solving round, a system design round for SDE-2+, and a hiring manager plus HR round.
Is the PhonePe interview hard?
The DSA bar is standard product-company level, but the loop is demanding in two places: the machine coding round, which requires runnable, extensible code in about 90 minutes, and the system design round, which is graded against payments failure modes — double-taps, partial failures, reconciliation — that generic prep rarely covers.
What is the PhonePe machine coding round?
A roughly 90-minute round where you build a small working system — commonly a Splitwise-style expense sharer, a parking lot, or an in-memory wallet — in a real editor. It's evaluated on whether the code runs, how cleanly responsibilities are separated, and how easily it absorbs a new requirement the interviewer adds near the end.
What system design questions does PhonePe ask?
Reported prompts center on money movement: design a payment status system with slow, out-of-order bank legs; handle a user retrying a payment that may have already succeeded; design a reconciliation system against bank settlement files; and design an append-only double-entry ledger.
How should I prepare for the PhonePe SDE interview?
Drill timed DSA for the screens, practice three full machine coding problems end to end with a refactor pass, and rehearse payments system design out loud — leading with failure modes (retries, duplicates, partial failure) rather than the happy path, because that's where PhonePe interviewers spend most of the round.