Paytm Analytics Engineer Interview Questions (2026)

1. 1Online Coding Test60 minMedium

   2-3 DSA problems on a hosted platform screening arrays, strings, and DP basics.

2. 2DSA Round 145 minMedium

   Live problem solving on medium DSA with emphasis on working code and edge cases.

3. 3DSA + Problem Solving Round 260 minHard

   Harder problem plus deep-dive on a past project's scale, failure handling, and payments edge cases.

4. 4System Design Round60 minHard

   Design a payments-adjacent system such as a wallet ledger or UPI transaction flow with reconciliation and idempotency.

5. 5Hiring Manager Round45 minMedium

   Discussion of ownership, delivery speed, past incidents, and why fintech; doubles as the behavioral round.

6. 6HR Round25 minEasy

   Compensation, notice period, and offer logistics; fast close.

1. Q1

   Design an A/B test for a new UPI Payments ranking or recommendation change. Define hypothesis, primary metric, guardrails, randomization unit, and launch decision rule

   MediumStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Context: Paytm wants to increase payment reliability and merchant adoption while controlling fraud.

   How to answer: A strong answer will define a clear, measurable hypothesis (e.g., new ranking increases successful transaction rate). The primary metric should directly reflect the business goal, such as 'Successful UPI Transaction Rate' or 'Value of Transactions'. Guardrail metrics are crucial for identifying negative side effects, like 'Failed Transaction Rate', 'App Crash Rate', or 'User Churn Rate'. The randomization unit must be carefully chosen, typically 'User ID' for personalized recommendations, ensuring consistent experience. Finally, the launch decision rule should specify statistical significance thresholds (e.g., p < 0.05) and minimum detectable effect for primary metrics, alongside no significant negative movement in guardrails over a defined period.

2. Q2

   During a Recharge experiment, the treatment/control split is 52/48 instead of 50/50. How would you diagnose sample ratio mismatch?

   MediumStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Assume assignment logs, exposure logs, and eligibility filters may disagree.

   How to answer: To diagnose sample ratio mismatch (SRM), I would first check the randomization unit (user ID, device ID, etc.) and ensure consistent assignment logic. Next, I'd verify data integrity by checking for data pipeline issues, logging errors, or late-arriving data that might disproportionately affect one group. I would also analyze pre-experiment metrics and user characteristics (e.g., demographics, past behavior) for both groups to see if any significant differences exist before the experiment even started. Finally, I'd investigate potential implementation errors in the A/B testing framework itself, such as incorrect bucketing logic or exposure issues.

3. Q3

   The Recharge experiment lifts payment success rate overall, but only for new users and only in one merchant_category. How would you evaluate heterogeneous treatment effects?

   HardStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Balance pre-planned segments with exploratory slicing and multiple testing risk.

   How to answer: A strong candidate would first acknowledge the overall lift but immediately pivot to the observed heterogeneity. They would propose segmenting the data by user tenure (new vs. existing) and `merchant_category` to isolate the specific uplift. Evaluation would involve running separate A/B tests within these identified segments, calculating statistical significance (p-values) and confidence intervals for each. Finally, they would discuss potential root causes for the heterogeneity and recommend targeted rollout strategies or further experimentation.

4. Q4

   Treatment improves payment success rate but worsens transaction failure rate for Paytm Postpaid. Walk through a launch recommendation

   HardStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Make a decision under conflicting metrics and quantify tradeoffs for stakeholders.

   How to answer: A strong candidate would first clarify the definitions of 'payment success rate' and 'transaction failure rate' and their relationship, as they often represent different stages or perspectives of the same process. They would then propose investigating the underlying causes for the divergence, potentially through segmenting users, analyzing specific failure codes, or examining the user journey funnel. The recommendation would hinge on understanding the business impact of each metric (e.g., revenue from success vs. customer churn from failure) and suggesting a phased rollout or further experimentation to mitigate risks, rather than a simple 'launch' or 'don't launch'.

5. Q5

   How would you design ramp-up, holdback, and post-launch monitoring for a successful Soundbox A/B test?

   HardStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Include ramp stages, persistent holdback, alert thresholds, rollback criteria, and owner accountability.

   How to answer: A strong candidate would outline ramp-up as a phased rollout (e.g., 1%, 5%, 20%, 50%, 100%) to monitor early performance and identify critical bugs or negative impacts before full exposure, using key metrics like transaction success rate, device uptime, and merchant feedback. For holdback, they would propose reserving a small, representative control group (e.g., 1-5%) from the winning variant post-launch to continuously validate long-term uplift and detect novelty effects or seasonal changes. Post-launch monitoring involves establishing a comprehensive dashboard tracking primary success metrics (e.g., GMV uplift, merchant retention), guardrail metrics (e.g., transaction failure rate, customer support tickets), and operational metrics (e.g., device health, battery life) with automated alerts for significant deviations. They would also mention the importance of ongoing qualitative feedback and periodic re-evaluation of the experiment's impact.

