Data Scientist Interview
Questions and answers

Supervised learning uses labelled data — each row has an input and the correct output. The model learns the mapping. Examples: predicting house price (regression), classifying email as spam (classification).

Unsupervised learning uses data without labels. The model finds structure on its own. Examples: grouping customers into segments (clustering), reducing dimensions (PCA), finding anomalous transactions.

There is also semi-supervised learning, which uses a small labelled set plus a large unlabelled set — common in NLP and image tagging.

The Central Limit Theorem (CLT) says that if you take many independent random samples from any population and compute the mean of each sample, the distribution of those sample means will approach a normal distribution — as long as the sample size is large enough (usually n ≥ 30).

It matters because most statistical tests — t-tests, confidence intervals, A/B testing — assume a normal distribution of the sample mean. CLT is the reason those tests work even when the underlying population is not normal.

A p-value is the probability of observing a result at least as extreme as the one you got, assuming the null hypothesis is true.

A small p-value (typically less than 0.05) means the observed effect would be unlikely if the null hypothesis were true, so you reject the null. A large p-value means there is not enough evidence to reject it.

A p-value is not the probability that the null hypothesis is true, and it is not the size of the effect. Always report the effect size alongside it.

Type I error is controlled by the significance level (alpha). Type II error is related to power (1 − beta). Reducing one usually increases the other unless you increase sample size.

Bias is the error from a model that is too simple — it misses the real pattern. Variance is the error from a model that is too complex — it fits the training noise and does not generalise.

The trade-off: as you make a model more complex, bias goes down but variance goes up. Total error is the sum of bias squared, variance and irreducible error.

The goal is not the lowest bias or the lowest variance — it is the lowest total error on unseen data. Regularisation, cross-validation and ensembling help find that balance.

Overfitting is when a model learns the training data too well — including its noise — and performs badly on new data. The training score is high but the validation score is much lower.

Ways to prevent it:

• More data — the simplest and most reliable fix.
• Simpler model — fewer parameters, shallower trees, fewer features.
• Regularisation — L1, L2 or dropout.
• Cross-validation — to detect overfitting early.
• Early stopping — for gradient boosting and neural networks.
• Ensembling — bagging and averaging reduce variance.

Choose precision when false positives are costly — for example, flagging a genuine transaction as fraud. Choose recall when false negatives are costly — for example, missing a cancer diagnosis.

Cross-validation splits the training data into k folds. The model trains on k−1 folds and validates on the remaining fold, repeated k times. The average score across folds is a more reliable estimate of performance than a single train/validation split.

k = 5 or 10 is standard. Use StratifiedKFold for classification so each fold has the same class balance. Use TimeSeriesSplit for time-series data — a random split would leak future data into training.

Options, roughly in order of preference:

1. Understand why the value is missing. Is it truly random, or does the missingness carry meaning? "No value" in a "date of first purchase" column often means "never purchased".
2. Drop rows or columns — only when the missing proportion is small (under 5%) and the rows are not important.
3. Impute the mean or median — for numeric columns with few missing values. Median is safer with outliers.
4. Impute the mode — for categorical columns.
5. Forward or backward fill — for time-series data.
6. Model-based imputation — KNNImputer or IterativeImputer for a principled approach.
7. Add a "was_missing" flag column — so the model can learn from the missingness itself.

Always fit the imputer on the training set and apply the same transformation to the validation and test sets. Fitting on the full dataset is a data leakage bug.

Feature engineering is creating new input variables from existing data so the model can learn a pattern more easily. It is often worth more than a fancier algorithm.

Examples:

• Date features — from a timestamp, create day of week, month, quarter, is_weekend, is_holiday. Time patterns become learnable.
• Ratio features — from "amount" and "income", create "amount_to_income". A ratio often predicts default risk better than the raw values.
• Aggregate features — from a transaction table, create "average order value per customer" or "days since last purchase".
• Text features — from a description, create word count, has_url, sentiment score.

A parameter is learned by the model during training. Example: the coefficients in linear regression, the weights in a neural network.

A hyperparameter is set by you before training. Example: the number of trees in a random forest, the depth of a decision tree, the learning rate in gradient descent.

Hyperparameters are tuned with grid search, random search or Bayesian optimisation — always using cross-validation on the training set, never on the test set.

