razorpay Data Scientist Interview: Questions, Experience & Prep (2026)

Razorpay is one of India's leading fintech companies, processing payments for hundreds of thousands of businesses. The data science team sits at the core of fraud detection, credit risk, payment success optimisation, and product analytics. As of July 2026, Razorpay has 42 open data scientist roles, which signals active growth in the team.

Candidates report a structured process that typically runs across three to five rounds: an initial screening call or online assessment, one or two technical rounds covering statistics, ML, and SQL, a case-study or take-home round, and a final hiring-manager or leadership discussion. The exact structure can vary by team and seniority, so confirm the format with your recruiter.

Razorpay interviewers look for people who can translate model outputs into business decisions, not just people who can tune hyperparameters. Expect questions grounded in payments and fintech: fraud signals, transaction anomalies, imbalanced datasets, and real-time scoring. Preparation should mix ML fundamentals with Razorpay-specific product thinking.

These questions come up frequently, based on what candidates publicly report after interviewing at Razorpay for data science roles.

1. Walk me through how you would build a fraud detection model for payment transactions. What features would you engineer?
2. How do you handle severe class imbalance? Razorpay's fraud rate is very low, so what techniques would you apply?
3. You have a model in production. Transaction success rates drop overnight. How do you investigate whether it is a model issue or a data issue?
4. Explain precision vs. recall in the context of flagging fraudulent payments. Which would you prioritise and why?
5. How would you design an A/B test for a new checkout flow feature? What are the risks if transactions are not independent?
6. A merchant's churn probability score has increased sharply this week. Walk me through your analysis to find the root cause.
7. Write a SQL query to find merchants whose transaction failure rate increased significantly month-over-month.
8. How would you build a model to assign a credit limit to a small business applying for a Razorpay line of credit?
9. What is the difference between bagging and boosting? When would you choose XGBoost over logistic regression for a credit scoring model?
10. How do you monitor a deployed model for data drift in a high-velocity payments environment?
11. Describe a time you found an insight in data that changed a product or business decision.
12. Razorpay serves merchants ranging from solo sellers to large enterprises. How would you segment them, and what data would you use?

Use these as templates. Adapt them to your actual experience before your interview.

Q: How did you handle a severe class imbalance problem in a real project?

*Situation:* At my previous company, we built a model to detect suspicious login attempts. Fraudulent logins were rare, making up a very small share of all events, so a naive model that always predicted 'not fraud' would still appear highly accurate on paper.

*Task:* My job was to build a model that caught a meaningful share of fraud cases without overwhelming the operations team with false positives.

*Action:* I first aligned with the ops team on how many cases they could review per day, translating that into concrete recall and precision targets. I then tried three approaches: SMOTE oversampling on the minority class, class-weight adjustment in the loss function, and threshold tuning on a well-calibrated probability output. I evaluated each on a stratified hold-out set using PR-AUC rather than ROC-AUC, because ROC-AUC is misleadingly optimistic on imbalanced data.

*Result:* Threshold tuning on a weighted logistic regression gave the best PR-AUC. The final model caught substantially more fraud cases at a precision level the ops team could handle, and the business reported a meaningful reduction in fraud losses in the quarter after deployment.

Q: Describe a time you designed an experiment and what you learned from it.

*Situation:* Our product team wanted to test a new one-click checkout feature for returning customers. The hypothesis was that reducing steps would lift conversion.

*Task:* I was responsible for designing the A/B test, choosing the randomisation unit, and computing the required sample size.

*Action:* I chose to randomise at the user level rather than the session level, because the same user could see both variants across sessions and contaminate results. I ran a power analysis to determine the sample size needed to detect a practically meaningful lift at a standard significance level. I also checked for network effects: since merchants share checkout links, I verified that variant assignment would not leak between user groups. I set up guardrail metrics alongside the primary conversion metric so we could catch regressions early.

*Result:* The experiment ran for three weeks and showed a statistically significant lift in conversion for returning users. We also found that the feature had a slightly negative effect on first-time users, so we shipped it only for the returning-user segment. The team would not have discovered this without the segmented analysis.

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

*Situation:* The business team believed that merchants who used more Razorpay products were stickier and less likely to churn, and they wanted to invest in a large cross-sell campaign based on this belief.

*Task:* I was asked to validate this belief with data before significant budget was committed.

*Action:* I pulled about a year of transaction and product-usage data and built a survival analysis model to compare churn rates across single-product and multi-product merchants. I controlled for merchant size and industry category, because larger merchants naturally adopt more products and also churn less for unrelated reasons. After controlling for those confounders, the raw correlation between product count and retention shrank considerably.

