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

Khatabook is one of India's leading fintech companies, best known for its digital ledger app used by millions of small and medium businesses across India. With 61 open Data Scientist roles currently listed, the company is actively hiring to work on transaction analysis, fraud detection, credit scoring, and merchant retention for its SME-focused products.

Candidates report a process that typically runs across 3-4 rounds: a screening call with HR or a recruiter, a technical assignment or take-home problem, a technical interview covering statistics and ML, and a final round with a hiring manager or a business stakeholder. The focus is on applied data science grounded in real fintech scenarios, not purely academic knowledge.

The role sits at the intersection of product analytics and ML. Interviewers want to see that you understand Indian small business data (irregular transactions, seasonal patterns, thin credit histories) and can translate model outputs into business decisions.

1. How would you build a model to predict whether a small business on Khatabook is likely to churn in the next 30 days?

2. Explain how you would handle a heavily imbalanced dataset in a fraud detection task. What evaluation metrics and resampling techniques would you use?

3. Khatabook's users often have irregular income patterns. How would you design features to capture this for a credit risk model?

4. Walk me through how you would design an A/B test for a new recommendation feature in the app. What metrics would you track and for how long?

5. A business analyst says your model's accuracy is high but the product team is not satisfied. How do you diagnose and resolve this?

6. How would you segment Khatabook's merchant base for a targeted marketing campaign? Which clustering approach would you choose and why?

7. Explain overfitting to a non-technical stakeholder. How have you handled it in a past project?

8. You are given transaction logs from millions of merchants. How would you identify anomalies that could indicate accounting errors or suspicious activity?

9. How would you measure the business impact of a newly deployed ML model at Khatabook?

10. Describe how you would build a recommendation system to suggest relevant financial products (loans, insurance) to merchants on the platform.

11. What would you do if your model performs well in offline evaluation but degrades after deployment?

12. How would you approach building a credit score for merchants who have no formal credit history but have built up a history of transactions on the platform?

Q: How would you build a churn prediction model for Khatabook merchants?

*Situation:* At my previous company, we had a SaaS product serving small retailers, and churn was a major business concern with the customer success team struggling to identify at-risk accounts early.

*Task:* I was asked to build a model that could flag accounts likely to stop using the platform within 30 days so the team could intervene before it was too late.

*Action:* I started by defining churn precisely with the product team: no login for 30 consecutive days. Then I pulled a trailing window of user activity data, including login frequency, number of transactions entered, time since last entry, and whether the user had set up any integrations. I trained a gradient boosting classifier, tuned it using the precision-recall curve rather than accuracy alone (since churned users were a minority), and validated on a held-out time window to prevent data leakage.

*Result:* The model identified at-risk accounts with enough lead time for the team to reach out proactively. The intervention campaign, tracked via a holdout group, showed a meaningful reduction in monthly churn. I also built a simple dashboard so the customer success team could act on scores without needing to query the model directly.

---

Q: Explain how you handled an imbalanced dataset in a fraud detection task.

*Situation:* I worked on a transaction monitoring pipeline where genuine fraud events were rare compared to normal transactions. Industry surveys commonly cite severe class imbalance as the norm in fintech fraud datasets, making standard accuracy metrics deeply misleading.

*Task:* My task was to improve the fraud catch rate without flooding the review team with false positives.

*Action:* I confirmed that accuracy was a misleading metric for this problem and switched to precision, recall, F1, and AUC-PR as my primary measures. I applied SMOTE to oversample the minority class in the training set only (never in validation or test splits). I also experimented with cost-sensitive learning by adjusting class weights in XGBoost. Finally, I selected the classification threshold by plotting the precision-recall curve and picking the operating point that matched the review team's daily capacity.

*Result:* The revised model caught a meaningfully higher share of suspicious transactions compared to the baseline, while keeping false positives manageable for the operations team. I documented the threshold choice clearly so it could be revisited if team capacity changed.

---

Q: How did you measure the business impact of a deployed ML model?

*Situation:* After deploying a product recommendation model at a previous role, my manager asked me to quantify its actual business value beyond offline metrics.

*Task:* I had to design a measurement framework that the finance and product teams would trust.

*Action:* I worked with engineering to set up a randomised holdout: a portion of users saw the model's recommendations, while a control group saw the old rule-based suggestions. I tracked downstream metrics including conversion rate, average order value, and 30-day retention. I also monitored for any negative effects on user experience. The experiment ran for several weeks to account for weekly seasonality.

*Result:* The model-driven group showed a statistically significant lift in conversion. I presented results with confidence intervals rather than just point estimates so leadership understood the uncertainty. This approach became the team's standard template for evaluating future model deployments.

