phonepe Data Analyst Interview: Questions, Experience & Prep (2026)

PhonePe is one of India's largest fintech platforms, built on UPI and now spanning payments, insurance, wealth, and commerce. A Data Analyst here works with transaction data at very large scale, helping product and growth teams make decisions that affect hundreds of millions of users.

As of July 2026, there are 319 active Data Analyst roles across India, with 64 of them at PhonePe, making it one of the more active hirers in this space right now. Salary bands from that same data: entry level (0-2 years) at 5-10 LPA, mid level (3-5 years) at 10-18 LPA, and senior analysts (6-9 years) at 18-30 LPA.

Candidates report the interview process typically covers SQL and analytics, a product or business case exercise, and a behavioural round with the hiring manager. Fintech domain knowledge is not required but gives you a clear edge in both the technical and case rounds.

Based on what candidates have shared about their PhonePe Data Analyst interviews, these questions come up most often:

1. Write a SQL query to find merchants whose transaction volume dropped by more than a set percentage month-on-month.
2. How would you detect anomalies in UPI transaction data? Walk through your approach step by step.
3. PhonePe sees spikes in transaction failures on certain days. How would you investigate the root cause?
4. A new feature was launched but activation rate is low. What analysis would you run and what data would you pull?
5. How do you define and measure success for a cashback campaign?
6. Daily active users are up but transaction value per user is down. What does this tell you, and what would you do next?
7. Write a SQL query to find users who transacted in January but not in February.
8. How would you build a dashboard for the merchant onboarding team to track their funnel?
9. Tell me about a time you found an insight in data that changed a business or product decision.
10. How would you design and analyse an A/B test for a UI change on the PhonePe home screen?
11. A cohort of new users churns within the first 30 days of signing up. How would you find out why?
12. How would you prioritise which data quality issues to fix first if engineering bandwidth is limited?

Q: Tell me about a time you found an insight in data that changed a business decision.

*Situation:* At my previous company, the product team believed a new onboarding flow was performing well because total signups had increased after launch.

*Task:* I was asked to prepare a quarterly funnel review report.

*Action:* When I broke the funnel down by acquisition channel, I found that paid traffic users were converting well but organic users were dropping off at the third step. The new flow had introduced a mandatory phone OTP that caused friction for users on slower connections. I built a segment-level view, highlighted the gap in the review, and proposed making the OTP step optional for lower-risk users.

*Result:* The product team implemented the change in the following sprint. Organic conversion improved the next month, and segment-level funnel reviews became a standing practice for the team.

---

Q: Daily active users are up but transaction value per user is down. What does this tell you?

*Situation:* This is a classic pattern in fintech growth, where new user acquisition and per-user value can move in opposite directions at the same time.

*Task:* The interviewer wants structured thinking, not a single-cause assumption.

*Action:* I would first check whether incoming users are from a different segment. First-time UPI users or users from smaller towns often have smaller transaction sizes. Then I would check whether high-value existing users are transacting less, which is a retention problem rather than a growth one. Finally, I would check whether a new low-value payment feature is driving frequency up while average ticket size stays low.

*Result:* The right action depends entirely on which hypothesis the data supports. If new users are simply smaller-ticket users, that may be expected and fine. If high-value users are churning, that needs immediate attention.

---

Q: How would you detect anomalies in UPI transaction data?

*Situation:* Anomaly detection in payment data is a real problem PhonePe teams work on, so this tests both technical skill and domain understanding.

*Task:* The interviewer wants a practical approach, not a textbook answer about model types.

*Action:* I would start by defining 'normal' for key metrics: transaction count per hour, failure rate, average transaction value, and merchant-level volumes. I would use rolling averages and standard deviation bands to flag anything outside the expected range. For sudden spikes or drops, a percentage-change threshold catches most real-time issues. For more gradual drift, such as a slowly rising failure rate for a specific bank, I would run daily cohort comparisons against a baseline period.

