Kotak Mahindra Bank Data Scientist Interview: Questions, Experience & Prep (2026)

Kotak Mahindra Bank is one of India's largest private sector banks, and its data science teams work on credit risk models, fraud detection, customer segmentation, and product recommendations across banking, insurance, and wealth management. With 946 open roles at the company, Kotak is actively hiring analytics talent at multiple seniority levels.

Candidates report a process that typically runs 3-5 rounds: an HR or talent acquisition screening call, one or two technical interviews covering statistics, machine learning, and SQL, a case study or take-home assignment, and a final managerial round. The full process commonly takes 2-4 weeks. Kotak interviewers tend to connect ML concepts to real banking problems, so expect questions that blend technique with domain context.

Salary ranges for Data Scientists, based on knok jobradar market data:

Actual offers depend on the specific team, location, and negotiation.

These questions appear regularly in Kotak Data Scientist interviews, based on candidate reports. They reflect the bank's focus on applied ML, financial domain knowledge, SQL, and responsible data use.

1. Walk me through a machine learning model you built end-to-end. What problem did it solve and how did you measure success?
2. How would you build a credit default prediction model? What features would you use and why?
3. A fraud detection model is flagging too many legitimate transactions. How do you fix the precision-recall trade-off without retraining from scratch?
4. Explain gradient boosting to someone who has not studied ML. How does it differ from a random forest?
5. We have a dataset with a high percentage of missing values in a key feature. What are your options and how do you decide which approach to use?
6. Write a SQL query to find the top 5 customers by transaction volume in the last 30 days, broken down by product type.
7. How do you handle class imbalance when building a churn model for a banking product?
8. A business team says your model is biased against certain customer segments. How do you investigate and respond?
9. What is the difference between L1 and L2 regularisation? When would you choose one over the other?
10. How would you design an A/B test for a new loan product recommendation feature? What metrics would you track?
11. How do you monitor a model in production? What signals tell you the model is degrading?
12. Kotak serves customers across very different income brackets. How do you make sure your model generalises across segments rather than overfitting to the most common profile?

Use these STAR-format answers as a starting point and replace the specifics with your own experience.

Q: Walk me through a machine learning model you built end-to-end.

*Situation:* At my previous company, the collections team was calling all overdue borrowers equally, wasting agent time on accounts that would self-cure.

*Task:* I was asked to build a model that would score each overdue account by its probability of going severely past due within the coming weeks.

*Action:* I pulled repayment history, bureau data, and in-app behaviour signals over a multi-month window. I trained an XGBoost classifier, handled class imbalance with SMOTE, and tuned the decision threshold to prioritise recall on high-risk accounts. I worked with the collections lead to validate the output on a held-out period before deployment.

*Result:* The model correctly flagged a large portion of accounts that later defaulted. Agent efficiency improved noticeably, and the team could prioritise outreach more cost-effectively. We were still measuring longer-term impact when I moved on.

---

Q: How do you handle class imbalance in a churn model?

*Situation:* I worked on a churn model for a fintech product where only a small fraction of users churned in any given month.

*Task:* My goal was to build a model with enough precision to make targeted retention campaigns cost-effective.

*Action:* I compared oversampling with SMOTE, undersampling, and class-weight adjustments inside the model. I evaluated each approach using AUC-ROC and precision-recall curves, since accuracy was misleading with such skewed labels. I also used stratified cross-validation to ensure the minority class was represented in every fold.

*Result:* The class-weight approach combined with threshold tuning gave the best business outcome. The retention team could act on the top decile of predicted churners with a hit rate high enough to justify the campaign spend.

---

Q: How would you design an A/B test for a new loan recommendation feature?

*Situation:* A product manager wanted to test whether showing a personalised loan offer on the home screen increased application rates.

*Task:* I was asked to design the experiment and define success criteria before the feature launched.

*Action:* I set the randomisation unit as customer ID to avoid contamination. I defined the primary metric as loan application rate and guardrail metrics as session drop-off and complaint rate. I calculated the required sample size based on the baseline conversion rate and the minimum detectable effect the business cared about, then proposed a run time covering at least two full weekly cycles.

*Result:* The test ran cleanly, the product team had a clear read within the agreed window, and the feature launched with confidence. I documented the experiment design so the team could reuse it.

