Aditya Birla Group Data Scientist Interview: Questions, Experience & Prep (2026)

Aditya Birla Group (ABG) is one of India's largest conglomerates, active across telecom, fashion, financial services, cement, and manufacturing. Their data science teams sit within individual business units, so the interview experience can differ between Aditya Birla Capital and UltraTech Cement. What stays consistent is a focus on applied ML, business problem-solving, and clear communication of results.

As of July 2026, knok's job radar tracked 325 open Data Scientist roles at ABG, making it one of the largest single-employer pools among the 937 total Data Scientist openings across India at that time. Most openings are in Bangalore (166 roles across all employers), Delhi (46), Hyderabad (27), Pune (18), and Mumbai (17).

Candidates typically go through two to four rounds: a screening call, a technical round covering statistics and ML, a case study or take-home, and a final round with a hiring manager or business leader. The process commonly takes a few weeks end to end.

These are knok jobradar figures as of July 2026 and reflect overall market data, not ABG-specific offers.

Based on candidate reports and ABG's publicly listed job descriptions, these questions come up frequently across divisions.

1. 'How would you build a churn prediction model for a financial services product like Aditya Birla Capital? Walk us through your full pipeline.'

1. 'Explain precision and recall in plain terms. In a loan default or fraud scenario, which one matters more and why?'

1. 'ABG has dozens of business units each with its own data systems. How would you think about creating a shared customer analytics layer across them?'

1. 'How would you design an A/B test for a new feature on a consumer app, like a health insurance recommendation tool? What metrics would you track?'

1. 'Your dataset for a fraud detection model has severe class imbalance where genuine fraud cases are a small minority. How do you handle this?'

1. 'Tell me about a time your model recommendation was rejected by a business team. What happened and what did you do differently after?'

1. 'What is the difference between L1 and L2 regularization? Give a scenario where you would pick each one.'

1. 'How would you measure the business impact of a recommendation engine on a fashion retail platform such as Madura or Louis Philippe?'

1. 'SQL: Write a query to identify customers who bought in the first quarter but not in the second, ranked by their spend in the first quarter.'

1. 'You deploy a model and after several months performance drops significantly. Walk me through how you would diagnose the root cause.'

1. 'How would you approach sentiment analysis or topic modelling on customer feedback arriving in multiple Indian languages?'

1. 'What does your model deployment and monitoring setup look like in a current or past role? How do you catch drift early?'

Q: Tell me about a time your model recommendation was rejected by a business team.

*Situation:* I built a propensity model to identify customers likely to upgrade their insurance plan at a previous employer in financial services.

*Task:* My job was to present the model output to the marketing team and get them to use the shortlist for their outreach campaign.

*Action:* I presented the model in technical terms, showing AUC scores and lift curves. The marketing lead pushed back because they did not trust a black-box score and were worried about contacting the wrong customers. I went back, rebuilt the explanation using plain examples, showed which factors drove each customer's score, and held a walkthrough session with the business team.

*Result:* The team adopted the model for a pilot campaign, and their conversion on the pilot exceeded what their previous rule-based shortlist had achieved, per their own internal comparison. I learned that model adoption depends as much on communication as on model quality.

---

Q: Your fraud dataset has severe class imbalance. How do you handle it?

*Situation:* At a fintech company, I worked on a transaction fraud model where genuine fraud cases made up a very small share of all transactions.

*Task:* I needed a model that would catch actual fraud without flagging too many legitimate transactions and creating friction for customers.

*Action:* Training on the raw imbalanced data produced a model that predicted 'not fraud' for nearly everything yet still showed a high overall accuracy, which was misleading. I applied SMOTE to oversample the minority class, tuned the decision threshold rather than using the default, and switched my primary evaluation metric to precision-recall AUC and F1 score instead of plain accuracy.

*Result:* The revised model caught a significantly larger share of actual fraud cases while keeping false positives at a level the fraud operations team could manage. They confirmed this by reviewing flagged transactions manually, and the approach reduced financial losses in the following quarter.

---

Q: How would you design an A/B test for a new recommendation feature?

*Situation:* A retail business unit wanted to test a new 'you may also like' recommendation widget on their e-commerce site.

*Task:* I was asked to design the experiment so the team could make a confident go or no-go decision.

*Action:* I defined the primary metric as revenue per user session, set a minimum detectable effect based on what would justify the engineering cost, calculated the required sample size for statistical significance, randomly assigned users to control and treatment groups at the user level rather than the session level to avoid contamination, and set a fixed experiment duration to prevent peeking bias.

*Result:* The experiment ran cleanly, the team got a statistically significant result, and the recommendation engine was rolled out. The structured approach was also adopted as the team's standard A/B testing template going forward.

