Razorpay Data Scientist Mock Interview and Preparation

After an initial screen, Razorpay data science candidates usually see a mix of rounds:

• SQL and data manipulation: joins, window functions and aggregations on transaction and merchant data.
• ML fundamentals: model selection, regularisation, evaluation under imbalance.
• Applied case: a payments problem such as fraud, payment-success optimisation or merchant risk, end to end.
• Statistics and experimentation: hypothesis testing, A/B design, interpretation.
• Behavioural/stakeholder: translating models into decisions for product and risk teams.

The signal Razorpay wants is a scientist who improves a payments or risk metric and can defend the trade-offs to non-technical partners.

Expect problems like predict and improve payment success rate by choosing the best routing or retry strategy, detect fraudulent transactions, score merchant risk for underwriting, or predict merchant churn. Payment-success optimisation is a distinctive Razorpay theme: framing it as choosing an action (which bank route or retry timing) to maximise success brings in uplift and decisioning ideas beyond plain classification.

A strong fraud or risk answer handles severe class imbalance, chooses precision-recall and cost-weighted metrics, discusses real-time constraints and feedback loops, and weighs the cost of false declines against missed fraud. A weak answer chases offline AUC and ignores the operating point and business cost.

SQL is frequently an early filter. Practise window functions (success rate over rolling windows, rank by transaction value), cohort retention for merchants, and joins across payments, merchants and instruments. Talk through your logic while writing.

On statistics, be fluent in hypothesis testing, confidence intervals and experiment design. Razorpay ships changes via experiments, so be ready to design an A/B test on a routing or checkout change, choose the metric and randomisation unit, estimate sample size, and interpret results where payment success improves but another guardrail moves. Understanding why an offline uplift may not hold online is a strong signal.

SQL fluency and clean experiment reasoning are the through-line for most Data Analyst / Data Science Jobs at this bar, so the drills below pay off well beyond a single Razorpay loop.

Concentrate on three tracks. Rehearse two applied cases end to end, ideally a payment-success or routing problem and a fraud/risk classification problem, including the imbalanced-data evaluation story. Drill SQL windows and cohorts. Sharpen A/B design and interpretation.

• Keep cost-of-error and operating-point reasoning ready, since it is central to payments modelling.
• Prepare a story where your analysis changed a product or risk decision and how you communicated it.

Then practise explaining it aloud. A free AI voice mock on InterviewPrep builds a Razorpay-style data science mock from your CV and a target job description, and scores your answers, pace and filler words, so your trade-off explanations stay clear under pressure.

The most distinctive Razorpay data science theme is improving payment success rate, and the candidates who shine reframe it from pure prediction to decisioning. You are not just predicting whether a payment will fail; you are choosing an action, such as which bank route to use or when to retry, to maximise the chance of success. That shift brings in uplift modelling and policy evaluation rather than a single classifier.

• Define success carefully: distinguish a genuine decline from a recoverable failure, and separate issuer-side from network-side causes, because the right action differs.
• Think counterfactually: you only observe the outcome of the route you chose, so discuss how you would learn a better routing policy, perhaps via controlled exploration or offline policy evaluation.
• Mind the guardrails: an aggressive retry strategy can lift success but annoy users or breach limits, so weigh the trade-off explicitly.

For fraud and merchant-risk problems, apply the same discipline you would at any fintech: reject accuracy on rare events, reason about the operating point and cost of errors, and plan for drift and feedback delay. A common mistake is treating every problem as offline classification and ignoring that the model's output triggers a real action with real consequences. Show that you connect the model to the decision and the business metric, and you will read as a scientist who ships impact at Razorpay. When you present a result, state the baseline you beat, the assumption you are least sure about, and how you would monitor the metric after launch, since that candour is what senior interviewers trust most.