Logistic regression is a classification algorithm despite the name — it outputs a probability between 0 and 1.

A confusion matrix is a table showing the four outcomes of a binary classifier:

From these four numbers you compute accuracy, precision, recall, F1 and specificity. For imbalanced data, always look at the confusion matrix — accuracy alone is misleading.

A population is every member of the group you want to study. A sample is the subset you actually measure.

In practice you almost never have the full population — you have a sample. Statistical inference is the process of drawing conclusions about the population from the sample, with a stated level of uncertainty.

A sample must be representative — a sample of only one city cannot tell you about the whole country.

A/B testing is a controlled experiment where users are randomly split into two groups — A (control) and B (treatment). Group A sees the current version, group B sees the change. You compare a metric (click-through rate, conversion, revenue) between the two groups.

Steps:

1. State the hypothesis and the primary metric.
2. Calculate the sample size needed for the effect you want to detect.
3. Randomly assign users to A or B — never split by time or geography only.
4. Run the test long enough — usually one to two full weeks to capture weekly patterns.
5. Run a t-test or a proportion test. Report the effect size and a confidence interval, not only the p-value.

Regularisation adds a penalty to the loss function for large coefficients. This reduces variance and prevents overfitting.

Elastic Net combines both. The strength is controlled by the hyperparameter alpha (or C in scikit-learn, where smaller C means stronger regularisation).

Options, roughly in order:

1. Change the metric. Accuracy is meaningless for 1% fraud data. Use precision-recall AUC, F1 or the cost-weighted metric.
2. Adjust class weights. Set class_weight='balanced' in scikit-learn. This is the simplest effective fix.
3. Change the threshold. A model that predicts 0.5 by default may need a threshold of 0.2 to catch more positives.
4. Oversample the minority class — SMOTE creates synthetic minority samples by interpolating between neighbours.
5. Undersample the majority class — loses information but is fast.
6. Collect more data — if the minority class can be expanded.

Always split into train and test before applying SMOTE. Oversampling before splitting creates duplicates across train and test — a classic leakage bug.

In practice, gradient boosting usually wins on tabular data. Random Forest is a strong, easy baseline that needs less tuning.

A random forest builds many decision trees, each on a different bootstrap sample of the data, and each split considers only a random subset of features.

Key ideas:

• Bagging — each tree sees a different sample of rows.
• Feature randomness — each split considers sqrt(n_features) features for classification, n_features/3 for regression.
• Aggregation — classification: majority vote. Regression: average.

Two big advantages: it needs very little preprocessing, and it gives you feature importance out of the box.

ROC-AUC plots True Positive Rate against False Positive Rate across all thresholds. It measures how well the model ranks positives above negatives.

PR-AUC (Precision-Recall AUC) plots Precision against Recall. It focuses on the minority (positive) class.

For imbalanced data, PR-AUC is usually the better metric. ROC-AUC can look optimistic because the large number of true negatives inflates the FPR denominator. Say this in an interview and you show real understanding.

Feature scaling puts numeric features on a similar range so no single feature dominates because of its units.

Needed for: linear regression with regularisation, logistic regression, k-NN, SVM, PCA, k-means, neural networks.

Not needed for: decision trees, random forest, gradient boosting — they split on thresholds, so scale does not matter.

Always fit the scaler on the training set only and apply the same scaler to the validation and test sets.

Data leakage is when information from the target or from the future leaks into the training features. The model looks excellent in validation and fails in production.

Common causes:

• Fitting the scaler or imputer on the full dataset before splitting.
• Target leakage — a feature that is only available after the outcome. Example: "loan default date" as a feature for predicting default.
• Time-based leakage — using future rows to predict past rows, or a random split on time-series data.
• Duplicate rows across train and test — often introduced by oversampling before the split.

Detection: if a model has suspiciously high performance (AUC above 0.99 on a hard problem), suspect leakage. Check the feature importance and the data pipeline carefully.

PCA (Principal Component Analysis) is a dimensionality reduction technique. It finds new axes (principal components) that capture the maximum variance in the data, ordered from most to least important.

When to use it:

• High-dimensional data — hundreds or thousands of features.
• Visualisation — reduce to 2 or 3 components and plot.
• Removing multicollinearity — components are uncorrelated.
• Speeding up a slow model — fewer features mean faster training.