*Result:* In a past role, setting up daily anomaly alerts reduced the time to spot data issues from several hours to under 30 minutes. The right method depends on latency needs: real-time dashboards need simple threshold rules, while batch jobs can support more complex detection.

For SQL questions: Think out loud before writing. State your assumptions (for example, 'I am assuming each row is one transaction'). Build the query in steps: filter first, then aggregate, then add window functions if needed. PhonePe interviewers reportedly value readable, well-structured SQL over clever one-liners.

For product analytics questions: Clarify the metric definition first, then segment by user type, time, acquisition channel, and geography. State what you would examine first and why. End with a clear recommendation or next step, not just a list of observations.

For root-cause investigation questions: Use hypothesis-driven thinking. List two or three plausible causes, explain what data you would pull to confirm or rule out each, and say which you would investigate first and why. This signals that you think before you query.

For behavioural questions: Use the STAR structure: Situation, Task, Action, Result. Keep the Situation to one or two sentences. Put the bulk of your answer into the Action section, focusing on what you specifically did rather than what the team did. Always close with a concrete Result.

PhonePe data teams typically look for a few qualities that go beyond raw SQL skill.

Business context awareness. PhonePe operates across payments, insurance, wealth, and commerce. Candidates who can reason about fintech metrics (why a payment failure rate has a different urgency than an email open rate, for example) and who understand UPI flows at a basic level tend to stand out.

Clear communication. Candidates report that interviewers push back with follow-up 'why' questions to test whether you can defend your reasoning. Explaining your SQL logic or analytical approach in plain, jargon-free language is rated highly.

Ownership mindset. Behavioural questions often probe whether you identified problems on your own initiative or waited to be asked. Framing your experience around problems you spotted and drove to resolution lands better than listing tasks you were assigned.

Comfort with ambiguity. Many questions are deliberately open-ended. Candidates who ask one or two good clarifying questions before diving in score better than those who rush to answer with the first thing that comes to mind.

Week 1: SQL and analytics basics. Practice window functions, CTEs, aggregations, and multi-table joins using fintech-style scenarios such as transaction tables, user tables, and merchant tables. Write queries that are clean and easy to explain. LeetCode Medium SQL problems are a reasonable benchmark for the difficulty level.

Week 2: Product thinking and business case prep. Pick a few PhonePe products (UPI, Switch, Pincode, SmartSpeaker, insurance) and think through how you would measure success for each. Practice questions where two metrics point in different directions. Read publicly available fintech product teardowns to build domain context.

Week 3: Behavioural stories and resume review. Write three to five STAR stories from your experience. Cover: a time you found an important insight on your own, a time you worked with messy or incomplete data, a time you influenced a decision with analysis, and a time something went wrong and what you did. Practice saying these out loud until they flow naturally.

In the final days: Go through your resume line by line. Every project and metric you have listed is fair game for deep follow-up. Know how you calculated the numbers you cited.

If you are still actively searching while you prepare, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so you do not miss a PhonePe or similar opening while you are heads-down studying.

Writing SQL before thinking. Many candidates start coding the moment a question is asked. Take a few seconds to restate the problem, state your assumptions, and sketch the logic first. Interviewers typically give credit for clear thinking, not just correct output.

Vague product answers. Saying 'I would look at the data and find patterns' does not work here. Be specific: which metric, which segment, which table, and what change would concern you enough to escalate.

Not knowing your own resume. If you listed a project where you improved a metric, be ready to explain the methodology, the baseline you compared against, and what you controlled for. Candidates who cannot defend their own work leave a poor impression.

Skipping the clarifying question. On open-ended questions, jumping in without clarifying signals that you treat all problems the same. A single well-placed clarifying question shows analytical maturity.

Treating this as a pure tech interview. PhonePe data roles sit close to product and business teams. Candidates who only prepare SQL and neglect product thinking often clear the first technical screen but struggle in later rounds, based on what candidates have reported.