📱 PhonePe Mobile Engineer Interview Experience (2026)

My experience interviewing with PhonePe across DSA, React-Native, Machine Coding, and Mobile System Design.

Over the last few months, I interviewed with multiple product companies, but among all of them, PhonePe’s interview process felt the most transparent and well-structured.

The journey started with a LinkedIn application, and I also requested one of my friends working at PhonePe for a referral.

To my surprise, I received a recruiter call the very next day.

The recruiter first discussed my previous experience, explained the complete interview process, and walked me through each round in detail. What I appreciated most was that there were no surprises later in the process — I already knew what to expect from every stage.

🔓 Not a Medium member? ***Read here for free***

Since the first round was DSA and I honestly wasn’t well prepared at that time, I requested at least a week’s time before scheduling it. The recruiter completely understood my situation and happily accommodated my request.

The interview process looked like this:

• 🧩 DSA Round (Qualifying)
• 📱 JavaScript, React-Native & Mobile Engineering
• 💻 Machine Coding
• 🏗️ Mobile System Design (Most Important)
• 👨‍💼 Hiring Manager Discussion

I really liked this approach because the expectations were clear right from the beginning, which helped me prepare accordingly.

🧩 Round 1 — DSA (Qualifying)

The interviewer started by introducing himself and explaining what he works on at PhonePe. After a brief introduction from my side, he explained the interview format.

There would be two DSA questions, both expected to be of medium to hard difficulty.

Question 1

Problem: Given a binary tree and one disease-infected node, find the minimum time required to infect the entire tree.

A node could infect only its parent and immediate children.

My Thought Process

I started by thinking out loud. My initial thought was to identify an optimal node somewhere near the middle of the tree so that the infection could spread in the minimum time.

The interviewer immediately pointed out that the infected node was already given in the problem statement, so there was no need to search for it.

That saved me from going in the wrong direction early.

Once that was clarified, I explained that we could start a Breadth-First Search (BFS) directly from the infected node.

However, there was one challenge.

Since a tree node normally has references only to its children, BFS alone wouldn’t allow us to move back to the parent.

To solve this, I suggested performing an in-order DFS first to store the parent reference for every node. Once every node knew its parent, the BFS could freely move in all three directions:

• Left child
• Right child
• Parent

While discussing the solution, I also realized that we must maintain a visited set. Otherwise, once parent references are introduced, the traversal would keep revisiting nodes and create an infinite loop.

After agreeing on the overall approach, the interviewer asked me to write pseudocode for:

• Building the parent mapping using DFS
• Performing the BFS traversal

Finally, we discussed the time and space complexity before moving on to the next question.

💡 What I Learned

One thing I liked about this round was that the interviewer wasn’t trying to trap me.

Whenever my thought process started moving in an unnecessary direction, he nudged me back with small hints instead of letting me waste several minutes.

It also reinforced an important interview lesson for me:

Think out loud.Even if your first approach isn’t perfect, explaining your reasoning gives the interviewer an opportunity to guide you in the right direction.

Question 2

Problem: Find the nearest palindrome to a given number.

The answer could be either greater than or smaller than the given number.

My Thought Process

My initial approach was fairly straightforward.

I suggested writing a helper function to check whether a number is a palindrome and then checking numbers on both sides until we found one.

Although this approach would work for smaller numbers, we quickly discussed that it wouldn’t scale well for larger inputs and could easily run into time limit issues.

The interviewer then gave me a hint:

“Try thinking about it mathematically instead of checking every possibility.”

Honestly, I struggled for a while.

Even after a couple of hints, I couldn’t immediately see the pattern.

Eventually, the mathematical approach clicked, and I was able to derive the solution.

The discussion didn’t stop there.

The interviewer also asked me to justify why the approach worked mathematically instead of simply implementing it.

After proving the reasoning, we discussed the time complexity and wrapped up the interview.

Before ending the call, he also asked if I had any questions for him.

💡 What I Learned

This question reminded me that many hard DSA problems aren’t about writing clever code.

They’re about identifying the underlying mathematical observation first.

