lendingkart Data Scientist Interview: Questions & Prep (2026)

Lendingkart is one of India's leading digital lending platforms, focused on small business loans and MSME credit. With 72 open Data Scientist roles currently tracked by knok, the company is actively scaling its analytics and risk teams. Data Scientists at Lendingkart work on credit risk modelling, fraud detection, loan underwriting automation, and customer behaviour analytics.

The interview process typically spans three to four rounds: a technical screening call, one or two deep-dive rounds covering ML and statistics, and a final managerial or case-study round. Candidates report that the focus is heavily applied rather than academic, with a strong emphasis on real-world credit and lending use cases. If you are preparing for this role, expect questions grounded in lending data, alternative credit scoring, and communicating model outcomes to business stakeholders.

1. Walk me through how you would build a credit risk scorecard for MSME borrowers from scratch.

1. Lendingkart uses alternative data sources such as GST filings and bank statements. How would you extract features from bank statement data to predict loan repayment?

1. How do you handle class imbalance in a loan default prediction model?

1. Explain the difference between precision and recall. Which matters more in a credit risk context, and why?

1. Write a SQL query to identify customers who took more than two loans in the past year and had at least one delayed payment.

1. How would you detect fraudulent loan applications using transactional data?

1. A model you deployed performs well on historical data but poorly on recent data. What would you investigate first?

1. How would you design an A/B test to evaluate a new underwriting policy? What metrics would you track?

1. Explain how gradient boosting works. Why is it commonly preferred over logistic regression for credit scoring at scale?

1. How do you ensure a lending model does not discriminate unfairly against certain borrower segments?

1. Describe a time you had to explain a complex model output to a non-technical business stakeholder.

1. How would you build a lead scoring model to prioritise which loan applicants the sales team should call first?

Q: How would you build a credit risk scorecard for MSME borrowers?

*Situation:* In a previous role at a fintech startup, the credit team relied entirely on bureau scores, which left out a large segment of thin-file MSME applicants.

*Task:* I was asked to build an alternative credit scoring model using internal and alternative data sources.

*Action:* I audited all available data: bank statement transactions, GST returns, and repayment history from prior loans. I engineered features like average monthly revenue volatility, GST filing consistency, and debt service coverage ratios. I trained an XGBoost classifier, tuned decision thresholds separately for different loan ticket sizes, and validated using time-based splits to prevent data leakage.

*Result:* The model meaningfully improved coverage for thin-file applicants while keeping the default rate within limits approved by the credit risk committee. The business expanded into a new borrower segment without a material rise in NPA.

---

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

*Situation:* Loan default datasets are inherently imbalanced because the large majority of borrowers repay on time.

*Task:* I needed a model that could flag high-risk applicants accurately without overwhelming the operations team with false positives.

*Action:* I evaluated three approaches: SMOTE oversampling, adjusting class weights in the model, and tuning the classification threshold post-training. I used precision-recall curves rather than accuracy to select the final threshold, because accuracy is misleading on imbalanced data. I also used stratified cross-validation to ensure each fold had representative default cases.

*Result:* The threshold-tuned model with class weighting gave the best balance for the operations team's review capacity. A champion-challenger test confirmed it caught the majority of actual defaults while reducing unnecessary manual reviews.

---

Q: Describe a time you explained a complex model to a non-technical stakeholder.

*Situation:* After building a fraud detection model, the head of collections was unconvinced about approving its deployment.

*Task:* I had to present the model's logic and business impact without using technical jargon.

*Action:* I used SHAP values to produce a simple 'top reasons this application looks risky' summary card for each flagged case. I showed three real examples from the validation set where the model caught fraud that the old rule system missed. I translated performance into business language by comparing how many fraudulent applications the old system caught versus the new model, using confirmed validation data rather than projections.

*Result:* The stakeholder approved a pilot. The model was deployed on a subset of applications, and the collections team reported the risk flags were actionable and easy to interpret.

For technical ML questions, use a Problem, Data, Model, Evaluation structure: state the problem and what success looks like, describe the data you would use and how you would prepare it, explain your model choice and why, then describe how you would evaluate and monitor it in production.

