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

Turno is building India's electric commercial vehicle ecosystem, helping small business owners buy and finance electric three-wheelers through a technology-first platform. Their ML team works on applied problems including battery health prediction, credit risk modelling for thin-file borrowers, fleet telematics analytics, and customer-product matching. As of July 2026, Turno had 47 open roles on knok's radar, and there are 803 Machine Learning Engineer openings across India in the same period.

City-wise distribution of ML Engineer openings (knok jobradar, July 2026):

Bangalore leads by a wide margin, but Delhi and Hyderabad also show healthy demand. Turno's interview process typically covers machine learning fundamentals, coding, system design for ML pipelines, and domain-specific problem solving around EVs and fintech. Candidates report the process is structured and moves at a reasonable pace.

These questions are drawn from candidate reports and reflect Turno's focus on EVs, fintech, and real-world data challenges.

1. How would you build a battery health prediction model for electric three-wheelers, and what features would you engineer from sensor data?
2. Turno works with small business owners who often have no formal credit history. How would you approach building a credit scoring model for this segment?
3. Describe how you would design a real-time anomaly detection system for vehicle telematics data.
4. How would you handle class imbalance in a fraud or loan default prediction model?
5. Walk us through how you would set up an MLOps pipeline from data ingestion to model serving in production.
6. How would you approach route or charging optimisation for a fleet of electric vehicles given battery range constraints?
7. If a deployed model's performance degrades over time, how do you detect model drift and address it?
8. How would you use large language models or transformer-based approaches to improve customer support or document processing at a fintech-EV company?
9. Describe a time you worked with noisy, incomplete, or poorly labelled real-world data. How did you clean and use it?
10. How would you explain a complex model's decision to a collections officer or loan relationship manager with no technical background?
11. What trade-offs would you consider when choosing between an interpretable model and a high-performing black-box model for credit decisions?
12. How would you design an experiment to compare two different recommendation algorithms for matching customers to EV financing products?

Q: How would you build a battery health prediction model for electric three-wheelers?

*Situation:* At my previous company, we operated a fleet of electric delivery vehicles and needed to reduce unplanned downtime caused by battery failures.

*Task:* I was responsible for building a predictive model that could flag batteries at risk of failure before they caused operational disruptions.

*Action:* I collaborated with the hardware team to identify which sensor signals mattered most, including voltage curves, temperature patterns, charge cycle counts, and depth-of-discharge history. I cleaned and resampled the time-series data to a consistent frequency, engineered rolling-window and lag features, and trained a gradient boosting classifier with stratified cross-validation. I also set up a feature drift monitoring dashboard to catch distribution shifts as new vehicle data arrived.

*Result:* The model helped the maintenance team prioritise inspections proactively. Reactive repair incidents dropped noticeably over the following quarter, and the feature importance output fed back into a conversation with the hardware team about which sensors to prioritise on future vehicles.

---

Q: How would you build a credit scoring model for small business owners with limited formal credit history?

*Situation:* At a lending-focused startup, a large share of our applicants had no bureau score or only a thin file with minimal history.

*Task:* My task was to build an alternative credit scoring model that could reliably predict repayment behaviour without relying on traditional bureau data alone.

*Action:* I sourced alternative signals including mobile recharge patterns, utility payment regularity, GST filing history, and transaction frequency from partner data integrations. I ran feature importance analysis to shortlist the most predictive variables, then trained and compared a logistic regression model against a gradient boosting model using precision, recall, and Gini coefficient as evaluation metrics. I also built a fairness audit step to check for bias across gender and geography before deployment.

*Result:* The model improved approval rates for thin-file applicants in a champion-challenger test without increasing the observed default rate across the pilot period. The fairness audit flagged one geographic variable we removed before going live.

---

Q: Describe a time you handled model drift in a production system.

*Situation:* I was maintaining a demand forecasting model for an e-commerce platform when a sharp shift in user behaviour caused forecast errors to spike.

*Task:* I needed to detect the drift quickly and retrain the model without causing major disruptions for the inventory planning team that relied on the forecasts daily.