The STAR format (Situation, Task, Action, Result) works well for behavioural and past-experience questions. Keep the Situation brief, spend most of your time on Action, and always close with a concrete Result, even if you have to say 'we estimated' or 'early signals showed.'

For ML design questions, follow this structure: (1) clarify the business goal and what success looks like, (2) define the target variable and data sources, (3) describe your feature engineering approach, (4) choose a model family and justify it, (5) explain evaluation and deployment, (6) mention monitoring after going live. Khatabook interviewers, candidates report, appreciate candidates who think about the full lifecycle, not just model training.

For product and metrics questions, always start by identifying the north star metric. Then break it down into leading indicators. For A/B tests, mention sample size, randomisation unit, and how long you would run the test before declaring a result.

For SQL or coding questions (candidates report these appear in technical rounds), think aloud. State your assumptions, write clean queries, and mention edge cases like nulls or duplicate rows, which are common in transaction data.

Handling 'I don't know': if you are unsure, say 'I haven't worked with that exact technique, but here is how I would approach it' and sketch a logical path. Candidates report that interviewers at Khatabook value intellectual honesty over bluffing.

Khatabook's Data Science team works on problems specific to Indian small businesses: thin data histories, cash-dominant transaction patterns, seasonal fluctuations tied to local festivals and regional cycles, and users with no formal credit records. Interviewers are looking for candidates who understand this context, not just someone who has memorised algorithms.

Business intuition matters as much as technical depth. Candidates who frame every answer in terms of 'what decision does this help the business make' stand out. Pure model accuracy without business context is a common red flag for interviewers.

Practical ML over textbook knowledge. Expect questions about handling missing data, dealing with data drift, debugging a model that works in development but fails in production, and communicating results to non-technical stakeholders.

Communication and collaboration. Data Scientists at Khatabook work closely with product managers, engineers, and business teams. Candidates who can explain a confusion matrix to a product manager or write a clear one-page summary of model findings are valued.

Ownership mindset. Candidates report that interviewers follow up with questions like 'what would you do next' or 'how would you improve this.' Show that you think beyond the immediate task.

Week 1: Foundations and company context
Review core statistics (probability, distributions, hypothesis testing) and key ML concepts (bias-variance tradeoff, regularisation, tree-based models). Read publicly available information about Khatabook's products, the problems they solve for small businesses, and recent news about their growth. Understand what a digital ledger product means for data: transaction frequency, merchant categories, and usage patterns.

Week 2: Applied ML and SQL
Practise end-to-end ML case studies: define the problem, engineer features, select a model, evaluate, and think about deployment. Revise SQL for aggregations, window functions, and joins, since transaction data analysis will almost certainly appear. Work through at least one imbalanced classification problem from start to finish.

Week 3: Mock interviews and assignments
Candidates report that Khatabook typically includes a take-home assignment involving a dataset. Practise structuring your analysis as a clean notebook with an executive summary at the top. Do two or three mock interviews focused on the STAR format for behavioural questions. Prepare a few stories from your past work covering impact, dealing with ambiguity, and cross-functional collaboration.

Day before the interview: review your resume line by line. For every project listed, be ready to explain the business problem, your specific contribution, the data you used, and the outcome. Do not list tools you cannot confidently discuss.

If you are actively applying while prepping, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so your energy stays on interview prep rather than application tracking.

Jumping into modelling before defining the problem. Interviewers often ask open-ended questions deliberately. Candidates who start talking about specific algorithms before asking 'what does success look like here' miss a big signal. Always clarify the business goal first.

Treating accuracy as the only metric. For any problem with class imbalance (fraud, churn, default prediction), leading with accuracy is a red flag. Know when to use precision, recall, F1, or AUC-PR instead.

Over-engineering on a whiteboard. Candidates sometimes propose a complex deep learning pipeline when a well-tuned gradient boosting model would do the job. Khatabook interviewers, candidates report, prefer practical and maintainable solutions over impressive-sounding complexity.

Not knowing your past projects in depth. If your resume mentions a recommendation system, expect to be asked exactly how you handled cold start, how you evaluated it, and what you would change now. Vague answers here hurt credibility.

Ignoring deployment and monitoring. Many candidates describe the training pipeline in detail but go blank when asked 'how would you know if this model is degrading in production.' Have an answer ready about monitoring data drift, tracking model metrics over time, and setting up alerts.

Weak SQL under pressure. Transaction data questions are common. If SQL is on your resume, practise writing queries by hand, not just running them in a notebook.