PhonePe frontend interview questions and process

The screen said "Processing". The interviewer asked what happens if the user closes the app right now. The candidate said the request would complete on the server. Correct. And when they reopen it? It would show the transaction. Also correct. And in the eleven seconds between the request timing out on the client and the server confirming — what does the screen say then, and what happens if they hit Pay again?

That eleven-second window is where PhonePe frontend interview questions live. PhonePe processes an enormous share of India's UPI volume on phones that are frequently slow and networks that are frequently worse, so the frontend rounds are unusually interested in what your interface does when it does not know the answer yet. Add a long machine coding round and a genuine JavaScript bar and you get a loop that rewards people who have shipped something users depended on. I built Greenroom after freezing in an interview I had prepared hard for, so this guide covers what PhonePe asks and how to reason through it out loud.

The PhonePe frontend engineer interview process

• Recruiter screen — level calibration and which org: the consumer app, merchant products, insurance and wealth, or a platform team.
• Machine coding round — 60 to 120 minutes building a working component or small app. This is the round that decides most loops.
• JavaScript and DSA round — language fundamentals, usually with one LeetCode-medium problem attached.
• Frontend system design — a payment flow, a transaction history screen, or the app shell itself.
• Hiring manager round — ownership, incidents you handled, and a real answer to why fintech.

Our PhonePe interview questions guide covers the company-wide process and the PhonePe backend engineer guide covers the services these screens call.

The machine coding round

You get a problem statement and a long block of time, and you build something that runs. Typical prompts: a transaction list with filters and infinite scroll, a multi-step payment form with validation, a split-bill calculator, a UPI-style contact picker with search, or an OTP input component with paste and auto-advance.

What is actually graded, roughly in order:

• Does it work? A running, incomplete solution beats an elegant, broken one every time.
• Structure. Component boundaries, where state lives, and whether logic is separated from rendering. Interviewers read your file layout as a signal.
• Edge cases without being told. Empty state, loading state, error state, and what happens on a slow network. In a payments context these are requirements, not polish.
• Readable naming and small functions. They will read this code with you afterwards.
• Extensibility. Very often the follow-up is "now add X in five minutes", and your structure either survives that or does not.

Practical advice: spend the first five minutes writing down the component tree and the state shape before typing. Handle the error path early rather than saving it for the end you will not reach. Our machine coding round guide covers the format in depth.

The payment-flow question, in every round

Whatever the round, the conversation converges on uncertainty. Be ready to talk about:

• Idempotency from the client side. The Pay button must not be able to submit twice. Disable on submit, and send a client-generated request ID so a retry is recognisably the same attempt.
• The unknown state. A timeout is not a failure. The correct UI says "we're confirming this payment" rather than "payment failed", because a false failure message makes users pay twice.
• Polling versus push. How the screen learns the final status, backoff on the polling interval, and what happens after a reasonable number of attempts.
• Resuming after a kill. The user closed the app mid-transaction. On reopen, the app should reconcile rather than assume.
• Deep links back from a UPI app. The user leaves your app to approve in another, and may return, or may not. Both paths need handling.
• Never lying to the user. The single most important sentence you can say in this round: "I would rather show an ambiguous state honestly than show a definite state that might be wrong."

// the button that must not double-charge — say the invariant while you write it
function PayButton({ amount, onDone }) {
  const [state, setState] = useState('idle');
  const requestId = useRef(crypto.randomUUID());   // stable across retries

  async function pay() {
    if (state !== 'idle') return;                  // guard, not just a disabled attribute
    setState('pending');
    try {
      const res = await charge({ amount, requestId: requestId.current });
      setState(res.status === 'success' ? 'done' : 'unknown');
    } catch {
      setState('unknown');                         // timeout is NOT failure
    }
    onDone(state);
  }

  return <button disabled={state !== 'idle'} onClick={pay}>{label(state)}</button>;
}

JavaScript depth

The fundamentals round is real, and questions arrive as follow-ups more often than as a quiz:

• The event loop, microtask versus macrotask ordering, and predicting the output of a mixed promise-and-timeout snippet.
• Closures and this, at mechanism level, plus implementing bind, debounce, throttle and a small event emitter from memory.
• Promise combinators — all versus allSettled versus race, and writing a promise pool with a concurrency limit.
• Why a component re-rendered — reference equality, context identity, and how a new object in props defeats memoization.
• Cleanup and leaks — cancelled requests, cleared intervals, and what a leaked poller does on a screen users leave open.

Our JavaScript interview questions and React interview questions guides cover this ground.

Performance on the phone your users actually have

PhonePe's audience includes a great many low-end Android devices on unreliable connections, and interviewers ask accordingly.

