Last checked against official sources: 9 October 2026.
PhonePe does not publish its interview questions or a fixed sequence of rounds, and we could not find an interview format described on the PhonePe careers site. What PhonePe does publish is a good deal of engineering writing on the PhonePe tech blog. That gives a software engineer something better than rumour: a view of the problems the company's own engineers write about.
This guide gives you practice questions in the areas a payments platform naturally cares about — correctness under concurrency, idempotency, rate limiting and data at scale — with worked answers. The questions are ours. They are not a claim about what PhonePe will ask you, and the success stories, salary figures and transaction statistics in an earlier version of this article have been removed because we could not verify them.
First, confirm your actual process
Apply through the current openings page or your campus placement cell. When an invitation arrives, note the format (online test, live coding, design discussion or managerial conversation), the duration and the platform. If a recruiter tells you the rounds, prepare for those. If not, prepare for the four practice areas below, which cover the usual shape of a product-company software interview.
Keep preparing
Continue with Top 50 Interview Questions₹299 — coaching के एक महीने से काफ़ी सस्ता / far cheaper than a month of coachingWhat the tech blog tells you
A few posts are useful reading before a design round, because they show how PhonePe's engineers frame trade-offs:
- The Kafka Edge: Managing 100 Billion Daily Events at PhonePe (October 2023) describes a disk-first ingestion path for analytics events, separate Kafka clusters for writes and reads, and a single capacity score per cluster based on disk, disk I/O, CPU and network usage.
- Powering Real-Time Decisions with PhonePe's Garfield Platform and Apache Druid (November 2025) covers real-time analytics.
- Beyond IaC (April 2026) discusses verifying what is actually running in production.
Don't memorise numbers from these posts to repeat in an interview. Use them to practise explaining a trade-off — for example, why a team might accept a few seconds of latency for analytics events in exchange for durability and lower load on the message brokers. If you mention a post, make sure you understood it.
Practice area 1: coding
Implement an LRU cache
Prompt: Build a cache with a fixed capacity that supports get and put in O(1) time and evicts the least recently used key when full.
Worked answer: combine a hash map (key to node) with a doubly linked list ordered by recency. On get, move the node to the front. On put, update or insert at the front, and if the size exceeds capacity, remove the node at the back and delete its key from the map. In Python you can show the idea quickly with collections.OrderedDict:
from collections import OrderedDict
class LRUCache:
def __init__(self, capacity: int):
self.capacity = capacity
self.data = OrderedDict()
def get(self, key):
if key not in self.data:
return -1
self.data.move_to_end(key)
return self.data[key]
def put(self, key, value):
if key in self.data:
self.data.move_to_end(key)
self.data[key] = value
if len(self.data) > self.capacity:
self.data.popitem(last=False)
Here the most recently used key sits at the end and popitem(last=False) evicts from the front. Then offer to write the linked-list version, because many interviewers want to see the pointer handling.
Top merchants by payment value
Prompt: Given a table payments(id, merchant_id, amount, status, created_at), return the five merchants with the highest total successful payment value yesterday.
SELECT merchant_id, SUM(amount) AS total_value
FROM payments
WHERE status = 'SUCCESS'
AND created_at >= CURRENT_DATE - INTERVAL '1 day'
AND created_at < CURRENT_DATE
GROUP BY merchant_id
ORDER BY total_value DESC
LIMIT 5;
This is PostgreSQL syntax. Point out the half-open date range, which avoids missing or double-counting rows at midnight; that failed payments are excluded; and that an index covering created_at and status would help on a large table.
Practice area 2: idempotency
Prompt: "A user taps Pay twice because the network is slow. How do you make sure they are charged once?"
Worked answer: the client generates a unique idempotency key for the payment attempt and sends it with every retry. The server stores the key with the outcome under a unique constraint. When a duplicate arrives, the server returns the stored result instead of processing the payment again. Cover the edge case too: if the first request is still in progress, the duplicate should wait or get an "in progress" response rather than start a second payment. You can add that POST is not an idempotent method under RFC 9110, which is why the key is needed.
Practice area 3: concurrency and consistency
Prompt: "Two requests try to debit the same wallet at the same moment. How do you stop the balance going negative?"
Worked answer: make the check and the debit one atomic step. Options include a conditional update such as UPDATE wallets SET balance = balance - :amt WHERE id = :id AND balance >= :amt, followed by checking that exactly one row changed; a row lock inside a transaction; or optimistic locking with a version column and a retry. Then talk about the ledger: record every debit and credit as an immutable entry so balances can be reconciled later. Interviewers usually care more about your reasoning about race conditions than about one "right" mechanism.
Practice area 4: rate limiting and design
Prompt: "Design a rate limiter that allows each user a fixed number of payment requests per minute."
Worked answer: describe a token bucket. Each user has a bucket of N tokens refilled at a steady rate; each request takes a token or is rejected with HTTP 429. Across many servers, keep the counters in a shared store with atomic increments and expiry. Discuss what happens if that store is down — fail open for low-risk endpoints, fail closed for sensitive ones — and how you would stop one very busy key from overloading a single node.
For a fuller treatment of concurrency, retries and reservations, read our system design interview guide.
Worked example: a three-week plan for a working engineer
This plan is illustrative and assumes about 90 minutes of practice on weekdays.
| Week | Weekdays | Weekend |
|---|---|---|
| 1 | Arrays, hashing, two pointers and the LRU cache; one SQL aggregation query a day | Timed mock: two coding problems in 60 minutes |
| 2 | Idempotency, transactions and locking; redraw the riskiest write path in your own project | One full design: a payment request flow from end to end |
| 3 | Rate limiting, queues and caching; read two tech-blog posts and summarise each trade-off in five lines | Mock interview with a friend, including "tell me about your project" |
The behavioural part
Expect questions about ownership and incidents, such as "Tell me about a production issue you handled" or "Describe a time you pushed back on a deadline." Use real examples in STAR form. Our behavioural interview guide shows how to build an example portfolio you can adapt.
Final checklist
- Confirm the rounds and format from your invitation, not from forums.
- Be able to code an LRU cache and a clean SQL aggregation without help.
- Explain idempotency keys, atomic debits and token buckets in plain words.
- Read two PhonePe tech-blog posts and be ready to discuss one trade-off.
- Prepare three true stories about ownership and incidents.