Data science and machine learning interview questions

How a data science interview loop is put together

The screen is short and mostly logistics, plus one question about a project you will be asked about again later. The coding round is usually Python or SQL against small inputs, often with an interviewer watching you type. The statistics round is spoken: definitions, a probability puzzle, an experiment design question. The depth round digs into something you built, and it is the hardest to fake. The applied case asks you to design a model, a metric or an A/B test for a business problem the team actually has.

The US Bureau of Labor Statistics summarizes the job as using analytical tools and techniques to extract meaningful insights from data, with duties such as deciding which data are available and useful for a project and creating, validating, testing and updating algorithms and models. Those two halves, data judgement and model craft, are what the loop is sampling.

It helps to know who is asking. A research-leaning team will press on statistics and on why your model works. A product-leaning team will press on measurement and trade-offs. An ML engineering team will press on what happens after the notebook: how the features are computed at serving time, what happens when a feature goes missing, how you would notice the model degrading. Ask the recruiter which of the three the role sits closest to, then weight your preparation accordingly.

Statistics and probability questions

A handful of definitions come up again and again, and they are easy to answer badly under pressure. A p-value is the probability of observing a result at least as extreme as the one you saw, assuming the null hypothesis is true. It is not the probability that the null hypothesis is true, and saying so clearly is worth more than any formula. The central limit theorem says that for independent draws from a distribution with finite variance, the distribution of the sample mean tends toward a normal distribution as the sample grows, which is why confidence intervals around a mean work even when the raw data is skewed.

Expect a conditional probability question, usually the medical-test shape: a rare condition, an imperfect test, what is the chance a positive result is real? Work it with counts rather than Bayes notation. Take a round population, apply the prevalence to get the number of true cases, apply the two error rates, then compare the true positives with all positives. Interviewers are checking whether you notice that a low base rate makes most positives wrong.

Experiment questions are the practical half. Be ready to explain what you would randomize over, why peeking at a running test inflates the chance of a result that is not there, what you would do about users who appear in both arms, and how you would pick a sample size: effect size you care about, variance of the metric, the error rates you will accept. If you have never run a test, say which single metric you would choose and why, which is the real question anyway.

Overfitting, validation and regularization

Machine learning interview questions and answers often start from a single idea: your model has seen this data, so your score on it means nothing. The scikit-learn documentation states it bluntly, that learning the parameters of a prediction function and testing it on the same data is a methodological mistake, since a model that just repeats the labels it has seen would have a perfect score and predict nothing useful. Hence a held-out test set.

The follow-up is why a validation set is not enough. Tuning hyperparameters against the test set lets knowledge about it leak into the model, so its scores stop reporting generalization. The usual answer is k-fold cross-validation: split the training data into k parts, train on k minus one of them, evaluate on the part left out, and average the k scores. The documentation notes the trade-off, that this is computationally expensive but does not waste much data, which matters when samples are scarce.

Then come the mechanics. Bias is error from a model too simple to capture the pattern, variance is error from a model that follows noise in the sample; regularization trades one for the other. L1 penalties can drive coefficients to exactly zero and so act as feature selection, L2 penalties shrink coefficients toward zero without removing them. Say where leakage hides: scaling or imputing before you split, target encoding computed on the whole dataset, a feature that is only known after the event you are predicting. For anything with a time order, use forward-chaining splits rather than random shuffles, because a random split lets the model train on the future.

Choosing a metric, and defending it

The most common senior-level question is not about algorithms. It is: which metric, and why? scikit-learn’s definition is a good script to borrow, that precision is the ability of the classifier not to label as positive a sample that is negative, while recall is its ability to find all the positive samples.

Show it with numbers rather than words. Take a toy set of 1,000 payments of which 20 are fraudulent.

def precision_recall(actual, predicted):
    tp = sum(1 for a, p in zip(actual, predicted) if a == 1 and p == 1)
    fp = sum(1 for a, p in zip(actual, predicted) if a == 0 and p == 1)
    fn = sum(1 for a, p in zip(actual, predicted) if a == 1 and p == 0)
    precision = tp / (tp + fp) if tp + fp else 0.0  # undefined if nothing is flagged
    recall = tp / (tp + fn) if tp + fn else 0.0
    return precision, recall