6. Q6

   Paytm's UPI Payments revenue suddenly drops 10% week over week. Structure a business case to diagnose the issue and identify the most likely drivers

   MediumProduct Analytics & Business CaseBusiness CasesPaytm-specific

   Context: Consider traffic, conversion, pricing, mix, supply/inventory, outages, marketing, and seasonality.

   How to answer: A strong candidate would structure their diagnosis by first confirming the data (source, scope, time period) and then segmenting the drop by key dimensions like user type (new vs. existing), transaction type (P2P vs. P2M), payment instrument, geography, and merchant category. They would then analyze external factors (regulatory changes, competitor actions, public sentiment) and internal factors (app updates, system outages, marketing campaign changes). Finally, they would prioritize potential drivers based on impact and ease of investigation, outlining a plan for deeper dive analysis and potential solutions.

7. Q7

   Paytm is considering launching Merchant QR in a new city tier. Build a decision framework and the first 90-day success metrics

   MediumProduct Analytics & Business CaseBusiness CasesPaytm-specific

   Context: Include demand, supply, operations, compliance, cost, and competitive positioning.

   How to answer: A strong answer will first define a decision framework for launching Merchant QR in a new city tier, focusing on market potential (merchant density, transaction volume, competitor presence), operational feasibility (logistics, sales force, support), and financial viability (CAC, LTV, payback period). It will then outline a phased approach for the first 90 days, starting with pilot launch and merchant onboarding, followed by transaction monitoring and user feedback collection. Success metrics will be categorized into acquisition (merchant onboarding rate, active merchants), engagement (transaction frequency, average transaction value), and operational efficiency (merchant churn, support ticket volume), with clear targets set for each.

8. Q8

   Marketing spend for Soundbox increased, but payment success rate did not. How would you evaluate whether spend is inefficient or the measurement is incomplete?

   HardProduct Analytics & Business CaseBusiness CasesPaytm-specific

   Context: Consider incrementality, attribution, channel mix, saturation, and lagged effects.

   How to answer: A strong candidate would first define success rate and identify potential confounding factors like seasonality, product changes, or competitor activity. They would propose segmenting the data by marketing channel, campaign, geography, and customer cohort to isolate the impact of the increased spend. The evaluation would involve analyzing the funnel from impression to successful payment, looking for drop-off points, and considering external factors like network issues or payment gateway downtimes. Finally, they would suggest A/B testing or controlled experiments for future marketing initiatives to establish causality more definitively.

9. Q9

   Build a one-page business review for Soundbox that explains what happened, why it happened, and what the team should do next

   HardProduct Analytics & Business CaseBusiness CasesPaytm-specific

   Context: Make it executive-ready: crisp narrative, key metrics, quantified impact, and action owners.

   How to answer: A strong answer will structure the review into three main sections: 'What Happened' (key metrics like Soundbox activations, daily active devices, transaction volume/value, and merchant retention), 'Why It Happened' (analysis of contributing factors such as marketing campaigns, competitor actions, seasonal trends, product improvements/bugs, or sales force effectiveness), and 'What's Next' (actionable recommendations based on the 'why', including specific initiatives for growth, retention, feature development, or operational improvements, along with proposed metrics to track success). The candidate should demonstrate an understanding of Paytm's business model and the Soundbox's role within it.

10. Q10

    Design a real-time operations dashboard for Wallet focused on transaction failure rate. What thresholds, alerts, and ownership model would you set?

    EasyDashboarding, Stakeholder & Hiring Manager RoundDashboardingPaytm-specific

    Context: Assume the team needs to detect issues quickly and prevent alert fatigue.

    How to answer: A strong answer would outline a dashboard with key metrics like real-time transaction count, successful transactions, failed transactions, and the overall transaction failure rate, broken down by failure reason (e.g., network error, user timeout, bank decline, system error). It would propose dynamic thresholds for failure rate (e.g., 1% warning, 3% critical) with automated alerts (SMS, Slack, PagerDuty) triggered when these are breached, including a 'no data' alert. The ownership model would involve a primary SRE/DevOps team for infrastructure and system-level failures, a product/business team for user experience and bank-related issues, and an analytics team for monitoring and trend analysis, with clear escalation paths.

