Interview
PhonePe Online Assessment: The Hardest First Round in Indian Tech (2026)
PhonePe's online assessment is competitive-programming hard — four problems, one sitting. What to expect, which topics carry it, and how to prepare properly.
Most online assessments are volume filters. Four medium problems, a generous clock, and the intent is to remove people who cannot code rather than to rank the ones who can.
PhonePe's is not that. Reported accounts describe roughly four problems at competitive-programming difficulty — the harder end of any interview problem set — in a single timed sitting. It is the most demanding first round among comparable Indian product companies, and it eliminates a large share of applicants before any human speaks to them.
This guide covers what to expect, which topics actually carry an assessment at that level, and how to prepare with enough runway. For the rest of the loop after the assessment, see PhonePe interview questions and process; to practise the design rounds that follow, PhonePe's interview kit holds three low-level design problems attributed to the company.
What makes it different
The difficulty band changes what preparation should look like, and this is the part candidates get wrong.
A medium-difficulty assessment rewards breadth. Know twenty patterns shallowly, recognise which one applies, implement it competently, move on. Most interview preparation is optimised for exactly this, and it works almost everywhere.
A hard assessment rewards depth in the patterns that carry hard problems, plus something breadth-oriented preparation never builds: the ability to make progress on a problem whose pattern you do not immediately recognise. At this level you will meet at least one problem where the technique is not obvious in the first minute, and what you do in the following five determines your score.
| Typical assessment | PhonePe's assessment | |
|---|---|---|
| Difficulty | Medium | Competitive-programming level |
| What it rewards | Pattern breadth, clean implementation | Depth, and progress under uncertainty |
| Preparation shape | Many problems, medium band | Fewer problems, harder band, timed |
| Common failure | Ran out of time on the last problem | Knew the technique, could not implement it cleanly |
The topics that carry it
At medium difficulty, arrays, strings and hash maps carry most of an assessment. At this level they are table stakes, and the problems that separate candidates come from elsewhere:
Dynamic programming. The single highest-value area. Hard assessments lean on it heavily, and it is the topic where the gap between "I have read about it" and "I can derive the recurrence under time pressure" is widest. Work through the standard families — subsequences, partitions, intervals, state-machine DP, DP on trees — until you can identify which family a problem belongs to from its constraints. Dynamic programming patterns is the right starting point.
Graphs beyond basic traversal. Shortest paths with weights, topological ordering, union-find for connectivity, minimum spanning trees, and problems where the graph is implicit rather than given. Graph traversal patterns covers the foundations you build on.
Binary search on the answer. A technique that turns a large class of hard optimisation problems into an easy check function plus a search. Recognising when a problem is monotonic in its answer is one of the highest-leverage single skills for this difficulty band. Binary search patterns covers it.
Greedy with a justification. Not guessing at a greedy strategy, but being able to argue in a sentence why the local choice is safe. Hard problems punish unjustified greed with a failing hidden test case.
Heaps and interval problems. Scheduling, merging, top-k under constraints. Reliably present and reliably underprepared.
The DSA Patterns Sheet is free to browse and organises problems by the pattern each actually tests, which is the right axis for this kind of preparation. How to identify the right DSA pattern covers the recognition skill directly.
Implementation speed is half the round
At this difficulty, knowing the approach and still failing is a normal outcome — and it is usually not a knowledge problem.
Hard problems have more moving parts: more state to track, more index arithmetic, more edge cases. A candidate who knows exactly what to do but takes thirty minutes to write it correctly will not finish the paper. The specific failures are mundane and expensive: off-by-one errors in a two-dimensional DP table, an inverted comparison in a custom sort, integer overflow, an uninitialised base case.
The fix is deliberate implementation practice with real execution rather than reading solutions:
- Type the solution out fully, every time. Reading a solution and nodding builds nothing.
- Run it against real test cases, including the boundaries. In-browser code practice with AI feedback gives you execution plus a critique of what you wrote.
- Time yourself from the beginning. Untimed practice at this level produces false confidence more reliably than it produces skill.
- Know your language's library cold. Sorting with a custom comparator, priority queues, ordered maps. Fumbling standard library syntax during a hard problem is a pure waste of clock.
💡 Pro Tip: Keep a list of every bug that has cost you a submission. Within a fortnight you will see two or three recurring classes — for most people it is boundary conditions and comparator direction. Those are worth a specific checklist before you submit.
Managing the sitting itself
Four hard problems in one window is as much an allocation problem as a technical one.
- Read all of them first. Two or three minutes, all four problems. Difficulty at this level is not ordered reliably, and the easiest problem is often not the first.
- Bank the ones you recognise. Solve what you know cleanly and completely before touching anything speculative. A fully correct solution beats two partial ones.
- Set a hard limit on the unfamiliar problem. If nothing has emerged in eight minutes, leave it and come back. Sunk cost is the most common way strong candidates score badly on hard papers.
- Take partial credit seriously. Most platforms score by test cases passed. A brute-force solution that is correct but slow scores well above an elegant approach that does not compile.
- Reserve the last few minutes for boundaries. Empty input, single element, maximum constraint, negative values, integer limits.
⚠️ Important: A correct brute force submitted is worth more than an optimal solution you did not finish. If twelve minutes remain and your clever approach is half-written, submit the version that works.
A six-week plan
Six rather than four, because this assessment genuinely needs the runway. Compress it if you must, but drop breadth rather than depth.
Weeks 1 and 2 — close the fundamentals gap. Everything at medium difficulty, but timed and fully implemented. This is the base the hard problems assume; skipping it makes weeks 3 to 5 far less productive.
Weeks 3 and 4 — dynamic programming and graphs, hard band. The two highest-value areas. Aim for family recognition rather than problem count: given constraints, which DP shape is this, and why.
Week 5 — binary search on the answer, greedy, heaps, intervals. The techniques that turn specific hard problems into easy ones. Practise stating the monotonicity argument or the greedy justification out loud in a sentence.
Week 6 — full timed papers. Four hard problems, one sitting, no assistance, twice or three times over the week. This week builds the allocation skill above, which no amount of single-problem practice produces. Review afterwards for time spent rather than problems solved.
Then keep light practice running until the assessment, and start on the design rounds — the loop that follows is design-heavy, and clearing the assessment puts you in it within days.
After the assessment, the loop moves fast
One thing worth planning for: clearing the assessment does not buy much breathing room. Candidates commonly describe technical rounds being scheduled within days, and the loop that follows is design-heavy in a way the assessment gives no hint of.
That creates a specific trap. Six weeks of hard algorithmic preparation leaves you sharp for exactly the round you have just passed, and cold for the ones that decide the outcome — class-level design, a take-home machine coding exercise for some roles, and an architecture round. Candidates who wait until they have cleared the assessment to think about design routinely find they have three days rather than three weeks.
The fix costs very little. In the final fortnight before your assessment, spend two sessions on design rather than adding a fiftieth hard problem to your total. Not a full preparation programme — enough to know the vocabulary, to have modelled one system end to end, and to have read a worked design against your own attempt. The three low-level design problems evidenced at PhonePe come with editorials that make this a two-evening exercise rather than a two-week one.
The marginal hard problem has diminishing returns once you are in the right band. The first hour of design preparation, if you currently have none, does not.
Frequently asked questions
How hard is PhonePe's online assessment? Reported accounts describe it as competitive-programming level — roughly four problems at the harder end of interview difficulty, in one timed sitting. It is the most demanding first round among comparable Indian product companies.
How many questions are there? Around four in reported accounts. Confirm with your recruiter, as formats change.
What topics should I prioritise? Dynamic programming and graphs first, then binary search on the answer, greedy with justification, heaps and intervals. Arrays, strings and hash maps are assumed rather than tested.
Do I need competitive programming experience? It helps, but it is not required. What transfers from competitive programming is implementation speed and comfort with unfamiliar problems — both trainable directly through timed, fully implemented practice.
Is partial credit given? Most assessment platforms score by test cases passed, so a correct but slow solution earns real marks. Confirm the scoring for your assessment where you can.
What language should I use? Whichever you are fastest in, and know the standard library of cold. At this difficulty, implementation speed is a large part of the score.
What happens after the assessment? Technical rounds combining coding and design, a machine coding exercise for some roles, a high-level design round, and a manager round. See PhonePe interview questions and process.
How long should I prepare? Six weeks is a realistic runway from a medium-difficulty baseline. Less is possible but the hard-band work is what earns the marks, so protect it.
Where to start
Do not prepare for this assessment the way you would prepare for a normal one. Breadth at medium difficulty is the baseline, not the goal — the marks are in dynamic programming, graphs, and being able to implement a hard solution cleanly while the clock runs.
Start with the free DSA Patterns Sheet, organised by the pattern each problem actually tests, and do every session timed and fully implemented in code practice rather than reading solutions. Then open PhonePe's interview kit for the three low-level design problems evidenced at PhonePe, because the loop after the assessment moves quickly.
Assessment formats change. Confirm the current structure with your recruiter, and check PhonePe's careers site for current openings.