Downside: components are linear combinations of the original features, so you lose interpretability. Always scale features before PCA — otherwise large-unit features dominate.

k-means is an iterative algorithm:

1. Choose k — the number of clusters.
2. Initialise k centroids randomly (or with k-means++).
3. Assign each point to the nearest centroid.
4. Recompute each centroid as the mean of its assigned points.
5. Repeat steps 3 and 4 until assignments stop changing or the max iterations is reached.

Choosing k: use the elbow method (plot inertia vs k) or the silhouette score.

Limitations: you must specify k in advance, it assumes spherical clusters of similar size, and it is sensitive to outliers and scale. Always scale features before running k-means.

Research shows random search finds a good configuration faster than grid search when only a few hyperparameters matter. Use Bayesian optimisation (Optuna, Hyperopt) when training is expensive — it learns from previous trials.

Detection methods:

• IQR method — values below Q1 − 1.5×IQR or above Q3 + 1.5×IQR are outliers.
• Z-score — values more than 3 standard deviations from the mean.
• Isolation Forest — a tree-based anomaly detector for high-dimensional data.
• Visual — box plot, scatter plot, histogram.

Handling options:

• Keep them if they are real and important — for example, a large enterprise customer.
• Cap them (winsorise) at a percentile such as 1% and 99%.
• Remove them only if they are data errors and the proportion is small.
• Use a robust model — tree-based models handle outliers better than linear models.

Never remove outliers blindly. Investigate first, and document the decision.

A parametric test assumes the data follows a known distribution — usually normal. Examples: t-test, ANOVA, Pearson correlation.

A non-parametric test makes no distribution assumption. It usually works on ranks. Examples: Mann-Whitney U, Wilcoxon signed-rank, Kruskal-Wallis, Spearman correlation.

Use non-parametric tests when the sample is small, the data is heavily skewed, or the variable is ordinal. They are often slightly less powerful when the normality assumption actually holds.

Ask these questions in order:

1. What is the metric? If the business cares about accuracy, the metric decides. Compare models on a held-out validation set, not on the training set.
2. How much data do you have? With little data, a simple model wins. With lots of data, complex models usually perform better.
3. Does the stakeholder need to understand the model? If yes, logistic regression or a shallow tree beats a deep neural network, even at slightly lower accuracy.
4. What is the inference cost? A model that takes 2 seconds to score will not serve real-time traffic.
5. How often will the model be retrained? Complex models take longer to train and to maintain.

Start simple. A logistic regression baseline that you can explain beats a black box you cannot defend.

Data scientists use SQL to pull training data and features. The most common patterns:

-- Filter and aggregate
SELECT customer_id, SUM(amount) AS total_spend
FROM orders
WHERE order_date >= '2025-01-01'
GROUP BY customer_id
HAVING SUM(amount) > 10000;

-- Window function for ranking
SELECT customer_id, order_date, amount,
       ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date) AS rn
FROM orders;

-- CTE for a feature table
WITH recent_orders AS (
    SELECT customer_id, MAX(order_date) AS last_order
    FROM orders
    GROUP BY customer_id
)
SELECT c.customer_id,
       DATEDIFF(CURRENT_DATE, r.last_order) AS days_since_last_order
FROM customers c
LEFT JOIN recent_orders r ON c.customer_id = r.customer_id;

Focus on SELECT with WHERE, GROUP BY, JOIN, window functions and CTEs. INSERT, UPDATE and DELETE are used only in data preparation.

A Series is a one-dimensional labelled array — essentially a single column. It has an index and a value for each index entry.

A DataFrame is a two-dimensional table — a collection of Series that share the same index. It has rows and columns with labels for both.

import pandas as pd

s = pd.Series([10, 20, 30], name="sales")
df = pd.DataFrame({"region": ["North", "South"],
                   "sales":  [100, 200]})

print(type(df["sales"]))   # Series
print(df.shape)                # (2, 2)

Step 1 — Data ingestion. Scheduled jobs pull data from source systems into a warehouse or feature store. Version the raw data.

Step 2 — Feature engineering. Reusable features live in a feature store so training and serving use the same transformation code.

Step 3 — Training. Runs on a schedule or on trigger. Trains on a defined window, logs metrics and artifacts to MLflow or a similar tool.

Step 4 — Evaluation. Compare the new model to the current production model on the same holdout set. Add a business rule or human review for high-impact decisions.

