navi Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

Navi is a Bangalore-based fintech company that offers personal loans, health insurance, and mutual funds. With 60 open roles on knok jobradar as of mid-2026, Navi is actively hiring across engineering functions, and Machine Learning Engineering sits at the core of how Navi builds credit scoring, fraud detection, and product personalisation. Across India, knok tracks 803 ML Engineer openings, with Bangalore leading at 165 roles, so competition for strong ML talent is high and companies like Navi invest seriously in their hiring bar.

Candidates typically go through an online assessment followed by two or three technical rounds and a final discussion, though the exact structure varies by team and level. The ML team at Navi works on large-scale financial data, so you are likely to face questions on tabular data modelling, model explainability for compliance, real-time serving, and monitoring for data drift. Preparation that ties ML fundamentals to fintech use cases will serve you well.

These questions are compiled from publicly shared interview experiences and the nature of Navi's products. They reflect what candidates report encountering in ML Engineer interviews.

1. Walk us through a credit scoring or risk model you have built end to end, from raw data to deployment.
2. How would you handle severe class imbalance in a fraud detection dataset?
3. Explain how gradient boosting works and when you would choose it over a neural network for a tabular financial dataset.
4. How would you design a real-time feature store for a lending platform serving a large user base?
5. A model you deployed is degrading in production. What do you investigate first, and how do you recover?
6. How would you monitor a credit risk model for data drift and concept drift after deployment?
7. Walk us through how you would evaluate a ranking model for a personal loan product feed.
8. How do you ensure fairness and avoid bias in a lending or insurance model? What checks would you build into the pipeline?
9. Navi serves millions of customers. How would you scale a personalisation model from prototype to low-latency production serving?
10. Describe a time you had to explain a model's predictions to a non-technical stakeholder such as a product manager or compliance officer.
11. What regularisation techniques have you used, and how do you decide which one to apply in a given situation?
12. How would you approach building a next-best-action model for cross-selling a loan product to existing insurance customers?

Q: How would you handle severe class imbalance in a fraud detection dataset?

*Situation:* At my previous company, we were building a transaction fraud detection model. The fraud class made up a very small fraction of all transactions, and our initial model predicted 'not fraud' for almost every case because that was the easy path to high accuracy.

*Task:* My task was to improve recall for the fraud class without hurting precision so badly that we flagged too many legitimate transactions and frustrated customers.

*Action:* I explored several approaches in parallel. I applied SMOTE to oversample the minority class in the training set and also tried undersampling the majority class. I switched my primary evaluation metric from accuracy to AUC-PR and F1 score, which gave a much clearer picture of real performance. I also tuned the classification threshold and used class-weight parameters in XGBoost to penalise missed fraud cases more heavily. I ran cross-validation on each variant and compared results carefully.

*Result:* The class-weighted XGBoost model with threshold tuning gave the best AUC-PR on the held-out set. The team adopted it as the production baseline, and post-deployment monitoring showed it caught a meaningfully higher share of fraud cases compared to the previous rule-based system.

---

Q: You trained a model that performed well offline but degraded after deployment. What would you investigate first?

*Situation:* At a previous role, a loan approval model showed strong offline metrics but started producing worse results a few weeks after going live.

*Task:* I was asked to diagnose and fix the performance drop quickly, since it was affecting approval decisions in production.

*Action:* I started by checking for feature distribution shifts between training data and live traffic using the population stability index. I then plotted the prediction score distribution over time to look for concept drift. I also audited the feature pipeline in detail to find any mismatch between how features were computed at training time versus inference time. This audit revealed that one categorical feature was being encoded differently in the serving layer than it was during training, because a preprocessing step had not been included in the serving pipeline.

*Result:* Fixing the encoding mismatch restored the model to its expected offline performance. I also worked with the team to set up automated drift alerts so we would catch similar issues earlier in future.

---

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

*Situation:* I had built a gradient boosting model to predict the likelihood of a customer defaulting on a personal loan. The compliance team needed to understand why certain applicants were being declined before they would approve the model for production use.

*Task:* I needed to present the model's logic clearly to people without an ML background and satisfy the regulatory requirement for explainability.

*Action:* I used SHAP values to identify the top factors driving each individual prediction. I created simple visualisations showing which features pushed a score up or down for a given applicant. I then wrote a one-page plain-language summary that replaced technical terms with business ones, for example 'past repayment behaviour' instead of 'high SHAP contribution from feature X'. I also prepared a few anonymised case examples to walk through with the compliance team.

