PhonePe Interview Experience
📝 1. Application Process
How did you apply? On-Campus placement drive
Timeline:
Application Date: 1/08/2026
Online Assessment Date: 03/08/2026
Interview Date: 04/08/2026
Note: Around 500+ students appeared for the Online Assessment. The shortlisting criteria was an AMCAT Automata score of ~55.
Interviews were scheduled based on OA rank — candidates with the highest OA scores were interviewed first. There were 9 parallel panels, each interviewing one candidate at a time.
💻 2. Online Assessment (OA)
The OA had 4 problems, worth a total of 340 points — two questions worth 70 points each and two worth 100 points each. The goal was to maximize your total score; you didn't need to solve everything perfectly to do well, but the higher-weighted questions mattered more.
Time Limit (each): 1 second | Memory Limit (each): 256 MB
Full OA questions (with constraints & examples): View on Google Drive
Difficulty Level: Medium–Hard
My Experience:
I managed to fully solve 1 of the 4 problems, while for the other 3 problems I was able to solve almost all of the test cases, with only around 3-4 test cases remaining unsolved on each. I ended up with a total score of around 246/340. The minimum cutoff to qualify for interviews was around 160/340.
The questions were genuinely Codeforces-like and hard. The biggest challenge was that they were not standard problems where you could immediately identify a familiar pattern and apply a known solution.
For me, the most important thing during the OA was not panicking and staying calm. You had to read the problem carefully, think about the solution, implement it, and then debug it very quickly.
A lot of my friends who were actually very strong at competitive programming failed to get shortlisted because they panicked during the OA. So I genuinely believe that keeping a calm mind and having confidence in your ability is one of the biggest differentiators in an OA like this.
🎤 3. Interview Rounds
🧩 Round 1: Technical Interview (DSA)
Type: Coding
Duration: 1 hour
Questions:
1. Russian Doll Envelopes
I was already familiar with this problem. My first approach was a greedy one where I sorted the envelopes by height ascending and width ascending.
The interviewer gave me a test case where this approach failed. I then realized the issue with the sorting and explained the standard optimal approach: sort by height ascending and width descending, and then find the LIS of the widths.
I explained why the width has to be sorted in descending order when the heights are equal and proved the intuition by dry-running the approach on a couple of test cases.
This gives the optimal O(N log N) solution.
The interviewer seemed to initially be expecting a brute-force O(N²) approach. I told him that I could implement that approach as well, but since I knew the optimal solution, I explained why my approach was better.
He then asked me to write the code for the optimal solution. After that, he asked me to explain the code line by line and dry-run it again using a test case.
Finally, he asked me for the time and space complexity. He seemed happy with the approach, so we moved on to the next question.
2. Minimum Time to Reach Target with Limited Power
I had seen similar questions multiple times in LeetCode contests, so I was familiar with the general idea.
My initial approach was to first find the minimum time and then use binary search to find the maximum power. This approach worked within the given constraints.
The interviewer told me that this approach would work but that they were expecting a different approach. He asked me to think about finding both the minimum time and power together.
After thinking about it, I came up with a DP-based approach where, for each node, we maintain the minimum time for every possible power level. Essentially, this results in a 2D DP array.
He asked me to dry-run my approach, after which he asked me to write the complete working code, including all declarations.
Once I finished coding, he asked me about the time and space complexity. He seemed satisfied with how I approached the problem and with the final solution.
Difficulty Level: Medium
My Experience:
I had already seen both types of questions before, so the main challenge in this round was not simply solving them, but explaining my thought process and arriving at the solution the interviewer was looking for.
As soon as the interviewer explained a problem, I would first ask for the constraints. I would then think about what time complexity those constraints would allow and mention that out loud.
I also made sure I was never completely silent while thinking. Even when I was figuring something out, I continuously explained what I was considering, why I was making a particular decision, and why I was moving toward one approach instead of another.
Another important thing was to listen carefully to the interviewer. Interviewers often give subtle hints about the type of solution they expect. Even if your solution works and is reasonably optimized, you need to be dynamic and understand what they are trying to guide you toward.
At the end of the interview, I asked the interviewer two questions about PhonePe.
Biggest takeaway:
Dry-running your code and explaining your thought process out loud, even the small things, are probably the most important skills for this style of interview.
👔 Round 2: HM Round (Behavioral + System Design + Technical)
In my case, this round happened right after Round 1 and before Round 3 — though for some other candidates, it was scheduled after Round 3 instead. Panels seemed to mix up the order depending on scheduling.
Type: Managerial / System Design / Behavioral
Duration: ~1 hour
Overall Experience
This was actually the round I was most worried about, mainly because I had failed similar rounds in the past. Because of that, I had prepared for this round quite a lot.
Fortunately, the HM was a very calm person. He helped me relax, which made me feel much more comfortable during the interview.
The round started with a brief introduction and then moved into a discussion around one of my projects.
📌 Project Discussion
He first asked me to introduce myself. After that, he immediately told me that I should select a project from my resume — either a personal project or an internship project — that I was particularly proud of and explain it to him.
Interestingly, this was basically the only thing he asked me directly from my resume. Almost everything else in the interview was outside my resume.
I explained my project, including:
Why I built it
What it does
How it works
How it could potentially help people in their daily lives
After understanding the project, he started going deeper into the technical side.
🤖 RAG & System Design
Based on my project, He asked me to explain the internal working of RAG, including how vector embeddings work internally.
He then asked me to create a high-level system design diagram for my project.
I drew the architecture and explained:
The different components
How the components interact
How data flows through the system
Why I had designed it that way
After the project and system-design discussion, we moved into the behavioral part of the interview.
🧠 Behavioral Questions
The behavioral questions took up the majority of the interview.
From the questions, I felt that he was trying to understand whether I was someone who:
Thinks from first principles
Is genuinely curious
Takes responsibility
Is self-aware
Takes initiative
Can handle difficult real-world situations
So while answering the questions, I tried to make sure that my actual experiences highlighted these qualities.
🚨 Handling a Production Failure
One question was about what I would do if the project I had worked on became a product used by a large number of people and it suddenly failed at midnight.
I explained the different things I would do — first trying to personally understand and resolve the issue, then involving whoever from my team could help, coordinating with them, identifying the root cause, and working toward restoring the service.
I talked quite a lot during this question because I tried to explain how I would actually approach the situation rather than just giving a one-line answer.
🤝 Conflict During Internship
He then asked me whether I had ever experienced a conflict while working during my internship.
I told him about a situation where I had a disagreement with a senior at the company regarding an approach.
Instead of immediately arguing for my solution, I listened to his reasoning, tried his approach, and separately tested my own approach. When my approach performed better, I explained the results to him and eventually convinced him to implement my solution.
From the interviewer's expressions, I felt that he was impressed by the fact that I was able to convince a senior using reasoning and evidence rather than simply arguing.
🔍 Curiosity & Learning
He then asked me whether there was something I had learned simply because I was curious about how the technology worked.
I understood that he was testing my curiosity and willingness to learn beyond what was required.
I told him about how blockchain technology fascinated me, so I independently learned about it through YouTube.
I explained what initially interested me, what I found fascinating, and what I learned from exploring the technology.
I ended up explaining the entire working of blockchain, followed by some of its applications.
He seemed happy with my answer.
🪞 Self-Awareness & Improvement
He then asked me whether there was any quality that one of my friends had that I wished I had.
I thought about this for around 10 seconds and decided to talk about a friend who is extremely good at public speaking and socializing.
I told him that I wished I was as good as my friend in that area.
However, I didn't stop there. I wanted to show that I was self-aware but also actively working on my weaknesses.
I explained that I had been consciously trying to improve my communication skills. For example, whenever teachers asked if someone was interested in presenting in front of the class, I would volunteer.
I also started taking initiative myself and asking teachers for opportunities to speak.
Another example I gave was that I had conducted sessions for juniors where I taught them DSA.
The point I wanted to convey was that I was aware of my weakness, but instead of simply accepting it, I was actively taking steps to improve.
The interviewer seemed impressed with this answer.
📱 PhonePe Feature & System Design
After that, he asked me to name a PhonePe feature that I liked.
I honestly told him that I don't use PhonePe and primarily use GPay.
I wouldn't necessarily recommend giving this answer — I said it because I was very much in the zone of the interview and simply wanted to be honest.
He then asked me to name a GPay feature that I liked.
I told him that I really liked the Autopay feature.
Interestingly, he was actually the person who had been the lead for the Autopay feature at PhonePe.
So he immediately asked me how I thought the Autopay feature could work internally.
I explained how I thought it might be implemented, including the use of queues and different components for handling scheduled transactions.
I used diagrams to explain my thought process and walked him through how I would design the system.
He seemed happy with my answer.
At the end of the interview, I asked him questions about working at PhonePe and how an intern could contribute to the actual product.
Difficulty Level: Medium
Biggest Takeaway:
Be as honest as possible, stay calm, and frame your answers in a way that highlights the qualities the interviewer is looking for.
A lot of students genuinely have qualities like curiosity, ownership, self-awareness and initiative, but their answers don't necessarily reflect those qualities.
You don't need to make up stories. Instead, think about your actual experiences and present them in a way that demonstrates those qualities.
🧩 Round 3: Technical Interview (DSA)
Type: Coding
Duration: 1 hour
Questions:
1. Greatest Common Divisor Traversal
This question was new to me before the interview, although I had seen a similar problem during Round 1.
My first approach was to use DSU and consider pairs of elements. The interviewer then asked me to optimize it.
I realized that we could factorize the numbers and use their factors to construct the DSU connections. My initial optimized approach was to find the factors of each number in O(N√N).
The interviewer was okay with this approach and asked me to code it.
However, after that, he told me that he wanted an even better solution.
At this point I was getting a little nervous, but I tried to stay focused and think through the problem instead of panicking.
I remembered the concept of Smallest Prime Factor (SPF), which allows us to factorize numbers much more efficiently.
I explained this idea to him and then coded the SPF sieve.
He asked me to dry-run how the SPF approach would work once, after which we moved on to the next question.
2. Largest Color Value in a Directed Graph
I got the intuition of using topological sorting + DP almost immediately.
I approached the problem step by step.
First, I explained that we need to determine whether the graph contains a cycle. If there is a cycle, we return -1.
If the graph is a DAG, we can use DP during the topological traversal.
I initially explained the solution for one alphabet and then explained that we can extend the same idea to all the other alphabets.
We maintain the DP information for every node and update the color counts as we process the graph using topological sorting.
I dry-ran the approach and then the interviewer asked me to code it.
I implemented the optimal acceptable solution.
Since we still had some time, the interviewer asked whether I could detect the cycle directly within the DP/topological approach.
I thought through an approach and explained what I had in mind. The intended solution involved using two visited arrays, which I wasn't initially aware of in that particular formulation.
The interviewer said that my existing solution was good enough, and since we still had some time, we moved on to another question.
3. Partition Array Into Two Arrays to Minimize Sum Difference
I immediately recognized this as a meet-in-the-middle problem from the constraints.
I had not solved many problems of this exact pattern before.
I initially explained a DP-based solution, but the interviewer told me that they were looking for a more optimized approach.
I was able to solve around 90% of the problem with some hints, eventually getting toward the meet-in-the-middle and binary-search intuition.
However, by that point, the time was almost over.
The interviewer told me that this question was not going to be used to evaluate me and that they had only asked it because we had some extra time.
I did not code this question; I only explained my approach and the direction I would take.
At the end i asked them a question about working at phonpe.
Difficulty Level: Medium–Hard
My Experience:
This round was a bit harder than Round 1 because the questions were not the standard problems I had practiced.
I had to converse with the interviewer quite a lot and take some hints during the problems.
The biggest thing that helped me was staying calm.
Even when I didn't immediately know the solution, I kept talking to the interviewer and explained what I was thinking. Eventually, one idea would lead to another and help me move closer to the solution.
I think this is one of the most important things in a technical interview: don't shut down when you don't know something immediately.
You don't necessarily need to know the solution instantly. Show the interviewer how you think, use the hints they give you, and keep exploring the problem.
4. Overall Experience and Tips
Overall Interview Experience:
The overall experience was very positive and fun, but intensive as well.
The OA required you to stay calm and solve as many test cases as possible. The questions were difficult and not necessarily standard patterns, so the ability to think under pressure was extremely important.
The technical DSA interviews tested whether you could find the most optimal solution, but more importantly, whether you actually understood the approach you were using — why it worked, what its complexity was, and how you arrived at it.
The HM round was different. It tested whether I could think from first principles, reason about real-world scenarios, demonstrate curiosity and ownership, and whether I would be a good fit for the company.
What to prepare?
Strong DSA fundamentals
Focus heavily on:
DP
Graphs
Trees
Binary Search
DSU
You should not only know the standard patterns but also be comfortable with unfamiliar variations of them.
System Design
Know the basics of high-level system design and, especially, understand the trade-offs between different approaches.
For projects, don't just know what your system does. Know:
Why you chose a particular architecture
Why you selected a particular database
How your components communicate
How you would scale it
What bottlenecks exist
What you would change if the number of users increased significantly
What happens when individual components fail
Competitive Programming
I strongly recommend giving LeetCode and Codeforces contests.
The main benefit is not just learning more algorithms. Contests teach you how to perform under time constraints and pressure, which can be a major differentiator in an OA.
If you feel your logical problem-solving is weak, try Codeforces because it forces you to develop that ability.
If you already have good logical ability, solving LeetCode Hard problems can be useful because many interview questions can be close to that difficulty level.
Some resources I personally recommend:
TLE Sheet
CSES Problem Set
Striver Sheet
Practice Explaining
Solving problems yourself is not enough.
Try doing mock interviews with seniors or friends.
The goal is to practice:
Explaining your approach before coding
Thinking out loud
Dry-running your solution
Explaining why your approach works
Discussing time and space complexity
Responding to hints
Handling cases where your first approach fails
This helps you identify gaps in your communication and reasoning.
Behavioral Questions
Prepare answers for the standard behavioral questions, but don't memorize a fixed script.
Instead, prepare several real experiences from your life that you can dynamically use for different questions.
Think about situations involving:
Conflict
Failure
Leadership
Ownership
Curiosity
Teamwork
The same experience can often be used to answer multiple behavioral questions if you frame it appropriately.
Projects and Internship
Know everything you have written on your resume.
Be prepared to explain:
Why you built the project
Why you chose the technologies
How the architecture works
Database design
Scaling
Failure scenarios
Trade-offs
Don't put something on your resume just because it sounds impressive. If it is there, assume the interviewer can ask you anything about it.
Final Advice
Throughout the entire process, there were many moments when I got nervous and started doubting myself.
There were times when I thought:
"Maybe I won't get selected."
"Maybe I messed up that question."
"Maybe the interviewer wasn't satisfied with my answer."
The key is to stay calm and maintain a positive mindset.
You have already put in the work. At that point, you need to trust your preparation and yourself.
Even if you mess up one question, don't let that affect the next question.
The interviewer isn't looking for a perfect candidate who knows everything and never makes mistakes.
They are looking for someone who is a good problem solver, communicates well, learns from hints, thinks logically, takes ownership, and is a good fit for the company.
So if something goes wrong during an interview, don't keep thinking about it.
Stay calm, reset, and focus on what comes next.
Believe in the work you have put in.
Verdict: Selected (Intern) ✅
Feel free to reach out to me on LinkedIn for any queries: linkedin.com/in/siddharthwagh21