Step 5 — Deployment. Package as an API (FastAPI, Flask) or a batch job. Containerise with Docker. Deploy with a blue-green or canary strategy.

Step 6 — Monitoring. Track input drift (PSI, KL divergence), prediction distribution, latency and business metrics. Alert on drift or on metric degradation.

Step 7 — Retraining. Define a trigger — a drop in performance, or a fixed cadence. Automate the retraining path so it does not depend on someone remembering.

Three levels of monitoring:

1. Operational. Is the API up? What is the latency? What is the error rate? What is the throughput? This is standard application monitoring.
2. Data and feature drift. Are the input distributions still similar to training? Use Population Stability Index (PSI) or KL divergence. Alert when a key feature moves by more than a threshold.
3. Model performance. When the labels arrive, compute precision, recall, RMSE, AUC and compare to baseline. Where labels are delayed, use proxy metrics that correlate with the target.

Also track prediction distribution — a shift in the fraction of positives is often the first sign of a change before labels arrive. Set alerts so the team is paged only when the change is meaningful.

Do not talk about the algorithm. Talk about the outcome and the risk.

Structure:

1. What the model does in one sentence — "It predicts which customers are likely to leave in the next 30 days."
2. How well it works using a business metric — "It catches 70% of churners with a 15% false-positive rate."
3. What drives the prediction using SHAP or feature importance — "The top three factors are days since last login, contract type and number of support tickets."
4. What action to take — "We will offer a retention discount to the top 10% by predicted risk."
5. What can go wrong — "If the usage data feed is delayed, predictions may be stale."

Use SHAP summary plots and one or two individual predictions. Avoid talking about gradient boosting, learning rates or log-loss unless asked.

Business cost, always. Higher accuracy is only useful if it translates to better business outcomes.

Approach:

1. Estimate the cost of a false positive and a false negative. For a fraud model, a false positive blocks a good customer; a false negative lets fraud through.
2. Build a cost-weighted metric — expected cost = FP × cost_FP + FN × cost_FN.
3. Tune the threshold to minimise the expected cost, not to maximise accuracy.
4. Compare candidate models on this cost metric, not on accuracy.
5. Confirm with the business that the cost estimates are realistic.

A model with 80% accuracy that minimises business cost beats a 90% accurate model that does not.

The problem a feature store solves is training-serving skew — when the feature computed during training differs from the feature computed during serving. One codebase, one definition of each feature.

Ask what they actually need. "Explainable" can mean three different things:

1. Global explainability. Which features drive the model overall? Use feature importance or SHAP summary plots.
2. Local explainability. Why did the model make this specific prediction? Use SHAP force plots or LIME.
3. Regulatory explainability. Can we justify a decision to a customer or a regulator? This usually needs a simpler, interpretable model.

For regulatory or legal use cases, a logistic regression or a shallow decision tree with clear rules is often the correct answer, even at slightly lower accuracy. Explainability is a requirement, not an optional extra.

Three main approaches:

1. Content-based. Recommend items similar to what the user liked before. Use item features (genre, category, tags) and similarity metrics.
2. Collaborative filtering. Use the pattern of user-item interactions. User-based: find similar users. Item-based: find similar items. Matrix factorisation (ALS, SVD) learns latent factors for users and items.
3. Hybrid. Combine both. Most production systems use a two-stage design: candidate generation (fast recall of thousands of items) then ranking (a heavier model scores the top hundreds).

Evaluation: offline (precision@k, recall@k, NDCG) then online (A/B test on click-through rate, conversion, watch time).

Cold start is the hard problem — a new user or a new item has no history. Solve with popularity fallback, content features or contextual signals.

A transformer is a neural network architecture built on self-attention. Instead of processing a sequence one step at a time like an RNN, it looks at all positions in the sequence in parallel and learns which positions matter for each other.

Key components: multi-head self-attention, positional encoding, feed-forward layers, layer normalisation, and residual connections. The original transformer had an encoder (for understanding) and a decoder (for generation).

An LLM (Large Language Model) is a very large transformer trained on a huge text corpus using self-supervised learning — predict the next token. Examples: GPT, Claude, Llama, Gemini. They power chat assistants, summarisation, code generation and retrieval-augmented generation (RAG) systems.

