Phonepe Software Engineer Interview Guide

The 60-second brief

A Software Engineer at PhonePe works at the heart of India's digital payments revolution, building and scaling systems that handle hundreds of millions of transactions daily. The engineering team is responsible for designing, developing, and maintaining high-throughput, low-latency APIs and microservices that power seamless financial transactions, merchant payments, and wealth management services. In this role, your impact is immediate and highly visible. You will contribute to core transactional systems where even a millisecond of latency or a minor bottleneck can affect millions of active users. SDEs at PhonePe do not just write code; they take complete end-to-end ownership of their services, from initial design and concurrency handling to production deployment, monitoring, and database optimization.

This guide is scoped to a Software Engineer candidate at Phonepe.

Focus areas

• Data Structures & Algorithms (DSA)
• Problem Solving
• SQL

The Phonepe interview process

Phonepe candidates report 5 rounds over 4-6 weeks. The stages below are what candidates describe, not a published process.

Online Assessment

Candidates complete coding challenges and fundamental computer science questions.

What to demonstrate

• Candidates complete coding challenges and fundamental computer science questions
• Depth in Data Structures & Algorithms (DSA)

How to prepare

• Answer aloud and timed: Solve the minimum coins problem using dynamic programming and discuss its time complexity.
• Answer aloud and timed: Given an N x N matrix and a variable K specifying how many times you can change a letter, find the lexicographically smallest word.

Machine Coding Round

A technical round focused on hands-on coding skills.

What to demonstrate

• A technical round focused on hands-on coding skills
• Depth in Data Structures & Algorithms (DSA)

How to prepare

• Answer aloud and timed: Implement a solution to balance the coins in a binary tree, where each node must end up with exactly one coin.
• Answer aloud and timed: Solve a path-finding problem on a grid using a modified Breadth-First Search (BFS) or Dijkstra's algorithm.

Deep-Dive DSA Interviews

Interviews that focus on data structures and algorithms.

What to demonstrate

• Interviews that focus on data structures and algorithms
• Depth in Data Structures & Algorithms (DSA)

How to prepare

• Answer aloud and timed: Implement a solution to find the longest substring with exactly K unique characters.
• Answer aloud and timed: Design a split-wise expense-sharing application with support for unequal splits and balance simplification.

System Design Discussion

Candidates engage in discussions about system design and architecture.

What to demonstrate

• Candidates engage in discussions about system design and architecture
• Depth in Data Structures & Algorithms (DSA)

How to prepare

• Answer aloud and timed: Design a multiplayer Snake and Ladder game ensuring clean abstraction, modularity, and extensibility.
• Answer aloud and timed: Design a scalable Parking Lot system supporting multiple vehicle types, spot allocations, and fee calculations.

Final Hiring Manager Round

The last round with the hiring manager to assess overall fit and readiness.

What to demonstrate

• The last round with the hiring manager to assess overall fit and readiness
• Depth in Data Structures & Algorithms (DSA)

How to prepare

• Answer aloud and timed: Design an online Battleship game, ensuring clear separation of concerns and executable business logic.
• Answer aloud and timed: Design a Customer Issue Resolution System that assigns tickets to support agents based on expertise and availability.

Where candidates lose points

Focus on Executable Code

In the machine coding round, a partially working but highly elegant design is often evaluated less favorably than a fully functional, executable system. Prioritize getting your core business logic running first, then refactor for design patterns and clean abstraction.

Think Out Loud During DSA

SDE interviewers at PhonePe value your problem-solving process. Avoid jumping straight to coding; instead, explain your brute-force approach, discuss its limitations, and walk the interviewer through your optimization steps.

Master Concurrency Concepts

Given the transactional nature of fintech systems, interviewers frequently ask follow-up questions about thread safety, database locking, and race conditions. Be ready to explain how your designs handle concurrent requests safely.

Questions & practice

Solve the minimum coins problem using dynamic programming and discuss its time complexity.

Medium · Data Structures & Algorithms (DSA)

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Given an N x N matrix and a variable K specifying how many times you can change a letter, find the lexicog

Medium · Data Structures & Algorithms (DSA)

Given an N x N matrix and a variable K specifying how many times you can change a letter, find the lexicographically smallest word.

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Implement a solution to balance the coins in a binary tree, where each node must end up with exactly one coin.