For technical ML questions: Start with problem framing: what are you predicting and why does it matter? Name the algorithm and give one sentence on why you chose it. Walk through data preparation, training, evaluation, and deployment. Always name the metric you are optimising and the trade-offs involved. Kotak interviewers probe on 'why this metric,' so be ready to defend your choice.

For case study questions: Clarify the goal and constraints before jumping to a solution. Ask one or two questions if allowed. Then walk through feature engineering logic, model selection rationale, validation approach, and a monitoring plan. Banking models face regulatory scrutiny, so mentioning model fairness and drift detection signals maturity.

For behavioural questions: Use STAR: Situation, Task, Action, Result. Keep Situation and Task combined to 2-3 sentences. Spend most time on Action. Make the Result specific: if you do not have a number, state what changed qualitatively and explain why the exact figure is not available.

For SQL questions: Think out loud before writing. State your approach, then code it. Use CTEs to keep queries readable. Kotak interviews almost always include at least one SQL question, so practise window functions, GROUP BY with HAVING, and joins on large tables.

Kotak Data Scientist interviewers typically look for four things.

Domain curiosity. They want to see that you understand why financial data is different: high-stakes decisions, regulatory constraints, and customers with very varied financial literacy. Candidates who connect ML knowledge to banking problems (credit, fraud, collections, cross-sell) consistently stand out.

Rigour over cleverness. A well-validated logistic regression often beats a poorly understood neural network in a banking context. Interviewers value candidates who know when a simpler model is the right call and can explain the reasoning clearly to a non-technical audience.

Cross-functional communication. Data scientists at Kotak work closely with risk teams, product managers, and compliance officers. Candidates who can translate technical results into business language, and who ask good clarifying questions during case studies, tend to get strong feedback.

Ownership and follow-through. Kotak's analytics teams move fast and are typically lean. Interviewers look for candidates who have shipped models to production, dealt with real deployment issues, and iterated based on results rather than just building prototypes.

Week 1: Technical foundations. Revise the statistics that come up most in banking ML: Bayes' theorem, probability distributions, hypothesis testing, and p-values. Practice SQL with window functions and multi-table joins. Solve at least 10 LeetCode SQL problems at medium difficulty.

Week 2: ML depth and domain knowledge. Review tree-based models (decision trees, random forests, gradient boosting) and regularised linear models. Read about credit scoring basics (logistic regression with scorecards) and fraud detection (anomaly detection, real-time inference). Understand model fairness fundamentals, since banking regulators care about it and Kotak interviewers raise it.

Week 3: Case study practice and behavioural prep. Practise 2-3 end-to-end case studies out loud. Prepare STAR answers for common themes: dealing with messy data, a model that underperformed, explaining a complex result to a non-technical audience. Record yourself and listen back to catch filler words and vague answers.

Week 4: Company research and mock interviews. Read Kotak's recent annual report section on digital and analytics initiatives. Look at current Kotak Data Scientist job descriptions for the specific tools mentioned (Python, PySpark, cloud platforms). Do at least two mock interviews with a peer or on a practice platform. Prepare two thoughtful questions for the end of each round.

If you are actively applying while you prepare, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR on your behalf, so you do not miss live openings at Kotak or similar banks while you are deep in interview prep.

Skipping the business framing. Candidates often jump straight to the algorithm. Kotak interviewers want to know you understand why the model matters before they care about how you built it.

Relying only on academic examples. If every example comes from a Kaggle competition or a university project, it signals limited production experience. Where possible, use examples from real work, internships, or freelance projects.

Ignoring the precision-recall trade-off. In credit and fraud, false positives and false negatives have very different costs. Saying 'I optimised for accuracy' without any nuance is a red flag for Kotak interviewers who deal with these trade-offs daily.

Weak SQL. Many candidates prepare ML heavily but neglect SQL. Kotak's environment relies on structured data, and a stumble on a medium-difficulty SQL question can hurt an otherwise strong interview.

Not asking questions. Candidates who ask nothing at the end of a round are seen as less engaged. Prepare at least two questions per round. Good ones: ask about the team's current data infrastructure, or what a successful first three months in the role looks like.

Over-claiming results. Saying your model improved revenue by some large specific amount without being able to back up the methodology raises credibility concerns. It is better to say 'the team reported a positive impact, though I do not have the final number' than to invent a figure.