*Action:* I set up statistical monitoring using population stability index scores on incoming feature distributions, with automated alerts and a scheduled retraining job triggered whenever PSI crossed a set threshold. I also introduced a brief human review step for the first few weeks after any retrained model went live, so unexpected outputs could be caught before reaching downstream systems.

*Result:* The system flagged the distribution shift within days of it beginning, and the retrained model recovered to its previous performance level within a week. The human review step caught one instance where a data pipeline bug had introduced corrupted training data before it caused any damage in production.

For behavioural questions, the STAR structure (Situation, Task, Action, Result) is the most reliable framework. Keep the Situation and Task brief, spend most of your time on Action, and make the Result concrete even if you cannot share exact numbers.

For ML system design questions, candidates report that a structured walkthrough covering these stages is well received: problem framing, data sourcing and labelling, feature engineering, model selection and trade-offs, evaluation metrics, deployment architecture, and monitoring and retraining. Practise moving through this flow out loud before your interview.

For technical ML questions, lead with your reasoning before diving into equations or code. Interviewers at applied companies like Turno typically want to see that you connect model choices back to real-world constraints such as interpretability, latency, or data availability, rather than just optimising a benchmark metric.

For domain-specific questions, you do not need to be an EV expert, but showing that you have thought about the unique properties of EV data (battery degradation curves, sparse telematics signals, informal borrower profiles) signals genuine interest and preparation beyond standard interview prep.

Turno sits at the intersection of fintech and electric vehicles, so interviewers typically look for candidates who can apply ML to messy, real-world data rather than clean benchmark datasets. Strong fundamentals in supervised learning, time-series modelling, and model evaluation are expected, combined with practical knowledge of taking models from a notebook to production.

Candidates report that showing domain curiosity makes a real difference. Asking thoughtful questions about EV battery degradation patterns, how informal sector borrowers differ from salaried customers, or how telematics data is collected and stored signals that you are thinking like a product builder, not just an algorithm writer.

Communication is valued as much as technical depth. Being able to explain your model choices to a collections officer, a product manager, or a field sales person in plain language is a skill Turno's team tests explicitly. Practise explaining a complex model using a simple analogy before your interview rounds.

Week 1: Core ML fundamentals. Revise gradient boosting, regularisation, cross-validation, and handling imbalanced datasets. Focus on explaining the intuition behind each concept, not just the formula. Be ready to discuss which evaluation metric fits which business problem.

Week 2: Domain preparation. Study credit risk modelling basics including scorecards and alternative data sources for thin-file lending. Read about EV battery degradation and the kinds of sensor data modern EV fleets collect. Review time-series feature engineering techniques such as rolling windows, lag features, and trend decomposition.

Week 3: System design and MLOps. Practise designing an end-to-end ML pipeline out loud, covering data ingestion, feature stores, model training, evaluation, serving, and monitoring. Build or revisit at least one project that goes from raw data to a deployed endpoint so you can walk through it concretely.

Week 4: Communication and mock interviews. Practise explaining a complex model to a non-technical audience. Record yourself answering STAR questions and review for clarity and conciseness. Do at least a couple of mock interviews with peers or on a practice platform to get comfortable with the format.

While you prepare, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR on your behalf, so you stay active in the market without spending hours on manual applications.

Jumping to complex models without a baseline. Interviewers notice when candidates propose a neural network before establishing whether a logistic regression or gradient boosting model would meet the requirement. Always propose a simple baseline first and explain when you would move to something more complex.

Vague answers about imbalanced data. Saying 'I used SMOTE' or 'I used class weights' without explaining why you chose that approach or what the outcome was reads as surface-level knowledge. Describe the nature of the imbalance, the metric you cared about, and what the technique actually changed in practice.

Ignoring business constraints in credit model questions. Regulatory requirements, interpretability for loan officers, and fairness across demographic groups are as important as AUC at a fintech company. Missing these signals a gap in applied thinking that interviewers are specifically looking for.

Not asking clarifying questions in system design rounds. Candidates report that jumping straight into an answer without scoping the problem (scale, latency requirements, label availability) is a common misstep. Take a minute to ask before you start designing.

Treating the interview as purely technical. Turno is building a product with real users. Showing that you care about the borrower experience, driver safety, or field adoption of a model, not just its accuracy metric, leaves a stronger impression than technical polish alone.