Medium · Data Structures & Algorithms (DSA)

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Solve a path-finding problem on a grid using a modified Breadth-First Search (BFS) or Dijkstra's algorithm.

Medium · Data Structures & Algorithms (DSA)

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Implement a solution to find the longest substring with exactly K unique characters.

Medium · Data Structures & Algorithms (DSA)

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Explain how you would implement database locking (optimistic vs. pessimistic) to prevent race conditions in a

Medium · High-Level Design & System Architecture

Explain how you would implement database locking (optimistic vs. pessimistic) to prevent race conditions in a payment system.

Approach

1. Say what the runtime actually does before reasoning about the code.
2. Name what is shared across threads and what owns each piece of state.
3. Identify the window where an invariant is briefly untrue.
4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

• What happens if two callers reach this at the same time?
• Where could this allocate more than you expect?

Explain how Java handles concurrent execution using threads, and how thread synchronization works under the ho

Medium · Databases, Operating Systems, & Networki

Explain how Java handles concurrent execution using threads, and how thread synchronization works under the hood.

Approach

1. Say what the runtime actually does before reasoning about the code.
2. Name what is shared across threads and what owns each piece of state.
3. Identify the window where an invariant is briefly untrue.
4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

• What happens if two callers reach this at the same time?
• Where could this allocate more than you expect?

Write a complex SQL query utilizing window functions (like DENSE_RANK) and multiple joins to retrieve transa

Medium · Databases, Operating Systems, & Networki

Write a complex SQL query utilizing window functions (like DENSE_RANK) and multiple joins to retrieve transaction statistics.

Approach

1. Name the grain you start from and join outward from it.
2. Check whether any join is one-to-many before aggregating, or the sums inflate.
3. Say which index the query would use, and what makes it unusable.
4. Handle the rows that do not match: that is usually the actual question.

Follow-up

• How does the query change if that join becomes one-to-many?
• What happens to this when the table is ten times larger?

What are the primary differences between SQL and NoSQL databases, and how do you choose between them for a led

Medium · Databases, Operating Systems, & Networki

What are the primary differences between SQL and NoSQL databases, and how do you choose between them for a ledger service?

Approach

1. Name the grain you start from and join outward from it.
2. Check whether any join is one-to-many before aggregating, or the sums inflate.
3. Say which index the query would use, and what makes it unusable.
4. Handle the rows that do not match: that is usually the actual question.

Follow-up

• How does the query change if that join becomes one-to-many?
• What happens to this when the table is ten times larger?

Why do you want to join PhonePe, and how do you think your skills align with the scale of our fintech platform

Medium · Behavioral & Project Walkthroughs

Why do you want to join PhonePe, and how do you think your skills align with the scale of our fintech platform?

Approach

1. Name the grain you start from and join outward from it.
2. Check whether any join is one-to-many before aggregating, or the sums inflate.
3. Say which index the query would use, and what makes it unusable.
4. Handle the rows that do not match: that is usually the actual question.

Follow-up

• How does the query change if that join becomes one-to-many?
• What happens to this when the table is ten times larger?

Design a split-wise expense-sharing application with support for unequal splits and balance simplification.

Medium · Low-Level Design & Machine Coding

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Design a multiplayer Snake and Ladder game ensuring clean abstraction, modularity, and extensibility.

Medium · Low-Level Design & Machine Coding

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Design a scalable Parking Lot system supporting multiple vehicle types, spot allocations, and fee calculations

Medium · Low-Level Design & Machine Coding

Design a scalable Parking Lot system supporting multiple vehicle types, spot allocations, and fee calculations.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Design an online Battleship game, ensuring clear separation of concerns and executable business logic.

Medium · Low-Level Design & Machine Coding

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Design a Customer Issue Resolution System that assigns tickets to support agents based on expertise and availa

Medium · Low-Level Design & Machine Coding

Design a Customer Issue Resolution System that assigns tickets to support agents based on expertise and availability.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Design a highly scalable transaction ledger system that guarantees consistency and prevents double-spending.

Medium · High-Level Design & System Architecture

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Design a real-time notification service capable of dispatching millions of push notifications, SMS, and emails

Medium · High-Level Design & System Architecture

