Interview experience
PhonePe Interview Questions and Answers (2026)
Overview
Section titled “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.
PhonePe interview process at a glance
Section titled “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 |
Online Assessment
Section titled “Online Assessment”A 60-90 minute timed test on HackerRank or CodeSignal with 2-3 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
Section titled “Machine Coding Round”Build a working application from scratch in the interview - candidates report tasks like a rate limiter or a class-booking system. 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
Section titled “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
Section titled “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
Section titled “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.
Common technical interview questions and answers
Section titled “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.
Frequently asked questions about PhonePe interviews
Section titled “Frequently asked questions about PhonePe interviews”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?
PhonePe typically runs 4-5 touchpoints: 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?
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.