How much statistics will they ask about?

Usually enough to check hypothesis testing, confidence intervals, power and common pitfalls. Explain the idea in words before any formula.

Should I think out loud in case questions?

Yes. Say your assumptions and structure as you go so the interviewer can redirect you. Silence for a minute, then an answer, is harder to score.

What if I don't know the company's product well?

Ask two clarifying questions about the goal and the users, state your assumptions, and continue. That's what they'd want on the job too.

How do I talk about a model that underperformed?

Say what you expected, what happened, how you found out and what you changed. Interviewers want to see you measure honestly.

How long should a behavioral answer be?

About 90 seconds to two minutes, with the business result included. Leave technical depth for their follow-up.

Data scientist interview questions and how to answer them

The spoken rounds matter more than people think

Data science loops usually include coding or SQL, statistics, and one or more spoken rounds: product sense, a case, and a behavioral interview. The spoken rounds are where many strong technical candidates lose, because they jump into methods before agreeing what the question is. The habits from a case interview help: clarify, structure, commit.

Explaining a model to non-experts

"Explain a model you built to someone with no technical background." The interviewer is playing your future stakeholder. Start with the decision the model supports, not the algorithm.

Example answer (details are illustrative):

"We wanted the support team to call customers before they cancelled. I built a model that gives every customer a score each week for how likely they are to leave in the next month. It learns from customers who left before: things like logging in less, more support tickets, and a recent price increase. The team got a list of the top 200 each Monday. It's not a crystal ball. About a third of the people on the list really were about to leave, which was far better than calling at random, and that was good enough to save the team's time."

The explanation never says "gradient boosting." If they want the method, they'll ask. The guide to explaining things simply covers the technique.

A project that failed

Choose a failure where the lesson is about judgment, not a bug.

Example answer:

"I spent two months on a demand forecasting model for our warehouses that beat the old method on paper. It never got used. I'd built it with the analytics team, but the planners who'd use it didn't trust a number they couldn't explain, and it arrived as a file, not in the tool they worked in. What I do now is sit with the end users in week one, ship a simple version into their workflow early, and only add complexity once they're using it."

Choosing metrics

"How would you measure the success of a new recommendations feature?" Structure out loud:

Goal. What's the feature for? More purchases, more discovery, more time well spent?
Primary metric. One number that moves if the goal is met, such as purchases per active user from recommendations.
Guardrails. What must not get worse: overall revenue, returns, page load time.
Counter-metric. How it could look good while being bad, such as clicks rising because people can't find what they searched for.
Decision. "If the primary metric rises and guardrails hold, ship."

Commit to a choice. Listing ten metrics without picking one sounds like avoiding the question.

Experiment design

"Design an A/B test for a new checkout page."

Part	What to say
Hypothesis	"A single-page checkout will increase completed orders."
Unit	Randomize by user, not by session, so people see one version
Primary metric	Checkout completion rate
Guardrails	Average order value, payment errors, refunds
Sample and duration	Size it for the smallest lift worth shipping; run full weeks
Pitfalls	Peeking early, novelty effects, other launches overlapping
Decision rule	Agreed before launch

If they ask what you'd do with a non-significant result, don't call it a failure. Say what the confidence interval rules out, whether the test had enough power, and whether a segment result is worth a follow-up test rather than a ship decision.

Mistakes to avoid

Naming algorithms before restating the problem.
Answering a product question with "it depends" and stopping there.
Telling a failure story where the cause was someone else.
Giving accuracy as the only metric for an imbalanced problem.

How to prepare

Prepare two project stories: one that shipped and changed a decision, one that didn't. Know the business result for each.
Practice explaining each to a non-technical friend in under two minutes.
Do three metric cases out loud with a timer, committing to one primary metric each time.
Rehearse with someone who pushes back on your metric. Speaking Coach's interviewer follows up on what you actually said, and you can add your CV so it asks about your real projects.