Back to feed
Single Experience
HL
Harsh Lembhe's profile picture
Interview Experience
Harsh Lembhe
PhonePe
Intern
AIDS 2027
Saturday, September 5, 2026
68 reads
✦6 min read

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

Question 1: Non-Subsequence Substrings β€” 70 points Result: Solved fully (15/15 test cases) Score: 70/70

Question 2: 3D DP β€” Two Startups β€” 70 points Result: Solved fully Score: 70/70

Question 3: Riding in a Lift (CF 479E) β€” 100 points Result: Plain 2D DP, no prefix-sum optimization (~70% cases) Score: 70/100

Question 4: MEX-Sequence Subarrays β€” 100 points Result: Brute-force O(NΒ²) (partial credit) Score: 40/70

  • Difficulty Level: Medium–Hard

  • My Experience: I managed to fully solve 2 of the 4 problems and partially solve the other 2, ending up with a total score of around 274/340. The minimum cutoff to qualify for interviews was around 160/340.

🎀 3. Interview Rounds

🧩 Round 1: Technical Interview (DSA)

  • Type: Coding

  • Duration: 1 hour

  • Questions:

    1. Russian Doll Envelopes β€” I started by explaining why we'd sort the envelopes the way we do, using a custom comparator, and dry-ran the sample cases against the expected output. The interviewers then gave me an edge case where my initial greedy approach broke. I quickly picked up the intuition that once sorted, we only need to focus on the heights (since widths are already ordered) which naturally leads to finding the LIS of the heights. I explained the optimal LIS approach using binary search, and since neither interviewer seemed familiar with it, I walked them through the proof as well.

    2. Minimum Time to Reach Target with Limited Power β€” This followed a pattern I recognized essentially a Dijkstra-style shortest-time computation, with a small twist: instead of skipping equal-time transitions, we continue exploring them since a higher power level could still be beneficial. I solved and explained this fairly quickly, dry-running my code against a few edge cases, then wrote the pseudocode on paper covering all the edge cases as asked.

  • Difficulty Level: Medium

  • My Experience: I started by dry-running the problems and clearly laying out all the constraints before diving into an approach for either question, then slowly worked my way to the optimal solution while thinking out loud. I solved both within the time limit, discussing the approach first each time before coding it on paper. After this round, I advanced straight to the HM round.

    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.


πŸ‘” HM Round (Behavioral + System Design + Technical)

In my case, this round happened right after Round 1 and before Round 2 β€” though for some other candidates, it was scheduled after Round 2 instead. Panels seemed to mix up the order depending on scheduling.

  • Type: Managerial / System Design / Behavioral

  • Duration: ~1 hour 20 minutes

Description: This was the most in-depth round of the entire process. It started with a deep dive into one of my projects. I actually steered the conversation toward this one myself, since it was by far my strongest project covering the database ER diagram, the system design behind it, where the design fell short, and how it could be scaled further.

From there, the conversation moved into DBMS β€” SQL queries and ACID properties β€” followed by a detailed discussion on WebSockets and HTTP vs HTTPS. The interviewer kept probing deeper until I genuinely got stuck on a couple of points.

Next, they asked about my go-to messaging app, and we went into a high-level design discussion comparing WhatsApp and Instagram, including:

  • How features like Stories (upload/view) are designed

  • How the two apps differ in messaging design, and the trade-offs each makes

  • How WhatsApp's single-tick, double-tick, and blue-tick (seen) system works internally

They then posed a hypothetical scenario: design and improve features for a new messaging app (referred to as "X") to compete with existing players.

After that, we shifted to UPI transaction design β€” they asked about major design aspects of UPI transactions, such as reconciliation and idempotency.

We then moved to behavioral questions

This discussion lasted about 15 minutes.

Finally, there was a rapid-fire round where I had to answer instantly:

  • Difficulty Level: Hard

  • My Experience: Out of 6 students (including me) who advanced from Round 1, this HM round followed. In total, around 8–10 students gave the HM round. I fumbled a bit during the project/system-design deep dive, but the interviewers were supportive and helped guide me through it when I got stuck.

    Biggest takeaway: Be as honest as possible, stay calm, and don't try to outshine the interviewers, as it usually backfires.


🧩 Round 2: Technical Interview (DSA)

  • Type: Coding

  • Duration: 1 hour

  • Questions:

    1. Greatest Common Divisor Traversal β€” As soon as I got the question, I explained the brute-force approach β€” trying out all pairs and building a DSU on top. The interviewer then asked me to think about the optimal solution, which took me a bit of time since it was a new problem for me. Eventually I connected the dots between prime factors and pairability, mentioning smallest prime factors (SPF). He asked me to code the SPF sieve optimally and explain its complexity, after which we reduced each number to its SPF, applied an offset of 1e5 to build the DSU graph, and simply checked whether the whole array collapsed into one connected component. He was satisfied and had me code the full DSU implementation, and we wrapped up discussing time and space complexity. This one took me around 30–40 minutes, leaving me a bit tighter on time for the next question.

    2. Largest Color Value in a Directed Graph β€” I got the topological-sort intuition almost immediately. Since I was short on time, I jumped straight to the optimal approach β€” maintaining a 2D DP count array to track the count of each color at every node while running the topological sort until the whole graph is processed. We discussed the transitions by dry-running 3–4 test cases, and he was satisfied and asked me to code the transition logic.

  • Difficulty Level: Medium–Hard

  • My Experience: This round was noticeably harder than Round 1, with a couple of questions that were new to me, but I managed to solve both just with a bit less time to spare. I again discussed the approach thoroughly before writing any code on paper. The interviewer was genuinely supportive, and it felt more like a friendly, two-way discussion than a formal interview.

    Looking back, I was a bit disappointed with my pacing if I'd been faster on Question 1, I'd have had time to attempt the third question they had lined up, which was a meet-in-the-middle DP problem, a pattern I actually practiced quite a bit.

4. Overall Experience and Tips

  • Overall Interview Experience: Positive overall. The process was rigorous; the OA had a genuinely hard Codeforces-level problem, and the technical rounds expected clean, optimal solutions rather than just "does it work." The HM round was the most intense, testing depth of understanding rather than memorized answers.

  • What to prepare?

    • Strong DSA fundamentals: DP, Graphs, Tries, Binary Search

    • System design basics

    • Be strong with high-level design concepts and the trade-offs between different approaches

    • Core CS fundamentals: DBMS, Computer Networks, OOP, OS

    • Be ready for rapid-fire, personality-driven questions

  • Verdict: Selected (Intern) βœ…

Feel free to reach out to me on LinkedIn for any queries: linkedin.com/in/harsh-lembhe-53b900277

68 reads

Shared on theInterview community feed

Related Experiences

Hand-picked interview stories similar to this one.

8 posts