Design a real-time notification service capable of dispatching millions of push notifications, SMS, and emails concurrently.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Propose an architecture for a Google News-style feed aggregator, focusing on data ingestion, caching, and low-

Medium · High-Level Design & System Architecture

Propose an architecture for a Google News-style feed aggregator, focusing on data ingestion, caching, and low-latency retrieval.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Design a rate limiter for PhonePe APIs to prevent abuse while ensuring high availability for legitimate users.

Medium · High-Level Design & System Architecture

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Explain the difference between TCP and UDP, and how PhonePe ensures reliable transaction delivery over lossy n

Medium · Databases, Operating Systems, & Networki

Explain the difference between TCP and UDP, and how PhonePe ensures reliable transaction delivery over lossy networks.

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

Describe the seven layers of the OSI model and explain how a packet travels from a mobile app to a backend ser

Medium · Databases, Operating Systems, & Networki

Describe the seven layers of the OSI model and explain how a packet travels from a mobile app to a backend server.

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

Walk me through the most technically challenging project on your resume, detailing your specific contributions

Medium · Behavioral & Project Walkthroughs

Walk me through the most technically challenging project on your resume, detailing your specific contributions and architectural decisions.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Describe a situation where you had to debug a critical production issue under tight time pressure. What was yo

Medium · Behavioral & Project Walkthroughs

Describe a situation where you had to debug a critical production issue under tight time pressure. What was your approach?

Approach

1. Establish what changed and when, before forming any theory.
2. Pick a bisection that eliminates candidates whichever way it turns out.
3. Check the instrumentation before believing the symptom.
4. Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

• What would you look at first, and what would it rule out?
• How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics Phonepe candidates report.

Day 1 — Map the Phonepe loop

• Write out the reported sequence: Online Assessment, Machine Coding Round, Deep-Dive DSA Interviews, System Design Discussion, Final Hiring Manager Round.
• For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 5 reported rounds, with the weakest marked.

Day 2 — Work Data Structures & Algorithms (DSA)

• Spend the session on Data Structures & Algorithms (DSA), which Phonepe candidates report being tested on.
• Write one worked example in Data Structures & Algorithms (DSA) and time yourself on it.

Deliverable: One timed worked example in Data Structures & Algorithms (DSA).

Day 3 — Work Problem Solving

• Spend the session on Problem Solving, which Phonepe candidates report being tested on.
• Write one worked example in Problem Solving and time yourself on it.

Deliverable: One timed worked example in Problem Solving.

Day 4 — Work SQL

• Spend the session on SQL, which Phonepe candidates report being tested on.
• Write one worked example in SQL and time yourself on it.

Deliverable: One timed worked example in SQL.

Day 5 — Answer out loud: Data Structures & Algorithms (DSA)

• Answer aloud, timed: Solve the minimum coins problem using dynamic programming and discuss its time complexity.
• Answer aloud, timed: Given an N x N matrix and a variable K specifying how many times you can change a letter, find the lexicographically smallest word.

Deliverable: Spoken answers to 2 reported Data Structures & Algorithms (DSA) question(s), under time.

Day 6 — Answer out loud: Low-Level Design & Machine Coding

• Answer aloud, timed: Design a split-wise expense-sharing application with support for unequal splits and balance simplification.
• Answer aloud, timed: Design a multiplayer Snake and Ladder game ensuring clean abstraction, modularity, and extensibility.

Deliverable: Spoken answers to 2 reported Low-Level Design & Machine Coding question(s), under time.

Day 7 — Answer out loud: High-Level Design & System Architecture

• Answer aloud, timed: Design a highly scalable transaction ledger system that guarantees consistency and prevents double-spending.
• Answer aloud, timed: Design a real-time notification service capable of dispatching millions of push notifications, SMS, and emails concurrently.

Deliverable: Spoken answers to 2 reported High-Level Design & System Architecture question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

How do you handle conflict or technical disagreements with senior engineers or product managers regarding syst

Medium · Behavioral & Project Walkthroughs

How do you handle conflict or technical disagreements with senior engineers or product managers regarding system design?

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

Give an example of an automation or system optimization you proactively drove in your previous organization.

Medium · Behavioral & Project Walkthroughs

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

• What would you do differently in the first five minutes, given the same dashboard and no more information?
• Which follow-up action did you deliberately not take, and why was dropping it the right call?