*Result:* The compliance team approved the model for production use. The business team found the explanations useful for designing better loan products, and we reused the same explainability format for every model review going forward.

For ML concept questions: Define the concept clearly, explain when you would use it versus alternatives, discuss trade-offs around speed, accuracy, and interpretability, and tie your answer to a fintech or high-stakes use case. Interviewers want to see that you can connect theory to practice.

For system design questions: Start by clarifying requirements: expected scale, latency budget, data freshness needs, and whether the model serves online or batch. Then sketch the data pipeline, describe model serving, and cover monitoring and fallback behaviour. Navi operates at scale, so showing you think about production from the start matters.

For coding questions: Think out loud. Explain what you are doing as you write. Choose readable, correct code over clever one-liners. If you use a library function, briefly explain what it does so the interviewer knows you understand it.

For behavioural questions: Use the STAR structure: Situation (brief context), Task (your specific responsibility), Action (what you personally did, in detail), Result (the outcome). Keep the situation and task short, and spend most of your time on your specific actions and a concrete result.

For case or product questions: Clarify the business goal first. Then propose metrics, data sources, and a simple baseline model before moving to more complex approaches. This shows structured thinking and avoids jumping to a solution before understanding the problem.

Candidates report that Navi's ML interviewers look for engineers who can own the full model lifecycle: not just train a model in a notebook but also deploy it, monitor it, debug it in production, and improve it over time.

Strong ML fundamentals. You should be able to explain concepts like the bias-variance trade-off, regularisation, and ensemble methods clearly and connect them to real decisions you have made.

Hands-on coding skills. Python is the standard. Experience with scikit-learn, XGBoost, LightGBM, or PyTorch is commonly expected. Be ready to write clean data manipulation and modelling code under interview conditions.

Domain awareness around financial data. Questions on credit scoring, fraud detection, and risk modelling come up frequently. Even if your background is in a different domain, showing you understand why explainability and fairness matter in lending goes a long way.

System thinking. The ability to talk about how a model would work at scale, including feature engineering pipelines, serving infrastructure, latency constraints, and monitoring, signals seniority.

Communication. Navi's ML engineers work closely with product managers and compliance teams. The ability to translate ML decisions into plain business language is valued, not just a checkbox on the scorecard.

Week 1: ML fundamentals. Revise decision trees, gradient boosting, neural networks, regularisation, and evaluation metrics. Practice explaining each concept out loud as if to an interviewer. Focus especially on when to use tree-based models versus deep learning for tabular data.

Week 2: Applied ML for financial data. Study class imbalance techniques such as SMOTE, class weights, and threshold tuning. Review feature engineering approaches for tabular financial data and model explainability tools like SHAP. Read about credit scoring and fraud detection approaches used in Indian fintech.

Week 3: System design and coding. Practice designing ML pipelines from data ingestion to model serving. Study how feature stores work and why they matter for low-latency inference. Do coding exercises on data manipulation, model training, and evaluation. Review how to set up model monitoring for drift.

Week 4: Mock interviews and Navi-specific prep. Practice STAR answers for the behavioural questions listed above. Read about Navi's products (personal loans, health insurance, mutual funds) so you can frame your answers in their business context. Run at least two full mock interviews with a peer or out loud on your own.

Knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so while you prep, your applications can keep moving in the background.

Defaulting to neural networks for every problem. Interviewers at fintech companies often prefer tree-based models for tabular data and will expect you to justify your model choice. If you always say 'I would use a neural network,' be ready for probing follow-up questions.

Ignoring the production side. Candidates who can discuss model training but struggle with deployment, monitoring, or retraining tend to hit a wall in system design rounds. Prepare to talk about the full lifecycle.

Using accuracy as the only metric. For imbalanced datasets like fraud or default prediction, accuracy is misleading. Always mention precision, recall, AUC-PR, or F1, and explain why they matter for the specific use case.

Vague STAR answers. Saying 'we improved the model' is not enough. Describe exactly what you did and what the outcome was. If you cannot share exact metrics, frame it as 'our offline evaluation showed a meaningful lift' or describe the qualitative business impact.

Skipping clarifying questions in design problems. Jumping straight into a solution without asking about scale, latency requirements, or business goals is a common red flag. Spend the first few minutes aligning on the problem before proposing a solution.

Overlooking fairness and compliance. Navi operates in a regulated lending and insurance market. Not mentioning bias checks or explainability requirements when discussing lending models can signal a gap in your production ML thinking.