11. Q11

    Set alert thresholds for payment success rate, net payment margin, and transaction failure rate in Soundbox. How would you distinguish noise from a real incident?

    MediumDashboarding, Stakeholder & Hiring Manager RoundDashboardingPaytm-specific

    Context: Use seasonality, baselines, statistical thresholds, and business severity.

    How to answer: A strong answer would propose setting thresholds based on historical data analysis (e.g., standard deviations, moving averages) and business context for each metric. For payment success rate and net payment margin, define lower bounds that trigger alerts, while for transaction failure rate, define an upper bound. To distinguish noise, candidates should suggest implementing time-based aggregation (e.g., alert only if the threshold is breached for X consecutive minutes/hours), comparing current trends against historical baselines, and considering the volume of transactions impacted. Finally, mention the importance of A/B testing alert thresholds and involving domain experts for fine-tuning.

12. Q12

    Create a dashboard narrative for Bank partnerships lead explaining why payment success rate changed for Merchant QR. What charts would you show first?

    HardDashboarding, Stakeholder & Hiring Manager RoundDashboardingPaytm-specific

    Context: Use a top-down story with impact, drivers, segments, and recommended actions.

    How to answer: The dashboard narrative should start with a clear summary of the success rate change (increase/decrease, magnitude, timeframe) and its impact on revenue/transactions. Then, it should break down the success rate by key dimensions like acquiring bank, issuing bank, network (Visa/MC/Rupay), transaction amount ranges, and merchant category/type to pinpoint the root cause. Finally, it should propose actionable insights or next steps based on the identified drivers, such as engaging specific banks or optimizing network routing. The initial charts should be a trend line of success rate, a breakdown by acquiring bank, and a breakdown by issuing bank.

13. Q13

    Wallet's conversion from payment_start to payment_success dropped 15% week over week. Walk through your diagnosis plan

    EasyProduct Analytics & Business CaseProduct AnalyticsPaytm-specific

    Context: Assume no single obvious outage has been announced.

    How to answer: My diagnosis plan would start by confirming the data accuracy and definition of 'conversion' (payment_start to payment_success). Next, I'd segment the drop by key dimensions like platform (iOS, Android, Web), payment method within Wallet (e.g., UPI, Net Banking), user type (new vs. existing), transaction value, and merchant category to pinpoint specific areas. Concurrently, I'd check for recent code deployments, A/B tests, or external service outages that could impact the payment flow. Finally, I'd analyze user behavior funnels immediately preceding the drop-off point to identify UI/UX issues or error messages.

14. Q14

    For UPI Payments, how would you measure supply-demand balance between customers and merchants?

    MediumProduct Analytics & Business CaseProduct AnalyticsPaytm-specific

    Context: Examples include availability, wait time, search zero-results, acceptance, inventory, or partner response rate.

    How to answer: To measure supply-demand balance for UPI payments, I would define 'supply' as the availability and willingness of merchants to accept UPI payments (e.g., active merchant QR codes, successful transaction rates) and 'demand' as the customer's intent and ability to make UPI payments (e.g., active users, transaction attempts). Key metrics would include transaction success rates, payment attempt-to-completion ratios, and geographical/temporal distribution analysis of both successful and failed transactions. I would also segment by merchant type and customer demographics to identify specific imbalances and potential root causes, such as network issues, merchant onboarding gaps, or customer friction points. Ultimately, the goal is to identify where supply (merchant acceptance) is insufficient for demand (customer attempts) or vice-versa, leading to friction or missed opportunities.

15. Q15

    You own the weekly business review for UPI Payments. What metrics go on the first page, and what drill-downs should be ready?

    HardProduct Analytics & Business CaseProduct AnalyticsPaytm-specific

    Context: Design for executive actionability rather than metric dumping.

    How to answer: A strong answer will prioritize top-level business health metrics for UPI Payments on the first page, focusing on both growth and engagement. Key metrics include Total Payment Volume (TPV), Number of Transactions, and Active Users (Daily/Monthly). For drill-downs, candidates should prepare to segment these metrics by transaction type (P2P, P2M), user cohorts (new vs. existing), merchant categories, and geographical regions. Additionally, they should consider key performance indicators related to transaction success rates and average transaction value (ATV) for deeper insights.

Practice these with instant AI feedback in a live mock interview → Start a Paytm Analytics Engineer mock

Practise DSA and system design; revise CS fundamentals; prepare fintech-scale scenario answers

Indicative Analytics Engineer pay in India: ~₹9–40 LPA (role-level range, not a Paytm-specific figure).

Other roles at Paytm

Analytics Engineer interviews at other companies