• JavaScript execution cost, not just bundle size. Parsing and running 300KB on a slow CPU is the real problem; say this explicitly.
• List virtualisation for long transaction histories, with the honest costs.
• Offline and flaky network behaviour. Cached last-known state, a visible reconnecting affordance, and queued actions where safe.
• App shell and perceived performance. Skeletons over spinners, and rendering the shell before the data arrives.
• Layout stability. Explicit image dimensions, reserved space for async content, no content jumping under a user's thumb mid-tap — which in a payments app is a genuine safety issue.
• Measurement. Real-user monitoring across device tiers, not a lab score on a MacBook.

Our Flipkart frontend engineer guide covers the same low-end-device problem in commerce.

The hiring manager round

Expect: an incident you owned, a time you shipped something that broke, how you work with backend engineers when a contract changes, a deadline you missed and what you told people, and why fintech rather than any other product.

The last one deserves a real answer. "Scale" is fine but generic; something specific about payments, trust, or the consequence of a bug landing on someone's actual money is better. Our behavioral interview questions guide covers the structure.

Where each prep option actually helps

• Machine coding practice, timed — build three components end to end under a clock. This is the single highest-yield preparation for this loop.
• GreatFrontEnd and JavaScript.info — for the implement-debounce class of question, which is guaranteed to appear.
• The NPCI UPI documentation and PhonePe's engineering blog — genuinely useful for understanding why the unknown state exists at all, which is what the design round is really testing.
• LeetCode — mediums, for the DSA half. Not the main event here, but not skippable.
• ChatGPT — good for generating machine coding prompts and reviewing your structure afterwards. It will not ask what the screen says at second eleven.
• Greenroom — the spoken layer. Ari, the AI interviewer runs the design and behavioral rounds out loud and pushes on the failure cases. Honest tradeoff: Ari will not review your component tree, so pair it with timed builds.

How to prepare for the PhonePe frontend interview

• Week 1 — three timed machine coding builds, each ending with a five-minute "now add this feature" extension.
• Week 2 — the JavaScript mechanism set from memory, plus output-prediction drills on the event loop.
• Week 3 — design a payment flow, a transaction list and the app shell out loud, with the unknown state, idempotency and low-end performance in each.
• Final week — five behavioral stories including one incident you owned, two full spoken mocks, and a real answer to why fintech.

Interviewing across comparable loops? The Razorpay frontend engineer guide covers merchant-facing dashboards, the Swiggy frontend engineer guide covers real-time order tracking, and the Zomato frontend engineer guide covers search and feed performance.

Frequently asked questions

What is the PhonePe frontend engineer interview process?

Candidates report a recruiter screen, a machine coding round of 60 to 120 minutes building a working component or small app, a JavaScript and DSA round combining language fundamentals with a LeetCode-medium problem, a frontend system design round usually about a payment flow or transaction list, and a hiring manager round on ownership and incidents. The machine coding round is the one that decides most loops.

What is asked in the PhonePe machine coding round?

Typical prompts include a transaction list with filters and infinite scroll, a multi-step payment form with validation, a split-bill calculator, a contact picker with search, or an OTP input with paste and auto-advance. Grading favours a working incomplete solution over an elegant broken one, then component structure and where state lives, then whether you handled empty, loading and error states without being told, and finally whether your structure survives a five-minute extension request at the end.

How do you handle a failed or unknown payment state in a frontend interview?

Treat a timeout as unknown rather than failed, because a false failure message causes users to pay twice. Guard the submit path so the button cannot fire twice, send a client-generated request ID so a retry is recognisably the same attempt, poll for the final status with backoff and a sensible attempt limit, reconcile on app reopen rather than assuming, and handle both paths when a user leaves for another UPI app. The sentence that lands is that you would rather show an ambiguous state honestly than a definite state that might be wrong.

What JavaScript questions does PhonePe ask?

Expect mechanism-level questions rather than framework trivia: the event loop with microtask and macrotask ordering including output-prediction snippets, closures and this binding, implementing bind, debounce, throttle and a small event emitter from memory, promise combinators and writing a promise pool with a concurrency limit, why a specific component re-rendered, and cleanup for cancelled requests and leaked pollers on long-lived screens.

Does PhonePe ask DSA questions to frontend engineers?

Yes, usually one LeetCode-medium problem inside the JavaScript round rather than as a separate algorithmic loop. It is not the main event — the machine coding round carries more weight — but it is not skippable either, and arrays, strings, hash maps and basic graph or tree traversal cover most of what appears.

How do you prepare for PhonePe's frontend performance questions?

Focus on low-end Android and unreliable networks rather than lab scores. Be ready to discuss JavaScript execution and parse cost rather than only bundle size, list virtualisation for long transaction histories with its honest costs, offline and flaky-network behaviour with cached last-known state and a visible reconnecting affordance, skeletons and app shell rendering for perceived speed, and layout stability so nothing shifts under a user's thumb mid-tap in a payments screen.