Without that observation, even the best implementation won’t help.

📱 Round 2 — JavaScript, React-Native & Mobile Engineering

The recruiter called me the very next day and informed me that the feedback from the DSA round was positive. We then scheduled the second interview three days later.

Unfortunately, on the day of the interview, I was at my hometown and was facing network connectivity issues. The interviewer politely suggested rescheduling the interview instead of continuing with an unstable connection. He also informed the recruiter himself, which I really appreciated.

The rescheduled interview started with a brief introduction from both sides, followed by a discussion about my previous experience and the projects I had worked on.

The conversation then moved into JavaScript, React-Native, and general Mobile Engineering concepts.

Some of the topics we discussed were:

• Explain Closures and Hoisting with examples.
• Security considerations while building mobile applications.
• Different ways to improve the performance of a React-Native application.
• Design a large listing component with support for filtering. What performance optimization can be added?
• Anything else I would like to share about my experience.

I found this round to be more discussion-oriented than question-and-answer-based. Instead of expecting textbook definitions, the interviewer was more interested in understanding my thought process, the trade-offs I had made in previous projects, and the reasoning behind my technical decisions.

The interviewer also asked a few follow-up questions based on my answers, making the discussion feel quite natural rather than scripted.

Soon after the interview, the recruiter called again and informed me that the feedback was positive. We then scheduled the Machine Coding round.

💡 What I Learned

This round reinforced something I had noticed in a few other product company interviews as well.

For senior mobile engineering roles, interviewers usually care less about whether you can recite JavaScript definitions and more about whether you’ve applied those concepts while building real products.

Whenever possible, try to answer with examples from your own projects rather than giving textbook explanations. It makes the discussion much more engaging and also demonstrates practical experience.

💻 Round 3 — Machine Coding

This round got rescheduled once because most of the team was on leave during the Holi week.

The assignment was to build a simple TODO application within 1.5 hours.

Functional Requirements

• Users should be able to create a TODO using a Bottom Sheet.
• The Bottom Sheet should contain a title input field and a Save button.
• Basic validations were expected, and the Save button should remain disabled until the user entered a valid title.
• Every TODO should have Edit and Delete actions.
• Clicking on a TODO should navigate to a separate screen where users can create multiple tasks for that TODO.
• The same Bottom Sheet should be reused for both Create and Edit operations.
• Each task should have a checkbox to mark it as completed.

Non-Functional Requirements

Besides implementing the functionality, the interviewer was also looking for:

• Clean and polished UI
• Filtering based on pending and completed tasks
• Offline support

The problem statement itself wasn’t particularly difficult.

The real challenge was managing time and deciding what deserved attention during those 90 minutes.

Mistakes I Made

Looking back, I think I made two mistakes that significantly affected my overall solution.

1️⃣ Trying Something New During the Interview

I had recently started exploring Zustand, so I thought it would be a good opportunity to use it during the interview.

Unfortunately, I ended up spending more time than expected setting it up properly and configuring TypeScript support.

Eventually, I decided to drop the idea and switched back to plain useState.

Looking back, I think that decision alone cost me valuable time.

Lesson: Interviews are probably not the best place to experiment with a new library unless you’re already very comfortable with it.

2️⃣ Overengineering the Bottom Sheet

I also spent quite a bit of time trying to make the Bottom Sheet highly reusable.

In hindsight, that optimization wasn’t really necessary.

Those extra minutes could have been invested in polishing the core functionality or improving the overall user experience.

Later, I realized that machine coding interviews are less about writing the “perfect architecture” and more about making smart trade-offs within a limited amount of time.

Sometimes, a simpler, fully functional implementation is far better than an elegant abstraction that remains incomplete.

One Unexpected Outcome

This interview actually changed the way I prepared for future machine coding rounds.

While practicing afterwards, I realized I was repeatedly facing the same problem — I didn’t have a simple environment where I could quickly simulate interview-style questions with a timer.

So I ended up building a ***lightweight machine-coding practice setup*** for myself, which I now use to prepare for interviews.