At a data science interview level, know the architecture, the training objective (next-token prediction), the difference between encoder-only (BERT for classification) and decoder-only (GPT for generation), and when an LLM is the right tool versus a classical model.

Data drift is a change in the input distribution. Concept drift is a change in the relationship between inputs and the target.

Detection:

• Statistical tests — Kolmogorov-Smirnov for numeric features, chi-square for categorical features.
• Population Stability Index (PSI) — a single number per feature. PSI above 0.2 usually triggers investigation.
• Monitor model performance when labels arrive. A drop in AUC or a shift in error rate is a signal.
• Prediction distribution — a shift in the fraction of positives is often the earliest indicator.

Correction:

• Retrain on recent data — the simplest and often the correct answer.
• Reweight training data to emphasise recent rows.
• Recalibrate the model outputs if the ranking is still good but the probability scale is off.
• Rebuild the feature pipeline if the drift is caused by a change in the upstream system.

Typical steps:

1. Save the model. Use joblib or pickle for scikit-learn; SavedModel or ONNX for deep learning.
2. Wrap in a web framework. FastAPI or Flask exposes a /predict endpoint that accepts JSON, runs the model and returns the prediction.
3. Containerise. A Docker image with the model, the code and the dependencies pinned.
4. Deploy. To a container service — Kubernetes, AWS ECS, Azure Container Apps, GCP Cloud Run.
5. Add observability. Log every request with the input, the prediction and the latency. Alert on errors and on drift.
6. Version and roll back. Deploy as a new version with a canary or blue-green strategy so you can revert quickly.

from fastapi import FastAPI
from pydantic import BaseModel
import joblib

app = FastAPI()
model = joblib.load("model.pkl")

class Features(BaseModel):
    tenure: int
    monthly_charges: float

@app.post("/predict")
def predict(f: Features):
    X = [[f.tenure, f.monthly_charges]]
    prob = model.predict_proba(X)[0][1]
    return {"churn_probability": float(prob)}

Step 1 — Understand the text. Language, average length, number of classes, class balance. Sample a few examples manually.

Step 2 — Baseline. TF-IDF with logistic regression. Fast, interpretable and often surprisingly strong. Do not skip this step.

Step 3 — Preprocessing. Lowercase, remove URLs, expand contractions. Skip heavy stemming or stop-word removal for transformer models — they handle raw text well.

Step 4 — Transformer model. Fine-tune a pretrained model such as DistilBERT or RoBERTa. Even with a few thousand labelled examples, this beats TF-IDF.

Step 5 — Evaluate per class. Look at the confusion matrix, not only the overall F1. Look at misclassified examples — the errors usually reveal a data quality problem.

Step 6 — Handle imbalance with class weights or threshold tuning, not with accuracy.

Connect the model metric to a business metric. A model is only useful if it changes a decision.

Approach:

1. State the decision the model supports — who will act on the prediction, and what will they do?
2. Map the model metric to the business metric. AUC 0.85 is not useful; "₹2 crore of retained revenue from 1,000 targeted customers" is.
3. Quantify with an A/B test or a holdout. Compare the treated group to a control group and measure the incremental revenue or cost.
4. Report the confidence interval, not just the point estimate.
5. Track the impact after deployment — does the benefit persist, or decay as the model ages?

Step 1 — Suspect class imbalance. If 98% of the data is one class, a model that always predicts the majority class gets 98% accuracy and predicts nothing useful.

Step 2 — Look at the confusion matrix and per-class metrics. Precision and recall for the minority class are almost certainly close to zero.

Step 3 — Switch the metric to PR-AUC, F1 or the cost-weighted business metric.

Step 4 — Fix the class imbalance with class weights, resampling or threshold tuning.

Step 5 — Re-evaluate against the business metric: how many of the actual positives are being caught, and at what false-positive cost?

Step 1 — Compare the distribution of each feature in production to the training set. A shift in a key feature is the most common cause.

Step 2 — Check for data leakage in the validation setup. A model that looked too good in validation is suspicious.

Step 3 — Check training-serving skew — the feature computed during training must be identical to the one served in production.

Step 4 — Check the time window. Did you train on older data and evaluate on recent data with a different pattern?

Step 5 — Check the scoring pipeline itself — a missing feature, a wrong default value, a different column order.