*Result:* The insight shifted the campaign strategy. Instead of targeting all multi-product merchants broadly, the team focused the cross-sell push on mid-sized merchants in high-churn categories where multi-product adoption actually predicted lower churn. The post-campaign review showed stronger ROI on this refined targeting than the original broad approach would have delivered.

For model-design questions: Start with the business objective and success metric before touching algorithms. State what you are optimising (precision, recall, RMSE) and why that metric matches the business cost. Then describe feature engineering, model choice, and validation strategy. Razorpay interviewers want to see that you think in terms of business impact, not just model accuracy.

For SQL questions: Think out loud. State what tables you would need, how you would join them, and any edge cases such as nulls, duplicate rows, or time-zone differences in timestamp columns. Write the query step by step rather than trying to produce the full answer silently.

For product and metric questions: Use a structured breakdown: define the metric clearly, list the dimensions you would slice (merchant type, geography, device, payment method), and propose a root-cause tree before jumping to a conclusion. This shows analytical rigour.

For behavioural questions: Use the STAR structure. Situation (one or two sentences of context), Task (what you were responsible for), Action (what you specifically did, not what the team did), Result (a measurable outcome or a clear learning). Keep Situation and Task brief so you have room to go deep on Action and Result.

For model-monitoring questions: Cover three layers: data drift (input distributions shifting), concept drift (the relationship between features and target changing), and business-metric monitoring (transaction success rate, fraud rate). Mention alerting thresholds and how you would distinguish a model problem from a data-pipeline problem.

Fintech domain awareness. You do not need prior payments experience, but you should understand why fraud detection differs from churn prediction, why false negatives (missed fraud) carry a direct financial cost, and why model latency matters when a payment decision happens in milliseconds.

First-principles thinking. Interviewers often strip away standard solutions to see if you understand the underlying reasoning. If you say XGBoost, be ready to explain why gradient boosting is appropriate for this specific problem versus a simpler baseline.

Communication clarity. Data scientists at Razorpay work closely with product managers and engineers. Candidates report that interviewers pay attention to how clearly you explain a technical trade-off to a non-technical audience. Practice giving crisp, jargon-light explanations.

Ownership mindset. Razorpay is a fast-moving company. Interviewers want to hear that you have driven a project end to end, from data collection through deployment and monitoring, not just built a notebook and handed it off.

Honest handling of uncertainty. If you do not know something, say so and reason through it. Interviewers consistently flag candidates who bluff as a red flag. A thoughtful 'I am not sure, but here is how I would approach it' lands better than a confident wrong answer.

Week 1: Core ML and Statistics

Revise classification metrics (precision, recall, F1, PR-AUC, ROC-AUC) and know when each is appropriate. Practice explaining bias-variance trade-off, regularisation (L1 vs. L2), and tree-based models (Random Forest, XGBoost, LightGBM). Do at least five LeetCode medium SQL problems focused on window functions, aggregations, and joins.

Week 2: Fintech and Razorpay Context

Read Razorpay's engineering blog to understand how the company thinks about data and ML problems. Learn how payment flows work: the role of payment gateways, acquiring banks, and settlement cycles. Think through how you would engineer features for fraud, credit risk, and merchant churn from first principles. Practice explaining a model you have built in under two minutes.

Week 3: Case Studies and Behavioural

Practice two or three mock case studies: one fraud-detection design, one A/B test design, one metric deep-dive. Prepare four or five STAR stories covering: handling ambiguity, influencing without authority, catching a mistake, and delivering under pressure. Record yourself answering and review for filler words and clarity.

Before the interview: Research the specific Razorpay team you are interviewing with (payments, capital, or banking). Prepare two or three thoughtful questions for the interviewer about team structure, model deployment practices, and how data science work gets prioritised.

Jumping to a model before defining the problem. A common pattern is naming an algorithm in the first sentence of a model-design answer. Interviewers at Razorpay flag this. Always anchor to the business goal and success metric first.

Using accuracy as the only metric for imbalanced data. Given that fraud detection is central to Razorpay, you will almost certainly face a question where accuracy is misleading. Defaulting to accuracy signals a gap in applied ML experience.

Vague STAR answers. Saying 'we improved model performance' without stating what the metric was, what it changed, or what the business impact was makes the answer forgettable. Interviewers cannot calibrate your level without concrete outcomes.

Ignoring latency and scalability. Razorpay processes a high volume of transactions. If you propose a solution that requires a slow inference call in the critical payment path, expect a follow-up challenge. Think about where in the stack your model lives and what the latency budget is.

Not asking clarifying questions in case studies. Jumping straight into analysis without clarifying the business context, available data, or constraints is a red flag. Interviewers want to see structured thinking, and asking good questions is part of that.

Over-preparing for coding and under-preparing for communication. Many candidates who are strong in Python and SQL still struggle to explain their reasoning clearly to a product manager in a cross-functional round. Practice spoken explanations, not just written code.