Real, anonymized candidate journeys from recent (2025–2026) PhonePe SDE loops in India — round by round, including what was asked, how the candidate approached it, and the outcome.
One complete journey, start to finish
Machine Coding — Workflow Execution Engine
A recruiter messaged me in early January and the machine coding round was set for the following Tuesday, online. The problem came at the start of the call: build a workflow engine like Airflow, where a workflow is a DAG of tasks, independent tasks run in parallel, and failed tasks retry on their own. Ninety minutes to code, then a discussion. First I asked what a task actually does — he said just simulate it with a sleep and a random failure. I wrote down the classes: Workflow, Task, Scheduler, and a small log, built the DAG validation and in-degree scheduling first, ran it on a three-task example, then added a thread pool so independent tasks ran together. Retries went in next with a max-attempts counter. In the discussion he asked what happens if a task with a side effect gets retried. I said each attempt should carry an id so a duplicate can be ignored downstream. Then he asked how I would avoid re-running finished tasks after a crash, and I explained logging each state change before acting on it and replaying that log on startup.
System Design — Merchant Settlement System
The design round was two days later, an hour long. The prompt was a merchant settlement system: merchants get paid the next day for yesterday's transactions, minus a commission, and finance must reconcile everything. I asked whether it was one payout per merchant per day with a flat commission; she said assume yes. Then I drew the flow: transactions are stored as unsettled, a nightly job picks them up per merchant, computes the net, writes ledger entries, then a payout goes to the bank. I spent much of the hour on an append-only, double-entry ledger. She asked about a one-time settlement outside the cycle; I said it should use the same job with a different cutoff. Then the main question: what if the job fails halfway through a merchant's batch. I explained committing in chunks, stamping each transaction with the run id in the same commit so a restart only picks up what is left, and paying out only once the run is fully posted. She asked how I would prove nothing was missed; I described a query for unsettled transactions before the cutoff that must come back empty.
DSA (one hour, three problems)
The DSA round was the next morning. One hour, and the interviewer said upfront there would be three problems, so I should keep moving. The first was Jump Game — can you reach the last index. I explained the greedy idea of tracking the farthest reachable index, coded it in a few minutes, and dry-ran it on the example that returns false. Then he gave me Jump Game II, the minimum number of jumps. I first described a BFS-style approach by levels and then wrote the greedy version that tracks the current range end and the farthest reach. He asked why it was linear and I walked through it. The third problem was the balloons one: intervals on a line, minimum arrows to burst all of them. I said sort by end coordinate and shoot at the end of the first balloon, then skip everything that starts before that point. I coded it, ran it on the sample and got 2. We finished with around five minutes to spare, which he used to ask how I would test the balloons code for edge cases like empty input and touching intervals.
Hiring-Manager Round
The last round was with the hiring manager the following week, about forty-five minutes on a video call. It was not a technical grilling. He first asked me to walk through my career so far and the two or three projects I was most involved in, and for each one he asked what my exact part was and who else was on the team. Then he described how his team was structured, roughly how many engineers, and what kind of work I would pick up in the first few months. Towards the end he asked about my notice period and what compensation I was expecting, and I gave him a range. I asked a few questions about on-call and how releases worked. The recruiter called a few days later with an offer. By that time I had another offer in hand that worked out better for me, so I ended up taking that one instead, but the process here was clean and quick.
Key takeaway: For the machine-coding round, prioritize a clean, extensible DAG/task model over cramming in every feature; for the settlement-system design, be ready to reason about ledger consistency and reconciliation, not just the happy path. The candidate received the offer here but chose a competing offer instead.
More real interview journeys
The first round of each journey below is shown in full; the rest of each candidate's journey — every remaining round, verbatim — is part of the Placement-Ready PYQ Kit.
Online Assessment (CodeSignal)
I applied through a referral and got the CodeSignal link about a week later, with a few days to take it whenever I wanted. I picked a Saturday morning so I would not be rushed. There were four problems and one timer for all of them. The first two were medium — an array question and a string question — and I got through them in about twenty minutes together. The third was a graph problem where I had to count groups of connected nodes; I wrote BFS and it passed all the visible cases. The fourth was the hard one, a stack-style problem with a twist, and I spent most of the remaining time on it. I got a working version but I was not sure it handled every edge case, so I added two of my own tests before submitting with a couple of minutes left. The recruiter emailed three days later saying I had cleared it and asked for slots for the live coding round.
🔒 3 more rounds — continue this journey in the full kit
Low-Level Design (90 min + 30 min review)
My loop started with the low-level design round, which was split into ninety minutes of coding on my own and then a thirty-minute review call. The problem was a code design exercise where several operations could happen at the same time, so the whole point was concurrency and keeping shared state thread-safe. I spent the first ten minutes listing the classes and deciding what state was shared and what was not. Then I coded the main flow with a simple lock around the shared part, got it working, and only after that tried to narrow the locking so that unrelated operations did not block each other. I wrote a small driver that ran operations from multiple threads to check nothing got corrupted. In the review call the interviewer went through my classes one by one and asked why I had chosen a lock over a concurrent collection in one place, and what would happen under heavy contention. I explained my reasoning and he pointed out one spot where the read path could be separated more cleanly. I cleared this round and the DSA round was scheduled for the following week.
🔒 3 more rounds — continue this journey in the full kit