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

Turno is a Bengaluru-based startup building India's electric commercial vehicle ecosystem, helping businesses switch their cargo fleets to EVs through vehicle financing, fleet management, and charging support. Data Scientists at turno typically work on battery health analytics, demand forecasting for vehicle bookings, fleet operator segmentation, route optimization, and pricing models.

Turno currently has 47 open roles across functions, with Data Scientist positions among the most active. Candidates report the process typically runs across a few stages: a technical screen covering statistics, SQL, or a take-home problem, a case study focused on a real business problem, and one or two discussions with senior data scientists and business leads. The exact structure varies by team and seniority.

Salary bands for Data Scientists across India (knok jobradar, July 2026):

Bangalore leads all cities with 166 active Data Scientist openings as of July 2026, making it the main hiring hub. Turno, as a growth-stage startup, typically pairs cash compensation with meaningful equity.

These questions come from candidate reports and turno's known focus areas in EV fleet analytics. Expect a mix of ML fundamentals, domain-specific problems, and business case reasoning.

1. How would you build a demand forecasting model for electric cargo vehicle bookings in a new city where historical data is sparse?
2. Turno's vehicles generate telemetry data (battery state, GPS, motor temperature). How would you design an anomaly detection pipeline for early fault prediction?
3. Walk through how you would segment turno's fleet operators to identify high-value versus at-risk customers.
4. How would you measure the impact of opening a new battery swap station on delivery completion rates in a zone?
5. Given sparse breakdown labels, what ML approach would you use for predictive maintenance on EV fleets?
6. How would you design an A/B test to evaluate whether a new pricing model increases fleet utilization?
7. Turno operates across Tier-1 and Tier-2 cities with very different usage patterns. How do you handle this distribution shift in your models?
8. A product manager wants to know which features drive customer churn among fleet operators. How would you approach this?
9. Explain how you would build a route optimizer that accounts for battery range constraints and charging stop availability.
10. Your model's accuracy drops a few months after deployment. What steps do you take?
11. How would you handle class imbalance in a fraud detection model for vehicle financing applications?
12. How would you explain model uncertainty to a non-technical stakeholder on turno's operations team?

Use the STAR format (Situation, Task, Action, Result) for behavioral and case questions. Below are three worked examples.

Q: How would you build a demand forecasting model for a new city with limited data?

*Situation:* At my previous role, we launched a new service city with only a few months of order history, while our main model needed at least a year of data to perform reliably.

*Task:* I needed a forecast accurate enough for the operations team to plan vehicle allocation within the first weeks of launch.

*Action:* I used a transfer learning approach, starting with a model trained on our mature cities and fine-tuning it on the new city's short history. I added features like local holiday calendars, competitor activity signals, and demographic proxies from public data. I also set explicit uncertainty bands so the ops team knew where to trust the forecast less.

*Result:* Allocation errors in the new city dropped compared to the naive baseline the team had been using, and the ops lead adopted the forecast for weekly planning within a few weeks of launch.

---

Q: How would you design an A/B test to evaluate a new pricing model?

*Situation:* Our growth team proposed a dynamic pricing model charging fleet operators based on distance and peak hours. Before rolling it out, we needed evidence it would improve revenue without hurting retention.

*Task:* Design a statistically sound experiment the business could act on within a quarter.

*Action:* I defined the primary metric as revenue per active vehicle per week and a guardrail metric as short-term operator retention. I randomized at the operator level (not trip level) to avoid spillover, calculated the required sample size using a power analysis, and set a pre-registered significance threshold. I also built a daily monitoring dashboard so we could call the test early if the guardrail metric moved badly.

*Result:* The test ran for several weeks and showed a statistically significant lift in revenue per vehicle, with no meaningful change in retention. The pricing model shipped to all operators the following sprint.

---

Q: Your model's accuracy drops a few months after deployment. What do you do?

*Situation:* Our churn prediction model started showing a noticeable drop in precision a few months after going live in production.

*Task:* Diagnose the root cause and restore model performance without causing downtime for the customer success team who relied on daily churn scores.

*Action:* I first checked for data pipeline issues: null rates, schema changes, upstream delays. Finding none, I ran a feature drift analysis and discovered that two behavioral features had shifted significantly because of a recent app redesign. I retrained the model on a rolling window that included post-redesign data and added automated drift alerts using population stability index checks.

*Result:* Precision recovered after retraining, and the drift alerts caught a smaller shift the following month before it could impact model quality.

