Interview experience
PhonePe interview experiences covering Online Assessment, Machine Coding Round, Machine Coding Discussion + DSA, System Design Round, +1 more. Round-wise notes, common questions, and what candidates report clears each stage.
PhonePe Interview Questions and Answers (2026)
PhonePe is India's leading digital payments platform, founded in 2015 and later acquired by Flipkart, with hundreds of millions of registered users. It processes billions of UPI and related transactions monthly across payments, bill pay, insurance, and financial services. Bengaluru engineering teams build the high-scale systems behind that consumer and merchant stack.
Explore: Interview experience · HR interview questions · Overview · Placement papers · Preparation guide
Overview
PhonePe’s fresher loop leans harder on machine coding than most fintech peers - candidates build a working system from scratch and get graded on OOP design and code quality, before a system-design round scoped to real payment-infrastructure problems.
PhonePe is India’s leading digital payments platform with over 500 million registered users. Founded in 2015 and acquired by Flipkart, PhonePe processes billions of transactions monthly. The company offers UPI payments, bill payments, insurance, and financial services with a strong engineering team in Bengaluru. PhonePe values innovation, scalability, and building robust payment systems.
HR interview questions
PhonePe HR interview questions with sample answer frameworks - motivation, relocation, STAR stories, and culture-fit prompts.
PhonePe interview process at a glance
| Round | Duration | What they test |
|---|---|---|
| Online Assessment | 60-90 min | 2-3 medium-hard DSA problems |
| Machine Coding Round | 45-60 min | Build a working system - OOP design, SOLID, code quality |
| Machine Coding Discussion + DSA | 45-60 min | Design trade-offs on your submission + 1-2 more DSA problems |
| System Design Round | 45-60 min | Hard DSA + system design (payments infra) |
| Managerial / HR | 30-45 min | Behavioral fit, motivation, offer discussion |
PhonePe online assessment: quick answers
These answers are compiled from public candidate reports and prep guides, not from an official notice, and drives differ. The instruction screen of your own test is the final word.
| Question | Answer |
|---|---|
| How many questions and how long? | It depends on the role. Software engineer campus OAs usually have 2-4 medium-hard coding problems in 60-90 minutes; 2025 campus reports describe 4 hard, competitive-programming-style problems in 90 minutes; one 2023 on-campus test had 15 technical MCQs (OOP, SQL, CN, OS) plus 3 coding questions. Analyst campus drives instead open with a short aptitude test (one report: 15 MCQs in 15 minutes). |
| Does it have negative marking? | No public report mentions any. For software roles the coding questions carry the shortlist. |
| Is there a sectional cutoff? | Not published. Where MCQs and coding are combined, the coding questions matter most in candidate reports. |
| How much is the cutoff? | Not published, and the funnel is narrow. In one 2023 campus drive, 33 students cleared the OA, 12 cleared technical round 1, 7 reached the managerial round and 3 were selected. |
| Which platform is it on? | Reports conflict. 2025 campus reports name DoSelect with proctoring (August 2025) and SafeBrowser (July 2025, Mumbai); older reports name HackerRank or CodeSignal. Some SDE-2 loops send a 90-minute CodeSignal machine-coding take-home. |
| Is there coding? Which topics? | Yes - DP, string decoding, arrays, graphs and binary search. Reported problems: check whether a triangle can be formed from array values, and count ordered pairs whose concatenation equals X. One campus OA also included UNIX questions. |
| Is there a GD? | Only in some analyst drives. One campus drive for a risk/analytics internship ran a group discussion on technology in finance after the aptitude test. Software roles go straight to interviews. |
PhonePe interview questions by role
These themes come from candidate reports on GfG. They show the level and style, not a fixed list.
| Role | Reported questions and topics |
|---|---|
| Software engineer (campus) | 2025 OA reports: Minimum Cost to Reach Destination in Time (graph with fees and a time limit), Dijkstra, binary search on the answer and DSU; balanced parentheses, check an array for duplicates, remove duplicates from a sorted array, restore IP addresses, linked lists, tries. SQL (10th highest score), candidate key vs primary key, ACID and indexing, HTTP vs HTTPS and status codes, hashing vs encryption, OSI model and TCP vs UDP, Singleton. |
| SDE-1 / SDE-2 | Machine coding a rate limiter, class-booking system or notification scheduler with clean OOP and thread safety, then a design review; payment gateway and distributed cache design. |
| Risk / business analyst | Fraud cases (a caller asking you to send money to a link), incentive abuse in a ride-hailing bonus, why a company’s growth stalled, 4-5 SQL questions on GROUP BY and window functions such as ROW_NUMBER, and basic Power BI. |
Asked across every role: a detailed project walkthrough, SQL, and why PhonePe. Some final rounds add a puzzle (one report: filling water buckets).
Online Assessment
A 60-90 minute timed test (DoSelect or SafeBrowser in 2025 campus reports, HackerRank or CodeSignal in older ones) with 2-4 medium-hard problems spanning arrays, binary search, trees, graphs, and dynamic programming.
Common questions
- Maximum subarray sum and array-manipulation variants
- Graph traversal problems (BFS/DFS-based)
- Binary search and dynamic-programming problems at medium-hard difficulty
Machine Coding Round
Build a working application from scratch in the interview - candidates report tasks like a rate limiter, class-booking system, notification scheduler, or TODO list with analytics. Some SDE-2 loops use a 90-minute CodeSignal take-home plus a 30-minute design review on the same code. Interviewers grade object-oriented design, SOLID principles, code readability, test coverage, and whether the code actually compiles and runs, not just the approach.
Common questions
- Design and implement a rate limiter (sliding window / token bucket) as running code
- Build a booking/reservation system with registration, booking, and admin flows
- Concurrency and thread-safety handling in your implementation
- Justify your class design and which design patterns you used
Machine Coding Discussion + DSA
The interviewer walks through your machine-coding submission first - design decisions, trade-offs, what you’d change - then adds one or two medium-hard DSA problems to test breadth beyond the design round.
Common questions
- Defend specific class-design choices from your machine-coding round
- What would you change if requirements doubled in scale?
- Follow-up DSA problems on trees, graphs, or dynamic programming
System Design Round
One hard DSA problem followed by a system-design discussion - lighter in scope for SDE-1 roles, but consistently framed around real payment-infrastructure scenarios rather than a generic prompt.
Common questions
- Design a payment gateway - transaction flow, database design, consistency
- Handle transaction retries and idempotency without double-charging
- Design a distributed cache system - consistency models, eviction policies, replication
- Rate limiting and event-driven architecture for high-volume transactions
Round-by-round narratives are on the PhonePe interview experience page.
Managerial / HR round
A closing 30-45 minute conversation on behavioral fit, career goals, and offer logistics. Some loops fold this into a single round; others run a separate managerial and HR step.
Common questions
- Tell me about yourself and your background
- Describe a conflict you handled in a team
- Why fintech, and why PhonePe specifically?
- What are your salary expectations and joining timeline?
Sample answer frameworks for each of these are on the PhonePe HR interview questions page.
PhonePe software engineer vs analyst roles
PhonePe runs separate campus processes for engineering and for analyst roles, and they share almost nothing beyond the HR round.
The software engineer route is a coding OA, then technical and machine-coding rounds, system design (lighter for SDE-1) and a managerial round. The analyst route (risk, safety, business analytics) opens with an aptitude test, sometimes a group discussion, then case interviews on fraud and business problems plus SQL.
PhonePe was part of the Flipkart group until the two announced their full ownership separation on 23 December 2022, after a partial split in December 2020; Walmart remains the majority shareholder of both, and PhonePe is now an India-domiciled company. It hires on its own, not through Flipkart drives. This page mainly covers the software engineer route.
Common technical interview questions and answers
Q: How would you build a rate limiter as running code in a machine coding round?
Define a RateLimiter interface with a single allow(clientId) method, then implement TokenBucketRateLimiter holding a per-client record of token count and last-refill timestamp. On each call, compute elapsed time, add elapsed multiplied by the refill rate to the token count capped at burst capacity, and allow the request only if at least one token remains, decrementing it. Store client state in a ConcurrentHashMap and make the check-and-decrement atomic - either synchronise on the per-client bucket or use compute() so two threads cannot both spend the last token. PhonePe’s machine coding round scores whether the code actually compiles and runs, so include a small main method exercising the limiter and keep the strategy pluggable behind the interface so a sliding-window implementation can be swapped in.
Q: What are the SOLID principles, and how do they show up in a machine coding submission?
Single Responsibility: a class has one reason to change, so BookingService should not also format receipts. Open/Closed: extend behaviour by adding a class, not editing existing code - a new pricing rule becomes a new PricingStrategy implementation. Liskov Substitution: any subclass must be usable wherever the base type is expected without breaking callers, which is why a Square that overrides setWidth to also change height is the classic violation. Interface Segregation: prefer several narrow interfaces over one fat one, so an implementer is not forced to stub methods it cannot support. Dependency Inversion: depend on abstractions, so BookingService takes a PaymentGateway interface injected via the constructor rather than instantiating a concrete class - which is also what makes the code unit-testable, and testability is the practical argument to give the interviewer.
Q: How do you make an in-memory booking system thread-safe?
The danger is a check-then-act race: two threads both see a seat as available and both book it. Guard the reserve operation so the availability check and the state mutation happen atomically - either synchronise on the specific show or seat object rather than a global lock, or model seat state as an AtomicReference and use compareAndSet from AVAILABLE to BOOKED so only one thread wins. Prefer ConcurrentHashMap over synchronised collections for the store, and lock at the finest granularity that is still correct, because a single global lock serialises the whole system. If your design locks multiple seats for one booking, acquire them in a consistent global order (for example by seat id) to avoid deadlock between two concurrent multi-seat bookings.
Q: Explain Kadane’s algorithm and the change needed for an all-negative array.
Kadane’s scans once, maintaining current = max(num, current + num) and best = max(best, current). The insight is that a running prefix with a negative sum can never improve a later subarray, so you drop it and restart at the current element. Time is O(n), space O(1). If every element is negative, initialising best to 0 wrongly returns 0 for a non-empty array, so initialise best to the first element or negative infinity and let max pick the least-negative element. To return the actual subarray, record a start index whenever current resets to num, and capture start and end whenever best improves.
Q: When would you use BFS over DFS on a graph?
BFS explores level by level using a queue and finds the shortest path in terms of number of edges on an unweighted graph, which DFS cannot guarantee. DFS uses a stack or recursion and goes deep first, which makes it the natural choice for cycle detection, topological sorting, connected components, and any problem needing backtracking. Both are O(V + E) time; BFS space is O(width of the graph) for the queue while DFS space is O(depth) for the stack, so on a wide shallow graph DFS uses less memory and on a deep narrow one BFS does. For weighted edges neither gives shortest paths - use Dijkstra with a min-heap, or 0-1 BFS with a deque when weights are only 0 or 1.
Q: How do you design a payment gateway so retries never double-charge?
Make the charge endpoint idempotent: the client generates a unique Idempotency-Key per logical payment, and the server inserts that key into a uniquely indexed table inside the same ACID transaction that writes the ledger entries. If the insert succeeds, process the payment and persist the serialized response against the key; if the unique constraint fires, return the stored response rather than charging again. Because the check and the write happen in one transaction, concurrent retries cannot both pass. Downstream, model the payment as an explicit state machine - INITIATED, AUTHORIZED, CAPTURED, FAILED, REVERSED - with only legal transitions permitted, and run a reconciliation job against the acquirer’s settlement file to catch the genuinely dangerous case where the charge succeeded but the response never reached you.
Q: How would you design a distributed cache? Cover eviction, consistency, and replication.
Partition keys across nodes using consistent hashing with virtual nodes, so adding or removing a node remaps only roughly 1/N of keys instead of reshuffling everything as plain modulo hashing would. For eviction, LRU suits general workloads, LFU is better when a small hot set dominates, and TTL-based expiry is what you want for data that goes stale on a schedule. For consistency, cache-aside (the application reads the cache, falls back to the database, and populates the cache) is the common default but leaves a stale window, so pair it with explicit invalidation on write; write-through keeps the cache consistent at the cost of write latency. Replicate each partition to at least one follower for availability, accept eventual consistency between replicas, and defend the database against a cache stampede with request coalescing or randomised TTL jitter so thousands of keys do not expire simultaneously.
Q: What does the CAP theorem mean for a payments system?
CAP states that a distributed system facing a network partition must choose between consistency and availability - it cannot have both, since partition tolerance is not optional on a real network. Payments generally choose consistency: it is far better to reject or hold a transaction than to allow a double-spend from two partitioned replicas that each believed a balance was sufficient. In practice this means the ledger and balance path runs on a strongly consistent store with synchronous replication and quorum reads, while peripheral concerns like transaction history views, notifications, and analytics can be served from eventually consistent replicas. The refinement worth mentioning is PACELC: even without a partition, you still trade latency against consistency, which is why the write path is deliberately slower than the read path.
Q: Explain a UPI P2P payment in plain language (what PhonePe interviewers probe).
The payer app collects amount and payee VPA, the PSP (PhonePe) validates limits and debits the payer’s bank account via NPCI’s switch, credits the payee’s bank, and returns a definitive success/failure to the app. Settlement between banks happens on NPCI’s schedule - not necessarily at the instant the user sees success. What breaks at scale: ambiguous timeouts (retry vs duplicate), switch cutoffs, and reconciliation when the app state disagrees with bank/NPCI records - so idempotency keys, explicit transaction states, and daily reconciliation jobs are the right talking points.
Q: How would you structure a TODO + analytics machine-coding problem?
Separate models (Task, User), a TaskRepository interface, and a TaskService with commands for create/complete/spill-over. Analytics (completed count, overdue tasks) can use Command objects or a small AnalyticsService so Open/Closed holds when new metrics appear. Store tasks in a ConcurrentHashMap keyed by user or task id; guard state transitions on each task object. Ship a main() that creates tasks, completes some, and prints analytics so the interviewer can run it in 90 minutes.
Frequently asked questions about PhonePe interviews
Does the PhonePe online assessment have negative marking?
No public candidate report mentions negative marking. For software roles the PhonePe OA is mainly 2-4 medium-hard coding problems in 60-90 minutes (some campus tests add about 15 CS MCQs), and the coding questions decide the shortlist.
Which platform does PhonePe use for its online assessment?
Reports conflict. 2025 campus reports name DoSelect with proctoring (August 2025, 90 minutes) and SafeBrowser (July 2025, Mumbai), while older reports and prep sites name HackerRank or CodeSignal. Some SDE-2 loops use a 90-minute CodeSignal machine-coding take-home followed by a 30-minute design review of the same code. Use the platform named in your invite.
What is the PhonePe interview process for freshers?
PhonePe’s process typically runs 4-5 stages: 1. Online Assessment (60-90 min) - 2-3 medium-hard DSA problems (arrays, binary search, trees, graphs, DP). 2. Machine Coding Round (45-60 min) - build a working system from scratch (e.g. a rate limiter or booking system), judged on OOP design, SOLID principles, and whether the code actually runs. 3. Machine Coding Discussion + DSA - the interviewer reviews your design decisions, then adds 1-2 more DSA problems. 4. System Design round - a hard DSA problem followed by a system-design discussion (lighter for SDE-1). 5. Managerial/HR round - behavioral fit, motivation, and offer discussion. Total timeline is roughly 2-3 weeks.
What questions are asked in PhonePe interviews?
Machine coding rounds commonly ask you to build a working rate limiter, booking system, or similar component with clean class design and concurrency/thread-safety handling. DSA rounds mix medium-hard array, graph, tree, and DP problems. System-design questions are frequently pulled from real payment-infrastructure scenarios - transaction retry logic, rate limiting, event-driven architectures, and distributed cache/consistency questions. Domain discussions probe UPI flows and switch design in plain language. Managerial/HR rounds ask about conflict handling, career goals, and salary expectations.
How many rounds are there in the PhonePe interview?
Usually 4-5: an Online Assessment, a Machine Coding round, a combined Machine Coding discussion + DSA round, a System Design round (depth varies by seniority - lighter for SDE-1, heavier for senior engineers), and a closing Managerial/HR round. Some drives compress or merge these depending on role and experience level.
What is the PhonePe technical interview like?
The Machine Coding round (45-60 min) asks you to build a working application end-to-end - candidates report tasks like a fitness-class booking system or a rate limiter - and interviewers dig into object-oriented design, code readability, and test coverage, not just whether it runs. The System Design round pairs one hard DSA problem with a design discussion scoped to payment infrastructure: transaction retries, rate limiting, event-driven flows, or distributed caching (consistency models, eviction policies, replication). Both rounds circle back to your machine-coding submission’s trade-offs in detail.
How should I prepare for PhonePe interviews?
Practice building small working systems end-to-end (not pseudocode) with clean OOP and SOLID principles - PhonePe’s machine coding round grades the actual code, not just the design talk. Revise DSA across arrays, trees, graphs, and DP for the OA and the DSA add-ons. For system design, study payment-infrastructure patterns specifically: retry/idempotency logic, rate limiting, and event-driven architecture, plus distributed caching fundamentals (consistency, eviction, replication). Prepare one detailed project story and concrete answers for the managerial/HR round.
What mistakes do candidates commonly make in PhonePe interviews?
The biggest one is treating machine coding as a coding-speed test rather than a design test - interviewers explicitly probe class structure, SOLID adherence, and thread-safety, not just a working main(). Other common misses: skipping edge cases and concurrency handling under time pressure, and giving generic system-design answers instead of grounding them in payments/transaction scenarios that PhonePe interviewers keep steering toward.
What PhonePe interviewers score
SDE loops are known for a machine-coding / LLD stage plus medium-hard DSA. Interviewers score:
- Compiling, runnable machine-code with modular OOP, SOLID habits, and basic thread-safety where relevant.
- Strong DSA - trees, graphs, DP, windows - with full test-case passes, not partial sketches.
- Payments ownership in the hiring-manager close - conflict handling, reliability mindset, Bengaluru fit.
Soft fail modes: beautiful class diagrams that do not run; DSA that times out; HR stories that never mention correctness when moving money.
What if my PhonePe machine-coding code does not compile?
Public prep guides stress that runnable, demonstrable code is the first gate - interviewers often stop early if the submission does not compile or fails basic cases. Prioritise a thin vertical slice that runs, then add modularity and extension points if time remains.
How to prepare for PhonePe interviews
- Loop map: Online Assessment; Machine Coding Round; Machine Coding Discussion + DSA; System Design Round. Confirm timings from the drive mail.
- Technical depth: Drill the Q&A section until answers are spoken, not read. Know every resume project cold.
- Experiences: Study round-wise notes on the interview experience page - real prompts beat generic lists.
- HR: Three STAR stories + a specific “Why PhonePe?” on the HR page.
A practical PhonePe prep plan
Use this as a default four-week loop before a PhonePe drive. Adjust to your invite timeline.
- Week 1: Language fluency: rewrite 10 old solutions in one language until you stop hunting syntax. Open the PhonePe previous-year sets on this site and mark which sections ate your time. Write the timing on a sticky note. That number is more useful than a 200-problem LeetCode streak you never timed.
- Week 2: Most PhonePe drives fail people on the first timed paper or OA. Do three timed sits this week. After each one, log every miss in a two-column note: topic and why (slow, wrong formula, bad edge case, panic). The next sit should only add problems from that log.
- Week 3: Technical interviews at PhonePe usually want a clean project story, one or two CS fundamentals, and (if the process has it) a behavioral or values round. Write STAR stories on paper, not in your head. Practise “Why PhonePe?” with one concrete product, lab, or business line - not a slogan.
- Week 4: Sleep, id photocopies, and a dry run of the oa platform if the invite names one. If you still have energy, redo only the questions you failed in week 2.
10-day crash version: Days 1-4 timed DSA, days 5-7 resume projects + CS fundamentals, days 8-9 mock interviews out loud, day 10 HR STAR stories on the HR page.
Compensation notes
Candidate-reported fresher/early-career packages for PhonePe often cite SE ₹18-25 LPA. Treat forum numbers as ranges, not guarantees - confirm the written offer letter for your team and location.
Sources
Interview process details and sample questions on this site are editorially organized from public candidate reports and hiring write-ups, with round structure, prep notes, and company-specific framing added by our team. For round-by-round stories, see the PhonePe interview experience page. For OA papers and coding drills, use PhonePe on placementpapers.app. OA quick answers and role-wise questions draw on GfG’s PhonePe interview experiences (on-campus 2023, on-campus 2024, software engineer FTE, online assessment) and 2025 campus snippets from Naukri Code360 (August 2025) and Glassdoor (July 2025) seen via search. The Flipkart separation facts come from PhonePe’s 23 December 2022 press release and TechCrunch’s report of 22 December 2022 (US time).
Also prepare for
Guides often searched alongside this page: Paytm interview questions · Razorpay interview questions · Google interview questions · Amazon interview questions · Flipkart interview questions · CRED interview questions.