PhonePe Data Scientist — Interview Questions
PhonePe Data Scientist Interview Questions
Data scientists at PhonePe work on problems where the cost of a wrong model isn't a bad recommendation — it's fraud losses, blocked legitimate transactions, or a lending decision that goes to a borrower who can't repay. The interviews reflect that: expect questions that push past "build a model" into "what happens when the model is wrong, and how do you know."
PhonePe's Interview Process for Data Scientist
Typically includes a take-home or live case round, a statistics/ML fundamentals round, an applied case-study round focused on fraud, risk, or growth problems, and a final round with a senior data science lead or cross-functional stakeholder. Expect heavy emphasis on trade-offs — precision vs. recall, speed vs. accuracy — grounded in payments-specific consequences.
Question 1: Real-Time Fraud Detection
Design a real-time model to flag potentially fraudulent UPI transactions before they complete. The model has roughly 200 milliseconds to make a decision. Walk through your approach, including how you'd handle the trade-off between catching fraud and blocking legitimate transactions.
Why interviewers ask this
This tests whether a candidate understands the operational constraints of real-time fraud systems — not just model accuracy, but latency budgets and the asymmetric cost of false positives versus false negatives in a payments context.
Example strong answer
"The 200-millisecond budget rules out anything computationally heavy running synchronously, so I'd split this into a fast-path and a slow-path. The fast path is a lightweight model — something like a gradient-boosted tree or a well-tuned logistic regression on a small feature set — using signals that are cheap to compute in real time: transaction amount relative to the user's typical range, velocity of transactions in the last few minutes, device and location consistency, and whether the recipient has been flagged before. That model outputs a risk score, and only transactions above a threshold get an additional friction step, like an OTP re-confirmation, rather than blocking outright.
The slow path runs asynchronously after the transaction, using richer features — graph-based signals like whether this recipient is connected to other flagged accounts, longer transaction history patterns — to catch fraud the fast model missed, feeding back into blocking future transactions or freezing an account, even if it can't stop the one that already went through.
On the precision-recall trade-off: false positives here mean blocking a legitimate user's payment, which for something like UPI — often used for essentials, rent, small business payments — has a real cost to trust and to the merchant on the other end. False negatives mean fraud losses. I wouldn't pick one threshold and call it done; I'd calibrate the threshold based on transaction risk tier — a ₹200 payment to a known recipient gets a much higher bar for intervention than a ₹50,000 transfer to a brand-new recipient at 2 AM.
I'd also build in a feedback loop: every transaction a human fraud analyst confirms as fraud or false-positive after the fact should retrain the model periodically, since fraud patterns adapt quickly once fraudsters learn what triggers detection."
Follow-up questions
- How would you monitor for model drift, especially since fraud patterns evolve specifically to evade whatever the current model catches?
- The fraud team says false positives are frustrating high-value merchants and causing churn. How do you adjust without opening a bigger fraud hole?
Question 2: Testing OTP Friction Removal
The growth team wants to remove an OTP step for returning users to reduce friction, but the risk team is worried this could increase account-takeover fraud. You're asked to design the test. How do you structure it so you can measure both the growth upside and the fraud downside credibly?
Why interviewers ask this
This checks whether a candidate can design an experiment that captures a delayed, asymmetric-risk metric (fraud, which often surfaces weeks later) alongside an immediate-signal metric (activation/conversion), rather than declaring victory on the fast metric alone.
Example strong answer
"The core challenge here is that the upside metric — conversion or activation — shows up in hours, while the downside metric — fraud — often doesn't show up for days or weeks, since compromised accounts aren't always exploited immediately. If I only ran the test for the length of time it takes to see a clean conversion lift, I'd be making a decision on half the picture.
I'd run a standard randomized A/B test — treatment group with OTP removed for returning users, control with it kept — but define the evaluation window in two parts: an early readout on conversion/friction metrics at day 3–5, purely informational, not a decision point, and a full readout at day 30–45 that includes fraud incidence, chargeback rates, and account-recovery requests for both groups.
Critically, I'd only expose the treatment to a bounded percentage of eligible users — say 5–10% — not because the test needs it statistically, but because if the risk team's concern is correct, I don't want that percentage to be higher until we've confirmed it's safe. This is a case where the cost of being wrong should shape the test design itself, not just the sample size math.
I'd also pre-register a stopping rule: if fraud incidence in the treatment group crosses a defined multiple of baseline at any point during the test — not just at the scheduled readout — the test pauses immediately rather than running to completion. Growth experiments that only check in at the end can let a real problem compound for weeks before anyone looks.
For the actual comparison, I'd look at fraud rate per transaction volume, not just raw fraud count, since the treatment and control groups may have different transaction volumes, and I'd segment by user tenure and risk profile, since removing OTP for a 3-year user with a clean history is a very different risk than removing it for someone active for 3 months."
Follow-up questions
- The early readout at day 5 shows a strong conversion lift and zero fraud so far. Growth wants to expand the test immediately. Do you agree?
- How would you account for the fact that fraudsters might specifically probe for which users are in the treatment group, biasing your fraud numbers?
Question 3: Modeling Merchant Churn
PhonePe wants to predict which merchants are likely to stop actively using the platform in the next 30 days, so the merchant success team can intervene early. What features would you use, and how would you validate that the model is actually useful for the business, not just accurate on paper?
Why interviewers ask this
This tests feature reasoning grounded in a real business process — merchant churn — and whether the candidate understands that a model's accuracy metric isn't the same as its business usefulness, especially when the output feeds a human intervention team with limited capacity.
Example strong answer
"I'd start with behavioral features that reflect engagement trend, not just current-state snapshots: change in weekly transaction volume over the last 4–8 weeks compared to the merchant's own historical baseline, change in settlement-check frequency, days since last transaction, and whether the merchant has recently had support tickets or payment failures — since friction often precedes disengagement.
I'd also want relative features, not just absolute ones: a merchant doing 50 transactions a week when they used to do 200 is a much stronger churn signal than a merchant who's always done 50. Comparing merchants only to global averages misses this, so I'd build features normalized against each merchant's own trailing history.
For validation, accuracy alone isn't the right frame here, because churn is typically a minority class — most merchants don't churn in any given 30-day window — so a model that just predicts 'no churn' for everyone could look accurate while being useless. I'd optimize for precision at a fixed intervention capacity: if the merchant success team can realistically reach out to, say, 200 at-risk merchants a week, I want the model's top 200 predictions each week to have the highest possible actual churn rate, not a global precision/recall trade-off that ignores operational constraints.
The real test of usefulness, though, isn't offline metrics at all — it's a randomized holdout: flag a set of predicted at-risk merchants, but have the success team intervene with only a random subset of them, and measure whether intervened merchants churn less than the untouched flagged group. That tells us whether the model is identifying merchants where intervention actually changes the outcome, not just merchants who were going to churn regardless, or merchants who were never really at risk."
Follow-up questions
- The holdout test shows intervention doesn't meaningfully reduce churn for flagged merchants. What does that tell you, and what would you investigate next?
- How would you handle a new merchant with only 2 weeks of history — not enough for trailing-baseline features?
Question 4: Cross-Sell Recommendation for Financial Products
PhonePe wants to recommend relevant financial products — insurance, lending, mutual funds — to UPI users based on their transaction behavior. How would you approach building this, and what guardrails would you put in place given these are financial products, not just e-commerce recommendations?
Why interviewers ask this
This checks whether a candidate treats financial product recommendations with appropriate caution — unlike recommending a movie or a product, a poorly-targeted financial recommendation can mean genuine harm (over-leveraging someone, mis-selling insurance), and PhonePe wants to see that instinct explicitly.
Example strong answer
"I'd treat this differently from a typical recommendation system from the start, because the cost of a bad recommendation is asymmetric and can be genuinely harmful — recommending a personal loan to someone showing signs of financial stress, for instance, isn't a minor UX miss, it's a real risk to that person.
For the modeling approach, I'd use transaction behavior as signal for relevance, not urgency — things like consistent UPI usage for bill payments suggesting insurance relevance, or regular small recurring transfers suggesting mutual fund SIP relevance — but I'd explicitly exclude signals that could indicate financial distress, like sudden drops in balance-adjacent behavior or increased small-value transactions late in the month, from being used to target lending products. Those users might be the ones a naive model would flag as 'high propensity' for a loan, and that's exactly the population recommending credit to is most likely to cause harm.
I'd build this as a propensity-to-value model per product line, ranking users by likely relevance and fit, then apply hard eligibility and suitability filters before anything is shown — regulatory eligibility for lending products, existing debt-to-income signals where available, and frequency caps so users aren't bombarded with cross-sell prompts.
For evaluation, I wouldn't optimize purely for click-through or conversion rate. I'd track downstream health metrics too — for lending specifically, early delinquency rates of users acquired through this recommendation channel compared to other channels, since a recommendation model that drives short-term conversion but higher default rates isn't actually working, it's just moving the cost downstream.
I'd also push for a manual review or sign-off process on which product categories a purely behavioral model is even allowed to target, rather than treating recommendation targeting as an unconstrained optimization problem."
Follow-up questions
- How would you detect if the model is inadvertently learning to target financially vulnerable users, even after explicitly excluding distress signals?
- Product wants to add push notifications for these recommendations to boost conversion. What's your view?
Question 5: Defining a Payment Reliability Metric
PhonePe wants a single north star metric to track payment reliability across the entire app — something leadership can watch on a dashboard. What would you propose, and what are the risks of oversimplifying this into one number?
Why interviewers ask this
This tests metric design maturity — whether a candidate understands that a single top-line number can hide critical variance, and whether they can propose something that's both simple enough to be a north star and honest enough not to mislead leadership.
Example strong answer
"A single number leadership can track daily makes sense operationally, but I'd be upfront that any one metric here is a simplification, and I'd propose it alongside a small set of guardrail metrics it needs to be read together with — not as a standalone truth.
For the north star itself, I'd propose transaction success rate — completed transactions divided by attempted transactions — measured over a rolling window, say hourly, with day-over-day and week-over-week comparison baked into the dashboard rather than just a raw current number. Raw success rate alone is intuitive to everyone in the company, which matters for something meant to be a shared reference point.
But I'd flag the real risk immediately: an aggregate success rate can look healthy overall while hiding serious localized failures — a specific bank's transactions failing at a high rate, a specific region or app version having problems, or failures concentrated in high-value transactions specifically. A 99% success rate could still mean total failure for one significant bank partner if their share of volume is small enough not to move the aggregate.
So I'd pair the north star with a small set of guardrail breakdowns, always visible alongside it: success rate segmented by top-5 banks by volume, by payment mode, and by transaction value tier. The rule I'd propose is that the aggregate metric drives the headline conversation, but any of those segment breakdowns crossing a defined threshold triggers an alert independent of what the aggregate shows — because leadership shouldn't have to remember to check the segments; the system should surface it when something's wrong even if the top-line number looks fine.
I'd also make sure the metric excludes user-caused failures — like a user having insufficient balance — from the definition, since conflating those with actual system failures would make the metric noisy and less actionable for the engineering and infra teams who'd be driving improvements against it."
Follow-up questions
- Leadership says the segmented breakdowns are too much detail for a weekly review and wants just the one number. How do you push back or compromise?
- How would you define the metric differently for a lending product, where 'success' isn't just 'transaction completed' but involves downstream repayment behavior?
Preparation tip
The strongest PhonePe data science answers treat every model as embedded in a real operational process with real people on the other end — a fraud analyst who has to act on a flag, a merchant success rep with limited capacity, a user who could be financially harmed by a bad recommendation. Candidates who only talk about model architecture and accuracy metrics, without addressing who acts on the output and what happens when it's wrong, tend to lose points here even with technically sound answers.