STAR for behavioral questions. Every story needs a concrete Situation, a clear Task you owned, specific Actions you took, and a measurable Result. Avoid vague outcomes like 'it went well.' Tie the result back to a business metric whenever possible.

Hypothesis-first for open-ended problems. When turno asks a case question, state your hypothesis before diving into analysis. For example: 'I suspect battery degradation in hot months is the main driver of unplanned downtime. Here is how I would test that.' This signals structured thinking over random exploration.

MECE decomposition for ambiguous problems. Break the problem into mutually exclusive, collectively exhaustive parts before solving any one piece. For a churn question, you might split customers by tenure, fleet size, and city before deciding which model to build.

Communicate uncertainty explicitly. Turno operates with real hardware and real operators. Interviewers want to see that you distinguish between what your model knows confidently and where it is guessing. Always mention confidence intervals, prediction intervals, or fallback rules when discussing deployed models.

Tie everything to the EV business. Generic ML answers get generic feedback. Connect every technique to turno's context: battery cycles, operator economics, last-mile logistics, or charging infrastructure density.

Candidates report that turno's interviewers evaluate on four main dimensions.

Domain curiosity. Turno is solving hard logistics and energy problems. Interviewers notice whether you have read about EV fleet challenges, battery degradation, or last-mile delivery economics, even at a surface level. You do not need to be an EV expert, but showing genuine interest signals you will ramp up faster.

Practical ML judgment. Turno's data is messy: sparse labels, short city histories, sensor noise from hardware. Interviewers prefer candidates who can navigate imperfect data over those who demand a clean benchmark dataset. Discussing trade-offs, not just accuracy scores, matters here.

Business communication. Data Scientists at turno work closely with operations and product teams. Interviewers often ask you to explain a finding to a non-technical audience. Clear, jargon-free explanations are valued as much as technical depth.

Ownership mindset. This is a startup. Interviewers look for signs that you will monitor your models in production, investigate anomalies without being asked, and care about whether the model actually moves a business metric, not just a leaderboard score.

Week 1: Company and domain research. Read turno's public blog posts and press coverage about their EV fleet model. Understand how fleet operators use turno's platform, what their pain points are (range anxiety, financing, downtime), and where data science could create value. Sketch a rough map of the data turno likely collects across trips, batteries, and operators.

Week 2: Core ML and statistics revision. Revise time series forecasting (ARIMA, Prophet, gradient boosted trees for tabular time series), anomaly detection methods, survival analysis for churn, and experiment design. Practice SQL on a platform like LeetCode or StrataScratch at medium difficulty.

Week 3: Case study practice. Find a public dataset related to logistics, fleet operations, or IoT sensor data and build a small end-to-end project. Practice explaining your approach out loud as if presenting to a product manager. Recording yourself helps you spot filler words and unclear reasoning.

Week 4: Mock interviews and STAR stories. Write out several STAR stories covering: a time you dealt with messy data, a model that failed in production, a cross-functional disagreement, a time you simplified a complex finding, and a project you drove end-to-end. Do a couple of mock interviews with a peer or an online platform before the real thing.

On the day, candidates report that turno interviewers appreciate concise answers. Keep initial responses to a few minutes and let the interviewer probe deeper. If you are actively searching at the same time, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so you can keep your focus on interview prep.

Ignoring the EV context. Giving a generic churn model answer when the question is about fleet operator retention misses what the interviewer is testing. Always frame your answer in turno's world, using signals and metrics relevant to EV fleet operations.

Jumping to complex models too fast. Candidates who immediately propose deep learning for a problem with sparse data often get pushed back. Start with a simple baseline and justify added complexity only when the baseline is clearly insufficient.

Skipping the business metric. Saying 'my model had high accuracy' without connecting it to a business outcome (lower downtime, better fleet utilization, reduced financing defaults) is a common miss at growth-stage startups where every model is expected to move a number.

Being vague about data. Interviewers at turno often probe what data you would actually need. Vague answers like 'I would use historical data' signal inexperience. Name specific signals: trip logs, battery cycle counts, operator payment history, city-level charging density.

Treating uncertainty as weakness. Saying 'I don't know the exact figure but here is how I would estimate it' is stronger than guessing. Interviewers at data-driven startups respect intellectual honesty and structured estimation over confident but unfounded claims.

Not asking clarifying questions. On case questions, jumping in without clarifying the objective, the available data, and the success metric is a red flag. Spend the first few minutes asking questions before solving.