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

Fractal Analytics is one of India's leading AI and analytics firms, serving large global clients across CPG, financial services, healthcare, and retail. As of mid-2026, Fractal has 55 open Data Scientist roles across India, signalling active hiring at multiple experience levels.

The interview process typically spans three to four rounds. Candidates report an initial screening call focused on your resume and basic ML concepts, followed by one or two technical rounds covering statistics, machine learning, and SQL. There is commonly a business case or take-home assignment where you solve a real client-style problem, and a final culture fit discussion. The full process typically takes a few weeks from first call to offer.

Fractal strongly values business acumen alongside technical skill. The firm serves senior stakeholders at large consumer brands and financial institutions, so interviewers look for candidates who can frame a modelling problem in terms of client impact, not just model accuracy.

Salary bands for Data Scientist roles in India align with the following market ranges:

These ranges are drawn from knok jobradar data as of mid-2026.

Fractal interviews test three things: ML fundamentals, SQL fluency, and your ability to connect technical work to business results. Candidates report these questions appearing frequently across rounds.

1. Walk me through a machine learning project you built end-to-end, from problem framing to deployment or handoff.
2. How would you approach building a customer churn prediction model for a large retail client? What data would you need, which algorithms would you consider, and how would you measure success?
3. Your model performs well in testing but its performance drops after going live. What steps do you take to diagnose and fix this?
4. How do you handle class imbalance in a classification problem?
5. Explain the bias-variance tradeoff. Describe a situation from your own work where you had to manage it.
6. What is the difference between L1 and L2 regularisation? When would you prefer one over the other?
7. How would you explain a gradient boosting model to a business stakeholder who has no data science background?
8. Walk me through your feature selection process. How do you decide which variables to include and which to drop?
9. Tell me about a time your analysis directly influenced a business decision. What did you recommend and what happened?
10. How do you ensure that a model you built is not biased against a particular customer segment?
11. Describe how you would design an A/B test to evaluate a new recommendation engine for an e-commerce client.
12. SQL question: Given a table of customer transactions, write a query to find the top customers by total revenue in the last quarter, excluding refunded orders.

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

*Situation:* My team was tasked with reducing customer attrition for an e-commerce client. The business had no systematic way to identify at-risk customers before they churned.

*Task:* I was responsible for building a churn prediction model the CRM team could act on every week without needing help from data science.

*Action:* I started by mapping out available data, including purchase history, session logs, and support ticket records. I worked with the business team to agree on the definition of 'churned' before writing any code. I then built a gradient boosting model, used SHAP values to surface the top drivers, and packaged the weekly output into a dashboard the CRM team could filter on their own.

*Result:* The team ran a pilot campaign targeting the highest-risk segment. The client reported a measurable reduction in attrition within two quarters and extended the engagement. I also documented the pipeline so a junior analyst could maintain it going forward.

---

Q: Tell me about a time your analysis changed a business decision.

*Situation:* A product manager at our client, a large FMCG brand, was convinced that increasing promotional spend in metro cities would lift total revenue.

*Task:* I was asked to validate this hypothesis using two years of sales and promotion data.

*Action:* I ran a regression analysis controlling for seasonality and city-level factors. The data showed that promotional lift in metro cities was already saturated, while Tier 2 cities showed a much stronger response. I built a one-page summary comparing projected revenue under both scenarios and presented it directly to the client stakeholder.

*Result:* The client shifted a portion of the promotional budget to Tier 2 cities for the next quarter. Post-campaign results, as publicly reported by the client's business unit, showed revenue growth outpacing the prior metro-only campaign.

---

Q: Your model degrades after going live. What do you do?

*Situation:* I had deployed a pricing model for a financial services client. About three months after launch, the model's recommendation accuracy started drifting downward.

*Task:* I needed to find the root cause quickly because the model was feeding into live pricing decisions.

*Action:* I first checked whether the input data pipeline had changed. I then compared the distribution of key features between the training data and recent live data using statistical tests and distribution plots. The issue was data drift: a new product category had been added post-training that the model had never seen. I retrained the model on a refreshed dataset and set up automated drift alerts going forward.

