Oolka Data Scientist Interview: Questions & Prep (2026)

Oolka currently has 12 open Data Scientist roles as per knok jobradar (July 2026), making it one of the more active hirers in this space right now. Candidates report the process typically runs 3-4 rounds, covering statistics, machine learning, SQL, and a product case study or take-home assignment. The interviews test both technical depth and your ability to turn data findings into clear business decisions.

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

With 937 Data Scientist roles active across India right now, competition is real but so is opportunity. Bangalore leads with 166 openings, followed by Delhi (46) and Hyderabad (27).

These questions reflect what candidates report seeing in Data Scientist interviews at product and analytics companies, including patterns typical for roles like those at Oolka.

1. Walk us through a machine learning project you built end-to-end, from data collection to deployment.
2. How do you handle a highly imbalanced dataset in a classification problem?
3. Explain the difference between bagging and boosting. When would you choose one over the other?
4. Write a SQL query to find the top 5 users by total revenue in each city, broken down by month.
5. A key product metric drops suddenly. How do you diagnose what went wrong?
6. How do you decide which features to include in a model and which to drop?
7. Explain precision and recall. For a fraud detection system, which one matters more and why?
8. How would you design an A/B test for a new recommendation feature? What are the main risks?
9. Tell us about a time you disagreed with a stakeholder over how to interpret data.
10. How would you build a customer churn prediction model from scratch for a subscription product?
11. What is multicollinearity? How do you detect it and what do you do about it?
12. Describe a situation where your model performed well in offline testing but failed in production. How did you resolve it?

Q: Walk us through a machine learning project you built end-to-end.

*Situation:* My previous company was losing customers at a concerning rate, but leadership had no early warning signal to act on.

*Task:* I was asked to build a system that could flag at-risk customers at least a month before their renewal date.

*Action:* I pulled several months of user behaviour data and engineered features around login frequency, feature adoption, and support ticket volume. I trained a gradient boosting classifier, validated it on a holdout set, and worked with the engineering team to deploy it as a weekly scoring job.

*Result:* The customer success team used the scores to prioritise outreach, and retention improved noticeably over the following quarters. I also documented the model card so future teammates could maintain or retrain it without starting from scratch.

---

Q: Tell us about a time you disagreed with a stakeholder over how to interpret data.

*Situation:* A product manager wanted to declare a new onboarding flow a success because sign-up conversions rose after launch.

*Task:* I suspected a concurrent marketing campaign was inflating the numbers, and I needed to make that case carefully without dismissing the PM's work.

*Action:* I segmented users by acquisition source and showed that conversions rose only in the paid channel, while organic conversions were flat. I presented both views side by side and walked the PM through the confounding variable rather than simply disagreeing.

*Result:* The team agreed to run a proper A/B test before scaling the new flow. That test confirmed a modest but real lift in organic conversions, which gave everyone far more confidence in the final decision.

---

Q: Describe a situation where your model failed in production after passing offline tests.

*Situation:* A recommendation model I shipped looked strong in offline evaluation, but click-through rates in production were consistently below the baseline.

*Task:* I had to diagnose the gap quickly, as the product team was tracking the rollout closely and pressure was building.

*Action:* I compared the training data distribution with live traffic and found a feature that behaved differently in production because of a subtle difference in how the pipeline computed it. I fixed the pipeline, retrained with a live-data sample blended in, and added a monitoring check for feature drift.

*Result:* Performance recovered within a week of the fix. The monitoring check has since caught two other drift events before they could affect users.

For technical ML questions, lead with the concept, then give a concrete example from your own work. Interviewers want to see that you can both explain and apply. Avoid listing every algorithm you know: pick the two or three most relevant ones and go deep.

For SQL and statistics questions, think out loud. Write your approach in plain language before writing any code. This shows structured thinking even if your syntax is slightly off under pressure.

For product and case questions, use a three-part structure: clarify the goal and constraints, walk through your analysis approach, then state what decision you would recommend and what you would monitor afterward. Candidates who skip the 'so what' step typically score lower, even if the analysis itself is strong.

For behavioural questions, use STAR (Situation, Task, Action, Result). Keep Situation and Task brief, spend most of your time on Action (what you specifically did, not what the team did), and close with a concrete Result. If the outcome was negative, explain what you learned and what you changed.

For disagreement or conflict questions, show that you resolved the issue with data and logic, not personality. Interviewers at data companies typically want to see intellectual honesty: if the other person turned out to be right, say so plainly.

Technical rigour without jargon. You should be able to explain a complex model to a non-technical colleague in plain terms. Interviewers typically probe whether you understand *why* an algorithm works, not just *that* it works.

Business sense. Data Scientists at product companies are expected to connect their work to outcomes: revenue, retention, engagement. Candidates who speak only in model metrics without tying them to business impact are commonly passed over at this stage.

Ownership. Interviewers want to see that you followed a project through to production and monitored it afterward, not just handed it off after a notebook presentation.

Communication and collaboration. Most behavioural questions probe how you work with product managers, engineers, and business stakeholders. Show that you can push back on a vague brief, explain your assumptions clearly, and adapt your style to the audience.

Intellectual honesty. If you do not know something, say so and explain how you would find out. Making up an answer is a much faster path to rejection than admitting a gap.

Week 1: Foundations
Revise the statistics and probability topics that come up most often: Bayes' theorem, common distributions, hypothesis testing, and confidence intervals. Practise explaining them out loud, not just solving problems on paper. Verbal fluency on fundamentals signals real understanding.

Week 2: Machine learning depth
Pick four or five algorithms you have actually used and be ready to explain their assumptions, failure modes, and key hyperparameters. Do not try to cover everything. Depth on a few beats shallow coverage of many.

Week 3: SQL and Python
Solve SQL problems at medium difficulty on any practice platform. Write Python code for data cleaning, feature engineering, and model training without looking things up, to simulate real interview conditions.

Week 4: Case studies and storytelling
Practise the 'metric drop' case out loud. Time yourself and record yourself if possible. Prepare three strong STAR stories: one where you shipped something successful, one where something failed and you recovered, and one where you influenced a business decision through data.

One week before the interview, research Oolka's product and any data or engineering content they have published publicly. Tailor at least one example in your answers to their domain so your responses feel relevant, not generic.

1. Overloading answers with theory. Candidates who list every model they know without connecting it to real project experience come across as textbook-trained, not job-ready.

1. Ignoring the business context. Saying 'I improved the model metric' without explaining what that meant for the product is a missed opportunity every time. Always close with impact.

1. Not clarifying ambiguous questions. If a case question is vague, ask one clarifying question before diving in. Interviewers typically view this as a positive signal, not a weakness.

1. Writing SQL without planning. Jumping straight to code often produces slower, messier queries. State your logic in one sentence first, then write.

1. Underestimating the behavioural rounds. Many candidates prepare only for technical questions and get caught off guard on 'tell me about a conflict' or 'describe a failure.' These rounds carry real weight in the final decision.

1. Not asking questions at the end. Candidates who ask nothing signal low curiosity or low interest. Prepare two or three genuine questions about the team's data stack, the problems they are currently working on, or how success is measured in the role.