actual = [1] * 20 + [0] * 980       # 20 fraudulent payments in 1,000
flag_none = [0] * 1000              # the lazy model
flag_fifty = [1] * 50 + [0] * 950   # catches all 20, plus 30 clean payments

# flag_none:  accuracy 0.98, recall 0.0, precision undefined (nothing flagged)
# flag_fifty: precision 0.4, recall 1.0, F1 about 0.571

That is the whole argument about imbalanced data in six lines. The lazy model is right 98 percent of the time and useless, which is why scikit-learn offers balanced accuracy to avoid inflated estimates on imbalanced sets. The second model catches every fraud at the cost of 30 false alarms, and whether that is a good trade depends on what a false alarm costs the business, not on the F1 score.

If ROC AUC comes up, define it as the area under the curve of true positive rate against false positive rate as the decision threshold varies, which summarizes performance across all thresholds in one number. Then say the useful part out loud: a model ships with one threshold, so at some point someone has to choose it, and that choice belongs to whoever owns the cost of a mistake.

The coding round: Python and SQL

The coding round is rarely about exotic algorithms. It is about whether you can manipulate data without a library doing it for you. Typical tasks: group records and aggregate them with a dictionary, deduplicate while keeping the latest row per key, compute a rolling average, reshape a list of dicts into columns, or write the split that cross-validation uses.

def k_folds(n, k):
    """Indices 0..n-1 split into k contiguous folds of near-equal size."""
    sizes = [n // k + (1 if i < n % k else 0) for i in range(k)]
    folds, start = [], 0
    for size in sizes:
        folds.append(list(range(start, start + size)))
        start += size
    return folds

# k_folds(10, 3) -> [[0, 1, 2, 3], [4, 5, 6], [7, 8, 9]]

Notice what the interviewer can see there: the remainder is handled so no fold is empty, and the function says what it returns. Narrate those choices. If the data should be shuffled first, say so and say why the shuffle needs a fixed seed to be reproducible.

SQL appears in most loops too, usually a join plus an aggregate plus a window function. The SQL interview questions page covers those patterns, and Python interview questions covers the language-level questions, such as mutable default arguments and how dictionaries are ordered, that interviewers slip in between the data tasks.

The applied case and ML system design

A case prompt sounds like a product question: how would you build churn prediction, or ranking for search results, or a model to decide which support tickets get escalated. The marks are for framing, not for naming an algorithm.

Start by turning the business goal into a prediction target and a decision. What exactly is predicted, for whom, at what moment, and what happens with the output? A churn model that scores a user after they cancelled is worthless, so define the prediction window and the label rule, then say which rows are excluded. Next the features and where they come from, including whether each one is available at prediction time rather than only in hindsight. Then a baseline: a rule, a popularity ranking, last month’s value. If a baseline is close to your model, that is a finding, not an embarrassment.

Finish with evaluation and the loop after launch: offline metric, the online metric it is supposed to move, how you would roll it out, what you would monitor, and what triggers a retrain. ML engineer interviews push harder here on serving: batch scores in a table versus a live endpoint, feature freshness, and what the system does when a feature is missing. If the discussion drifts toward architecture and scale, the system design interview page covers that vocabulary.

The project deep dive, and if you are early in your career

One round will pick a project from your CV and stay on it for 40 minutes. Prepare two projects properly: the problem, why it mattered, the data and its defects, what you tried that failed, the decision the result changed, and what you would do differently. Expect to be interrupted, and expect at least one question you cannot answer. Saying “I do not know, here is how I would find out” costs very little; inventing a mechanism costs the interview.

Data science interview questions for freshers lean on the same conversation, sourced from coursework, a competition entry or a dataset you cleaned for your own curiosity. Depth beats breadth. A tidy project where you can justify every preprocessing step and name the leakage you avoided reads as stronger than three notebooks copied from a tutorial.

Two habits travel well. Keep a single page per project with the numbers on it, so you are not reconstructing a result from memory in front of a panel. And practise explaining your model twice: once to an engineer, once to someone who will ask what the business should do on Monday. Most offers are decided by that second version.