It has been surprisingly helpful because it allows me to focus on managing time instead of spending the first few minutes setting up a project.

A few days later, I received a call from another recruiter (my original recruiter was on leave).

She informed me that I had received mixed feedback for the Machine Coding round.

One thing I really appreciated was that she didn’t just tell me the outcome — she also shared detailed feedback about what went well and where I could have improved.

She then explained that the next round would be Mobile System Design and even suggested the areas I should prepare before the interview.

💡 What I Learned

This round completely changed my perspective on machine coding interviews.

Initially, I thought the goal was to showcase the best architecture possible.

Later, I realized the real objective is to deliver a complete, stable solution while making sensible engineering trade-offs within the given time.

The interviewer is usually evaluating your decision-making as much as your coding ability.

🏗️ Round 4 — Mobile System Design

The interviewer for this round was a Senior Architect from the hiring team.

After a brief introduction and an overview of what his team works on, he explained the interview format.

He gave me two options to choose from:

1. Generic implementation — Design reusable mobile libraries such as upload/download managers, data syncing libraries, etc.
2. Application flow implementation — Design end-to-end mobile application flows like e-commerce, checkout, payments, and similar user journeys.

Since I had been working extensively on checkout and booking flows in my day-to-day work, I chose the second option.

The problem statement was:

Design an e-commerce application covering Listing, Product Details Page (PDP), Cart, Checkout, and Payment.

Initially, I felt comfortable because this was something I had worked on professionally.

However, as the discussion progressed, I realized that knowing how a feature works and being able to systematically design it during an interview are two very different skills.

One area where I struggled was justifying some of the offline-first approaches and the trade-offs behind them.

Looking back, I also realized that I jumped into the solution too quickly.

I should have spent more time asking clarifying questions before proposing an architecture.

For example:

• Who are the end users?
• What is the expected traffic?
• Is this a consumer-facing app or an internal application?
• Are there any offline requirements?
• What business metrics matter the most?

Instead, I assumed the team was building for merchants and started designing around that assumption.

That affected some of the design decisions I made later in the discussion.

A few hours after the interview, the recruiter called me with the final feedback.

Unfortunately, I wasn’t selected for the role.

The primary feedback was that I still needed to strengthen my Mobile System Design skills, as I had missed discussing several important aspects during the interview.

Looking back now, I completely agree with that feedback.

After the interview, I started exploring more Mobile System Design resources and mock interviews, and only then did I realize how many areas I had overlooked.

Although the rejection was disappointing, the feedback itself was extremely valuable because it gave me a clear direction for what to improve.

💡 What I Learned

This interview completely changed how I prepare for System Design rounds.

Previously, I focused mostly on designing the solution.

Now, I spend much more time understanding the problem before proposing one.

I’ve also realized that interviewers are evaluating much more than architecture diagrams.

They want to understand:

• How you gather requirements.
• How you evaluate trade-offs.
• How do you think about scalability?
• How do you justify your decisions?

In many cases, your reasoning is just as important as the final architecture.

🎯 Final Thoughts

Although I wasn’t able to clear the interview process this time, I genuinely enjoyed the overall experience.

Among all the companies I interviewed with over the last few months, PhonePe stood out for having one of the smoothest and most transparent hiring processes.

Some things I really appreciated were:

• The recruiter clearly explained every interview round right from the beginning.
• They were flexible with scheduling whenever I needed more preparation time or had connectivity issues.
• I received timely updates after every round.
• Most importantly, I received detailed feedback instead of just a generic rejection.

Looking back, I also came away with a few important lessons:

• Thinking out loud during DSA interviews is incredibly valuable.
• Machine coding interviews are all about making the right trade-offs within the given time.
• Mobile System Design requires much more than knowing how to build features — you need to ask the right questions, justify your decisions, and communicate your thought process clearly.

Overall, even though the outcome wasn’t what I had hoped for, the interview process gave me a clear understanding of where I stood and what I needed to improve.

I hope sharing my experience helps someone preparing for a similar role.

If you’ve recently interviewed at PhonePe or another product company, I’d love to hear about your experience as well.