*Result:* Performance recovered to near-original levels within two weeks. The drift monitoring we added became a standard part of how that team managed all their deployed models.

For technical ML questions, structure your answer in three parts: what the concept is, why it matters in practice, and a brief example from your own work. Interviewers at Fractal are not just checking textbook definitions. They want to see that you have applied the concept in a real setting.

For case or business problem questions, use a structured problem-solving approach. Start by clarifying the business objective before jumping to algorithms. State what data you would need. Walk through your modelling choices and explain the tradeoffs. End with how you would measure success and how you would present results to a non-technical audience. Fractal works with senior client stakeholders, so showing you can communicate clearly is as important as getting the model right.

For behavioural questions, use the STAR format: Situation, Task, Action, Result. Keep the Situation and Task brief. Spend most of your time on the Action, specifically what you did rather than what 'we' did as a team. Always close with a concrete Result. If the result involved a business metric, describe it clearly even if you cannot share a precise number.

For SQL questions, think aloud. State your approach before writing the query. Mention edge cases like nulls, duplicates, or date filtering. Fractal SQL questions typically involve aggregations, window functions, and filtering on time ranges, so practise those patterns specifically.

Business-first thinking. Fractal sells outcomes to large clients, not models. Interviewers consistently look for candidates who start with the business problem before choosing an algorithm. If you jump straight to 'I would use XGBoost,' you risk losing points even if the technical answer is correct.

Strong ML fundamentals. Expect questions on regularisation, model evaluation, feature engineering, and handling messy real-world data. You should be able to explain the intuition behind an algorithm, not just import it from a library.

Communication and storytelling. Fractal Data Scientists present findings to clients who are not data literate. Interviewers probe whether you can translate technical results into plain business language. Practise explaining your projects as if the listener is a smart business manager, not a fellow data scientist.

SQL fluency. Many roles at Fractal involve pulling and transforming data directly. SQL questions in interviews are common and can be moderately complex. Being slow or uncertain on SQL is a frequently cited reason candidates do not clear the technical round.

Ownership and follow-through. Fractal interviews often ask about times things went wrong or models failed in production. They want to see that you diagnose problems, take responsibility, and fix them rather than pass them on.

Week 1: Build your story bank. Identify five to six projects from your experience and write a STAR summary for each. Cover at least one project where things went wrong and one where you influenced a business decision. Make sure you can describe each project in under two minutes without notes.

Week 2: Sharpen ML fundamentals. Review the concepts that appear most often in Fractal interviews: regularisation, gradient boosting, class imbalance handling, model validation, feature selection, and data drift. For each topic, write a short plain-English explanation as if you are briefing a client, not a colleague.

Week 3: SQL and case practice. Spend time on window functions, CTEs, and time-based aggregations. Practise a few SQL problems each day. In parallel, practise one business case per day: pick a domain (retail, FMCG, fintech), pick a problem, and walk yourself through how you would frame, model, and present a solution.

Week 4: Mock interviews and refinement. Do at least two full mock interviews where someone asks you questions and you answer out loud. Pay attention to filler words and how long you take to reach the point. Review any concepts where you stumbled and close those gaps before the actual rounds.

Jumping to algorithms before understanding the problem. Opening a case answer with 'I would use a random forest' signals that you prioritise tools over thinking. Always clarify the business objective and data availability first.

Vague STAR answers. Responses like 'we improved model performance' or 'the team was happy' do not land well. Be specific about what you personally did, and describe the result in terms of business impact even when you cannot share precise figures.

Ignoring the business case for your technical choices. If you chose a simpler model because it was easier to explain to the client, say that explicitly. Fractal values that reasoning. Candidates who justify choices only on accuracy metrics miss a big part of what the firm looks for.

Being underprepared on SQL. Many candidates focus entirely on ML and are caught off guard by SQL questions. Treat SQL as a required skill, not a bonus.

Not asking clarifying questions during case rounds. Diving into a solution without asking about constraints, available data, or what success looks like suggests you would do the same with real clients. Interviewers typically expect and reward thoughtful clarifying questions at the start of a case.