Paytm Data Analyst 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

   Choose primary and guardrail metrics for a Merchant QR experiment aimed at improving payment success rate. What metrics would prevent a harmful launch?

   MediumStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Include user experience, partner health, revenue, reliability, and long-term retention considerations.

   How to answer: For a Merchant QR experiment focused on payment success rate, the primary metric should be 'Payment Success Rate' (successful transactions / total initiated transactions) to directly measure the experiment's goal. Guardrail metrics are crucial to prevent negative side effects. Key guardrails would include 'Average Transaction Value' (ATV) to ensure the change isn't driving smaller transactions, 'Number of Failed Transactions' to monitor absolute failures, and 'Merchant Churn Rate' or 'Active Merchants' to ensure the change doesn't negatively impact merchant satisfaction or retention. Additionally, 'Payment Latency' could be a guardrail to ensure the improved success rate isn't at the cost of slower transactions.

2. Q2

   The Paytm Postpaid experiment is trending positive after two days. A PM wants to stop early and launch. How do you handle peeking and sequential testing?

   MediumStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Discuss pre-specified stopping rules, alpha spending, business urgency, and risk.

   How to answer: A strong candidate would first explain that peeking early in an A/B test inflates the Type I error rate, leading to false positives. They would then discuss the need for a pre-determined sample size and test duration based on power analysis, and the risks of not adhering to it. The candidate should propose solutions like sequential testing methods (e.g., using O'Brien-Fleming boundaries or Group Sequential Designs) if early stopping is truly desired, or simply advocating for patience and letting the experiment run its course to the planned duration. Finally, they would emphasize the importance of statistical rigor for reliable decision-making at Paytm.

3. Q3

   A new Soundbox feature shows a large week-1 lift in payment success rate, but the effect fades by week 4. What could explain this and how would you design the test duration?

   MediumStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Discuss novelty, learning effects, seasonality, and durable impact.

   How to answer: The fading effect suggests a novelty effect or a change in user behavior over time. Initial excitement or increased attention to the new feature could cause an early lift, but as users habituate, the effect diminishes. Alternatively, the feature might be solving a short-term problem that users adapt to, or it could be displacing other positive behaviors. Test duration should be long enough to capture the full user lifecycle and account for habituation, seasonality, and potential long-term negative effects, typically 4-8 weeks for significant feature changes, with continuous monitoring post-launch.

4. Q4

   payment success rate is a low-frequency event for Wallet. How would you set up an experiment with enough power without waiting too long?

   MediumStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Discuss proxy metrics, variance reduction, larger samples, longer windows, and risk of metric gaming.

   How to answer: To address the low-frequency nature of payment success rate, focus on selecting a more frequent, correlated proxy metric that occurs earlier in the user journey. This could be 'initiation of payment' or 'reaching the payment confirmation screen.' Increase the sample size significantly to detect smaller effect sizes, and consider using a sequential testing approach to stop the experiment early if a clear winner emerges. Additionally, evaluate the practical significance of the observed lift, even if statistically significant, to ensure it justifies the change.

5. Q5

   Design a geo or city tier-level experiment for Merchant QR. When is this better than user-level randomization, and what are the analytical downsides?

   MediumStatistics & Experimentation RoundA/B TestingPaytm-specific

   Context: Use matched markets, pre-period balancing, spillover checks, and fewer experimental units.

   How to answer: A strong candidate would outline designing a geo-level experiment by defining experimental units as cities or city tiers (e.g., Tier 1, Tier 2), randomizing these units into control and treatment groups, and then applying the Merchant QR change within the treatment geos. This approach is superior to user-level randomization when there's a high risk of network effects or spillover between users within the same geographic area, or when the intervention itself is location-dependent (e.g., physical infrastructure changes). However, the analytical downsides include reduced statistical power due to fewer experimental units, increased variance, and the potential for confounding if geographic units are not truly comparable, making it harder to detect smaller effects and requiring longer experiment durations.

6. Q6

   Estimate the business impact of changing pricing, commission, delivery fee, or ad load for Wallet. What assumptions and sensitivities would you model?

   MediumProduct Analytics & Business CaseBusiness CasesPaytm-specific

   Context: The interviewer is testing whether you connect metrics to profit, not just top-line growth.

   How to answer: A strong candidate would outline a framework for estimating business impact, starting with defining the specific change (e.g., 5% reduction in delivery fee). They would then identify key metrics affected (e.g., transaction volume, average order value, customer acquisition/retention, revenue, profit margin). The core would involve modeling the elasticity of demand for each change and quantifying the direct and indirect effects on revenue and costs. Finally, they would discuss necessary assumptions (e.g., competitor response, market conditions) and sensitivities (e.g., varying elasticity, cost structures) to provide a robust impact estimate.

7. Q7

   Fraud, abuse, or policy gaming is suspected in UPI Payments. Size the financial impact and propose an analytics approach to reduce it

   HardProduct Analytics & Business CaseBusiness CasesPaytm-specific

   Context: Balance loss prevention with false positives and user/partner experience.

   How to answer: A strong candidate would first define the scope of 'fraud, abuse, or policy gaming' within UPI, categorizing common scenarios (e.g., synthetic identity fraud, transaction laundering, promo abuse). They would then propose a sizing methodology, likely involving sampling suspicious transactions, estimating loss per transaction, and extrapolating to the total affected population, considering both direct financial loss and indirect costs (e.g., reputational damage, operational overhead). For the analytics approach, they would suggest a multi-pronged strategy: anomaly detection (e.g., using transaction velocity, unusual patterns, network analysis), rule-based systems, and potentially machine learning models (e.g., supervised learning on labeled fraud data, unsupervised for novel attacks). Finally, they would emphasize continuous monitoring, A/B testing of mitigation strategies, and collaboration with risk and product teams.

8. Q8

   Wallet is preparing for a high-traffic event or sale. What metrics and analyses would you use to prevent a business-critical failure?

   HardProduct Analytics & Business CaseBusiness CasesPaytm-specific

   Context: Think capacity, inventory, payments, support load, latency, and real-time alerting.

   How to answer: A strong candidate would outline key metrics across system performance, user experience, and business impact, focusing on real-time monitoring and pre-event analysis. They would propose specific metrics like API latency, error rates, transaction success rates, payment gateway success rates, and user funnel conversion rates. The analysis would involve capacity planning based on historical data and projected traffic, load testing results, and setting up intelligent alerting thresholds. Finally, they would discuss a rollback plan and incident response protocols for critical failures.

9. Q9

   Inventory, capacity, or availability constraints limit Merchant QR. How would you prioritize scarce supply across customers, regions, or categories?

   HardProduct Analytics & Business CaseBusiness CasesPaytm-specific

   Context: Use margin, fairness, service-level promises, strategic segments, and long-term retention.

   How to answer: A strong candidate would first identify the primary business objective (e.g., maximizing revenue, market share, or customer lifetime value) and the specific constraint type. They would then propose a data-driven prioritization framework, likely involving a scoring model that considers factors like merchant transaction volume, potential for growth, strategic importance (e.g., new market entry, high-value category), and customer segment value. The framework should be dynamic and adaptable, allowing for A/B testing of different allocation strategies and continuous optimization based on performance metrics. Finally, they would discuss the practical implementation challenges and how to communicate the rationale to internal and external stakeholders.

10. Q10

    Evaluate the ROI of a loyalty, subscription, or membership benefit attached to Recharge. How do you avoid mistaking selection bias for program impact?

    HardProduct Analytics & Business CaseBusiness CasesPaytm-specific

    Context: Use cohorts, holdouts, propensity, causal design, and margin-based economics.

    How to answer: To evaluate ROI, define clear metrics (e.g., increased recharge frequency/value, reduced churn, cross-sell) and establish a control group. Calculate incremental revenue and subtract program costs (benefits, marketing, operational). To avoid selection bias, implement A/B testing or use quasi-experimental methods like difference-in-differences (DiD) on historical data, ensuring the control group is comparable in relevant characteristics. A strong answer will also discuss the long-term strategic value beyond immediate ROI, such as customer lifetime value (CLTV) and brand loyalty.

11. Q11

    You need to create a self-serve dashboard for Merchant QR that PMs and business teams will use weekly. How do you define metrics and prevent misuse?

    EasyDashboarding, Stakeholder & Hiring Manager RoundDashboardingPaytm-specific

    Context: Include metric glossary, data freshness, filters, caveats, and examples.

    How to answer: A strong candidate would first identify the primary users (PMs, business teams) and their core objectives related to Merchant QR, such as growth, retention, and transaction value. They would then define key metrics across these areas, distinguishing between leading and lagging indicators (e.g., new QR activations, active QRs, transaction volume, average transaction value, merchant churn rate). To prevent misuse, they would emphasize clear metric definitions, provide context and segmentation options (e.g., by geography, merchant type), and implement data governance measures like tooltips, documentation, and access controls. Finally, they would suggest a feedback loop for dashboard improvements and user training.

12. Q12

    A UPI Payments dashboard is slow and users export raw data instead. How would you improve performance and adoption?

    MediumDashboarding, Stakeholder & Hiring Manager RoundDashboardingPaytm-specific

    Context: Discuss aggregated tables, filters, caching, chart pruning, and stakeholder training.

    How to answer: To improve performance, I would first investigate the underlying data source and query logic, optimizing SQL queries, indexing relevant columns, and potentially denormalizing data or using materialized views. For the dashboard itself, I'd explore server-side rendering, data aggregation at a higher level, and caching mechanisms. To boost adoption, I would conduct user interviews to understand specific pain points and missing features, then prioritize improvements based on user needs, ensuring the dashboard provides actionable insights and is easily navigable. Finally, I'd implement user training and communication around new features and performance enhancements.

13. Q13

    How would you audit a dashboard for Wallet after stakeholders report that numbers do not match finance or operations reports?

    MediumDashboarding, Stakeholder & Hiring Manager RoundDashboardingPaytm-specific

    Context: Trace metric definitions, source tables, filters, timezones, freshness, and access rules.

    How to answer: A strong candidate would first suggest validating the data sources, ensuring the dashboard pulls from the correct and most up-to-date tables or APIs, and comparing the dashboard's data refresh schedule with that of the finance/operations reports. Next, they would focus on data definitions and filters, checking if key metrics like 'active users' or 'transaction value' are calculated identically across all reports and if any date ranges, geographical filters, or user segmentations differ. Finally, they would perform a sample-based reconciliation, picking a specific date or transaction ID and tracing its value from the raw data through the dashboard's aggregation logic to identify discrepancies.

14. Q14

    Design role-based access and privacy rules for a Recharge dashboard that includes customer or partner-level details

    HardDashboarding, Stakeholder & Hiring Manager RoundDashboardingPaytm-specific

    Context: Include aggregation, masking, row-level security, audit logs, and legitimate use cases.

    How to answer: A strong answer will define user roles (e.g., Customer Support, Partner Manager, Regional Head, Executive) and map specific data access levels to each. It should detail privacy rules like data masking for sensitive PII (e.g., full mobile numbers, bank details) for lower-tier roles, while allowing higher-tier roles aggregated or anonymized views. The design must incorporate row-level security (RLS) to restrict data visibility to only relevant customers/partners for specific users, and column-level security (CLS) to control which data fields are visible. Finally, it should mention audit logging for access and changes, and the use of a robust access control system (e.g., RBAC) within the dashboarding tool.

15. Q15

    Define a north-star metric for Paytm's UPI Payments. What input metrics and guardrails would you track to ensure it is not gamed?

    EasyProduct Analytics & Business CaseProduct AnalyticsPaytm-specific

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

    How to answer: The North-Star Metric for Paytm's UPI Payments should be 'Monthly Active Users (MAU) making at least one successful UPI transaction'. Input metrics would include 'Number of successful transactions per user', 'Average transaction value', 'Transaction success rate', and 'User retention rate'. Guardrail metrics would focus on 'Fraudulent transaction rate', 'Customer support ticket volume related to UPI', and 'Transaction dispute rate' to prevent gaming and ensure a healthy ecosystem.

Practice these with instant AI feedback in a live mock interview → Start a Paytm Data Analyst mock

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

Indicative Data Analyst pay in India: ~₹6–22 LPA (role-level range, not a Paytm-specific figure).

Other roles at Paytm

Data Analyst interviews at other companies