Step 6 — Rebuild the validation set to match production conditions — time-based split, same feature pipeline, same pre-processing.

Step 1 — Define churn precisely. Is it no purchase in 90 days, cancellation of a subscription, or a drop in usage below a threshold? The definition drives the labels.

Step 2 — Define the prediction window. Are we predicting churn in the next 30 days, 90 days or a quarter?

Step 3 — Define the action. Will marketing send a discount to high-risk customers? Will support proactively call them? The action determines the metric and the threshold.

Step 4 — Choose the metric. If the action is a costly discount, precision matters. If the action is a cheap email, recall matters more.

Step 5 — Build a baseline — logistic regression on usage and tenure. Then try gradient boosting. Compare on the same time-based holdout.

Step 6 — Ship with an A/B test. Measure the retained revenue, not just the model metric.

Step 1 — Explain that with p = 0.12 there is a 12% chance of seeing this result if the change had no effect. That is above the standard 5% threshold, so the result is not statistically significant.

Step 2 — Look at the confidence interval on the lift. If it spans zero, the effect could be zero or even negative.

Step 3 — Check the sample size and duration. Was the test powered to detect the effect size the business cares about?

Step 4 — Check for novelty effects or segment-level effects that the aggregate is hiding.

Step 5 — Recommend one of: extend the test, ship if the business accepts the risk, or do not ship. Never call an insignificant result "positive".

Step 1 — Remove features that leak the target or that would not be available at prediction time.

Step 2 — Remove constant and near-constant features — they carry no signal.

Step 3 — Remove highly correlated features. Keep one of each pair above 0.95 correlation.

Step 4 — Check missing-value rate. Features with more than 60-70% missing are usually not worth the imputation effort.

Step 5 — Use a filter method — correlation with the target, mutual information — to shortlist the top 60-80 features.

Step 6 — Use an embedded method — L1 regularisation or tree feature importance — to reduce further.

Step 7 — Compare model performance with the shortlisted set vs the full set on a validation split. If the metric is the same, keep the smaller set.

Step 1 — Check for a proxy label. For churn, "no purchase in 90 days". For fraud, "chargeback raised". A proxy is often good enough to start.

Step 2 — Use weak supervision — rules, heuristics or pattern matching to label a subset with high precision.

Step 3 — Hand-label a small, high-quality set — 500 to 2,000 examples. This is often faster than building a labelling pipeline.

Step 4 — Use a pretrained model as a starting point — a transformer for text, a pretrained CNN for images. Fine-tune on the small labelled set.

Step 5 — Use active learning — train on the small labelled set, then have a human label the examples the model is most unsure about.

Step 6 — Ship an MVP that is better than the current rule-based system, and improve the labels over time.

Step 1 — Use a local explanation method — SHAP force plot or LIME — on the specific prediction.

Step 2 — Translate the top three to five contributing features into business language. "High debt-to-income ratio, short credit history and recent missed payment pushed this application below the threshold."

Step 3 — Show the magnitude and direction of each feature's contribution, not just the feature names.

Step 4 — If the model is a black box and the decision is high-stakes, consider training a simpler surrogate model — a shallow decision tree — to approximate the black box for explanation purposes.

Step 5 — Have a manual review path for borderline or disputed decisions. Explainability is not a substitute for oversight.

Week 1 — Data and framing. Confirm the business question, get access to the data, profile it, and set up a simple baseline model. Share a short written problem statement with the stakeholder.

Week 2 — Baseline model. Build a logistic regression or decision tree. Measure it on a time-based holdout. Present the baseline result — "here is what a simple model can do".

Week 3 — Improve. Feature engineering, gradient boosting, hyperparameter tuning. Cap the improvement work at three days — diminishing returns kick in quickly.

Week 4 — Wrap. Explain the model with SHAP, write a short memo, prepare a deck, and define what "deployed" means — an API, a batch job or a notebook the analyst runs manually.

Set expectations early. A working model in week 2 that the business can react to beats a perfect model delivered on the last day.

import pandas as pd

df = pd.read_csv("customers.csv")

print(df.shape)
print(df.isnull().sum())

# Fill numeric columns with the median
num_cols = df.select_dtypes(include="number").columns
df[num_cols] = df[num_cols].fillna(df[num_cols].median())