For SQL and analytical questions, think out loud. State your assumptions, build the query step by step, then sanity-check it with a small mental example. Lendingkart interviews typically reward clear reasoning over perfect syntax.

For business or case questions, lead with the metric that matters to a lender (default rate, approval rate, NPAs, collection efficiency) before diving into technical choices. Interviewers want to see that you connect model decisions to business outcomes, not just model accuracy.

For behavioural questions, use STAR (Situation, Task, Action, Result) but keep the Situation brief. Spend most of your time on Action (what you personally did, not what the team did) and Result (a concrete outcome, even if qualitative).

For fairness and ethics questions, acknowledge the regulatory context in India (RBI guidelines on fair lending practices) and explain how you would audit model outputs across borrower segments before deployment.

Lendingkart interviewers, based on candidate reports, consistently look for a few things beyond technical skills.

Domain fluency in lending. You do not need prior fintech experience, but you should understand concepts like NPA, bureau scores, GST-based underwriting, and the loan lifecycle. Candidates who speak the business language of credit tend to progress further in the process.

Applied, not academic, thinking. Interviewers typically push on what you would actually do with messy, real-world data, not textbook scenarios. Expect follow-up questions like 'what if bureau data is missing for half your applicants?' or 'how would you retrain this model monthly at scale?'

Communication clarity. Data Scientists at Lendingkart work closely with credit, product, and collections teams. Interviewers assess whether you can translate your work into business decisions. Practise explaining model tradeoffs in plain language before the interview.

Ownership mindset. Candidates report that interviewers respond well to answers where you drove an outcome end to end, not just contributed one piece. Use 'I' rather than 'we' when describing your specific contribution.

Week 1: Technical foundations
Revise classification algorithms with a focus on logistic regression, decision trees, and gradient boosting. Practise SQL window functions and aggregation queries on a sample lending dataset available on public data platforms. Review statistics: probability, distributions, hypothesis testing, and common interview pitfalls like the difference between Type I and Type II errors.

Week 2: Domain and applied problems
Read about MSME lending in India, how alternative credit scoring works, and what RBI guidelines say about digital lending. Practise feature engineering on bank statement or transaction data. Work through at least two end-to-end case studies: one credit risk modelling problem and one fraud detection problem.

Week 3: Communication and mock interviews
Prepare five STAR stories from your past work covering: a model you built end to end, a time you handled messy or missing data, a time you influenced a business decision with data, a conflict or challenge you navigated, and a failure and what you learned from it. Do at least two mock interviews with a peer or on a practice platform. Record yourself once to check your clarity and pacing.

Before the interview
Read Lendingkart's recent news (funding rounds, product launches, partnerships). Check their open roles page to understand which teams are hiring. Prepare two or three thoughtful questions for the interviewer about data infrastructure, model deployment practices, and team structure.

If you want to track open Data Scientist roles at Lendingkart and similar companies while you prepare, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so you do not miss a new opening while focused on interview prep.

Using generic examples not connected to lending. Saying 'I built a recommendation system' without connecting the skills to credit or fraud will not resonate at Lendingkart. Before the interview, map your past experience to lending problems.

Jumping to model choice without discussing data. Candidates who immediately say 'I would use XGBoost' without first talking about data collection, cleaning, and feature engineering signal that they skip the hard parts. Always start with data quality and availability.

Optimising for accuracy on imbalanced data. Mentioning accuracy as your primary metric for a default prediction model is a red flag in fintech interviews. Know your precision, recall, AUC-ROC, and KS statistic, and be ready to explain which matters most in a given context.

Not asking clarifying questions in case rounds. Treating a vague case prompt as fully specified and diving straight into a solution is a common mistake. Interviewers typically want to see you ask about business constraints, data availability, and what success looks like before you build anything.

Over-claiming team outcomes as personal. Saying 'our model reduced NPAs' when you only built one feature is easy to unravel in follow-up questions. Be precise and honest about your individual contribution.

No questions for the interviewer. Candidates who ask nothing at the end are often seen as unengaged. Prepare genuine questions about the data stack, model lifecycle, and team priorities.