For ML and modelling questions, walk through the full pipeline: problem framing, data sourcing and cleaning, feature engineering, model selection and training, evaluation, deployment, and monitoring. ABG interviewers typically want to hear all of these stages, not just the model training step.

For statistics and metrics questions, define the term first in plain language, then give a business example grounded in ABG's actual sectors: financial services, insurance, retail, or telecom. When explaining precision and recall, anchor the trade-off in the cost of each error type for that specific business. A fraud model at a lending company prioritises catching all genuine fraud (high recall) even if some legitimate transactions get flagged. A customer upgrade campaign may prioritise precision so the sales team focuses only on the most promising leads, not the full pool of flagged customers.

For business case and impact questions, use this structure: metric chosen, baseline established, experiment or rollout designed, result measured, business decision made. Tie every model you describe back to a business outcome in INR terms or a directional change in a key metric, drawing on your own experience.

For system and deployment questions, cover where the model runs (batch vs real-time), how predictions reach the end user or system, what monitoring is in place, and how you detect and respond to model drift. ABG's scale across business units means interviewers value candidates who have operationalised models, not just built them.

For SQL and coding questions, think out loud. State what the query needs to do before writing it. Common patterns in ABG interviews include window functions, CTEs, and aggregation across time periods. Write clean, readable SQL and prefer CTEs over deeply nested subqueries.

Business context first. ABG hires data scientists to solve real problems across retail, financial services, and manufacturing. Interviewers want to see that you understand why a model matters to the business, not just how it works. Ground every answer in a business outcome.

Communication across levels. You will present to analysts, product managers, and senior business leaders. Candidates who can explain a complex model to a non-technical stakeholder in plain terms move forward faster. Practice translating technical concepts into outcomes a business leader would care about.

Depth on the full pipeline. ABG teams want people who can take a problem from raw data to a deployed, monitored model. Shallow knowledge of only one stage, knowing model training but not feature engineering or monitoring, is a common rejection point.

Ownership and initiative. The STAR answers that land best describe situations where the candidate personally drove the work. Use 'I did' rather than 'we did' when describing your specific contribution, while still acknowledging the team where appropriate.

Comfort with ambiguity. In a large conglomerate, problems are often poorly defined and data is spread across many systems. Interviewers probe how you scope a vague problem and what clarifying questions you ask before proposing a solution.

Week 1: Technical foundations

Revisit the core statistics topics ABG questions cover: hypothesis testing, confidence intervals, the bias-variance trade-off, and regularisation. For ML, make sure you can explain gradient boosting, logistic regression, and random forests from first principles and articulate when you would choose each. Practice explaining precision and recall using business examples from ABG's actual sectors, grounding the trade-off in the cost of each error type for that domain rather than relying on abstract numerical illustrations.

Week 2: SQL and coding

Work through intermediate SQL problems covering window functions, CTEs, and multi-table joins. The SQL questions candidates commonly report involve ranking or comparing customer behaviour across time periods, so practise those patterns specifically. For Python, make sure you are fluent in pandas and scikit-learn and can write clean, readable code under time pressure.

Week 3: Case study prep

Pick two or three problem types from ABG's actual business: a lending default model, a retail churn model, a recommendation engine for fashion, or a fraud detection system for a payments product. For each, write out your full approach from problem framing to evaluation metric choice and be ready to defend every decision you made.

Week 4: Behavioural and communication

Prepare four to six STAR stories from your own experience covering: a model you built end to end, a time stakeholders pushed back on your work, a time you dealt with poor data quality, and a time you improved a business outcome with data. Record yourself answering out loud so you can hear whether the explanation is clear to a non-technical listener.

Knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR directly on your behalf, so active ABG openings reach you without manual searching.

Stopping at the model. Many candidates describe building a model but never mention deployment, monitoring, or what happened when performance changed over time. ABG interviewers at mid and senior levels probe this hard.

Using accuracy as the only metric. For imbalanced datasets common in fraud, defaults, and churn, accuracy alone is misleading. Saying 'my model achieved high accuracy' without discussing the class distribution and your choice of evaluation metric invites pointed follow-up questions.

Generic business context. Saying 'this would be useful in many industries' instead of grounding your answer in ABG's actual sectors signals a lack of specific preparation. Name the business unit and the problem type you have in mind.

Skipping clarifying questions on case studies. Jumping straight to a solution without asking about business constraints, available data, success metrics, or timelines is a red flag. ABG interviewers want to see how you scope an ambiguous problem before you start solving it.

Overclaiming on team work. Saying 'we built' when asked what you personally did is a common deflection. Be specific about your own contribution even when the project was collaborative.

Not knowing your own resume numbers. If your resume mentions a model that improved conversion or reduced churn, be ready to explain exactly how you measured it, what the baseline was, and what changed. Vague references to 'significant improvement' do not hold up under follow-up questioning.