# Fill categorical columns with the mode
cat_cols = df.select_dtypes(include="object").columns
for c in cat_cols:
    df[c] = df[c].fillna(df[c].mode()[0])

print(df.isnull().sum().sum())

(1000, 12)
tenure         0
monthly        15
city           3
dtype: int64
0

Always inspect the missing count before deciding the imputation strategy. Fill numeric columns with median (safer with outliers) and categorical columns with mode.

import pandas as pd

df = pd.DataFrame({
    "order_id": [1, 2, 3],
    "order_ts": ["2026-01-05 10:30", "2026-03-15 18:00", "2026-05-28 08:15"]
})
df["order_ts"] = pd.to_datetime(df["order_ts"])

df["year"]       = df["order_ts"].dt.year
df["month"]      = df["order_ts"].dt.month
df["day_of_week"] = df["order_ts"].dt.dayofweek
df["is_weekend"] = df["order_ts"].dt.dayofweek >= 5
df["hour"]       = df["order_ts"].dt.hour

print(df)

   order_id           order_ts  year  month  day_of_week  is_weekend  hour
0         1 2026-01-05 10:30:00  2026      1            0       False    10
1         2 2026-03-15 18:00:00  2026      3            6        True    18
2         3 2026-05-28 08:15:00  2026      5            3       False     8

Convert to datetime first, then use the .dt accessor. The same pattern works for any timestamp column and is the fastest way to make time patterns learnable.

from sklearn.model_selection import train_test_split
from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler, OneHotEncoder
from sklearn.impute import SimpleImputer
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report

num_cols = ["tenure", "monthly_charges"]
cat_cols = ["contract", "payment_method"]

num_pipe = Pipeline([
    ("imp", SimpleImputer(strategy="median")),
    ("sc",  StandardScaler())
])
cat_pipe = Pipeline([
    ("imp", SimpleImputer(strategy="most_frequent")),
    ("oh",  OneHotEncoder(handle_unknown="ignore"))
])

preprocess = ColumnTransformer([
    ("num", num_pipe, num_cols),
    ("cat", cat_pipe, cat_cols)
])

model = Pipeline([
    ("prep", preprocess),
    ("clf",  RandomForestClassifier(n_estimators=300, random_state=42))
])

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, stratify=y, random_state=42)

model.fit(X_train, y_train)
print(classification_report(y_test, model.predict(X_test)))

              precision    recall  f1-score   support
           0       0.85      0.90      0.87       120
           1       0.72      0.62      0.67        50
    accuracy                           0.82       170

The pipeline ensures the same preprocessing is applied at training and scoring. It also prevents leakage — the imputer and scaler are fit only on the training folds during cross-validation.

from sklearn.model_selection import GridSearchCV, StratifiedKFold
from sklearn.ensemble import GradientBoostingClassifier

cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)

param_grid = {
    "clf__n_estimators":  [100, 300],
    "clf__max_depth":     [3, 5, 7],
    "clf__learning_rate": [0.05, 0.1]
}

grid = GridSearchCV(
    model, param_grid, cv=cv, scoring="roc_auc",
    n_jobs=-1, verbose=0)

grid.fit(X_train, y_train)

print("Best params:", grid.best_params_)
print("Best CV AUC:", round(grid.best_score_, 3))
print("Test AUC:",    round(grid.score(X_test, y_test), 3))

Best params: {'clf__learning_rate': 0.1, 'clf__max_depth': 5, 'clf__n_estimators': 300}
Best CV AUC: 0.864
Test AUC:    0.859

If the CV AUC is much higher than the test AUC, the tuning has started to overfit the validation folds. Use nested cross-validation or a separate holdout for model selection.

from sklearn.linear_model import LogisticRegression
from sklearn.metrics import average_precision_score, roc_auc_score
import numpy as np

# 2% positive class
model = LogisticRegression(
    class_weight="balanced", max_iter=1000, random_state=42)
model.fit(X_train, y_train)

probs = model.predict_proba(X_test)[:, 1]

print("PR-AUC:",  round(average_precision_score(y_test, probs), 3))
print("ROC-AUC:", round(roc_auc_score(y_test, probs), 3))

# Tune the threshold for F1
from sklearn.metrics import precision_recall_curve, f1_score
prec, rec, thr = precision_recall_curve(y_test, probs)
f1 = 2 * prec * rec / (prec + rec + 1e-9)
best_thr = thr[np.argmax(f1[:-1])]
print("Best threshold:", round(best_thr, 3))

PR-AUC:  0.412
ROC-AUC: 0.876
Best threshold: 0.34

With 2% positives, the ROC-AUC of 0.88 looks great but the PR-AUC of 0.41 shows the real challenge. Always report both, and tune the threshold using the PR curve, not the default 0.5.

import shap
import pandas as pd
from sklearn.ensemble import RandomForestClassifier

model = RandomForestClassifier(n_estimators=300, random_state=42)
model.fit(X_train, y_train)

# TreeExplainer is fast for tree models
explainer   = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X_test)

# Global feature importance
shap.summary_plot(shap_values, X_test, plot_type="bar")

# Mean absolute SHAP value per feature
importance = pd.Series(
    abs(shap_values).mean(axis=0),
    index=X_test.columns
).sort_values(ascending=False)
print(importance.head(5))

tenure            0.187
monthly_charges   0.142
contract          0.098
payment_method    0.061
num_support       0.052

SHAP gives both a global view (which features drive the model overall) and a local view (why this specific prediction was made). Use the summary_plot in a business deck and the force_plot for an individual decision.

Problem framing. Binary classification: will this customer default in the next 30 days? Decision: reduce credit limit or flag for a retention/support call. The cost of a false negative (letting a defaulter through) is much higher than a false positive (a good customer gets a smaller limit).

Data. Historical transaction, repayment and account data for the last two years. Typical columns: age, credit limit, bill amounts, previous payments, education, marital status, default flag from the prior month.

Features.

• Utilisation ratio = bill amount ÷ credit limit.
• Payment ratio = payment ÷ bill amount (last month, average of last three months).
• Delinquency count — number of months with a payment delay in the last 6 and 12 months.
• Months on book — tenure with the bank.
• Bill trend — slope of the bill amount over the last six months.

Model. Start with logistic regression for a strong baseline and for the coefficients that a compliance team can review. Move to gradient boosting (XGBoost or LightGBM) for the production model. Use stratified 5-fold cross-validation, and split by time — train on months 1–18, validate on 19–21, test on 22–24.

Metric. Because of class imbalance (defaults are typically 2–5% of accounts), use PR-AUC as the main metric, and recall at a fixed precision as a business metric. Also report the confusion matrix at the chosen threshold.

Explainability. SHAP values per customer so the bank can explain a decision. The top drivers are usually utilisation, delinquency count and payment ratio — all of which make intuitive sense and match the domain.

Business answer. Deploy the model as a monthly batch job. Score all active accounts and hand the top risk bucket to the risk team for review. Run an A/B test for three months — a control group reviewed by the current rule and a treatment group reviewed by the model — and compare the loss rate. If the model reduces default loss by even 10-15%, it pays back the cost of building it.

Problem framing. Two problems, not one. First: predict which customers will churn in the next 30 days. Second: estimate the effect of a retention action on a churner. The 20% reduction target is a business target, not a model metric.

Data. Usage logs, subscription details, billing history, support tickets and app events, joined at the customer-month level.

Features.

• Recency: days since last login, days since last payment.
• Frequency: logins in the last 7, 30, 90 days; sessions per week.
• Monetary: monthly recurring revenue, average order value.
• Engagement trend: slope of logins over the last 3 months — a falling trend predicts churn better than any absolute value.
• Support signals: number of tickets, average resolution time, sentiment of the last ticket.
• Contract: plan type, tenure, discount applied, auto-renew flag.

Model. Gradient boosting (LightGBM or XGBoost) for the churn classifier. For the uplift model (who will respond to the retention offer), use a two-model approach — one model on the treatment group, one on the control group — and compute the difference. This is the correct approach when you have historical A/B test data.

Metric. PR-AUC for the churn classifier. For the retention decision, use uplift at the top decile — how much incremental retention does the offer create among the highest-uplift customers? Not the overall churn rate, which hides the effect on customers who would have stayed anyway.

Business answer. Do not send the retention offer to every predicted churner — many will stay without an offer. Send it only to customers with a high predicted churn risk AND a positive predicted uplift. Run a proper A/B test with a control group to measure the incremental retention. A model that identifies 1,000 truly persuadable customers is worth more than one that identifies 10,000 churners.