Mock Interview Simulator¶

A complete mock interview session. Work through it exactly as you would a real interview: read each question, close the answer block, think for 60–90 seconds, then open the answer and compare.

Do not open answers until you have tried. The discomfort of not knowing is the practice.

How to Use This

Set a 90-minute timer.
Read each question aloud — interviews are verbal.
Think through your answer before opening the collapsible block.
After opening the answer: note what you missed, not what you got right.
At the end, re-answer any question you rated yourself below 7/10.

Round 1 — Screening (25 minutes)¶

These questions appear in the first 20–30 minutes of almost every data science interview. They test whether you can hold a conversation about fundamentals.

Q1. Walk me through the steps you would take from receiving a raw dataset to delivering a trained model.

Show answer

A complete end-to-end response covers these phases in order:

Frame the problem — What decision does this model support? What does success look like? What metric matters to the business?
Understand the data — Shape, dtypes, missing values, target distribution, time range, how it was collected.
EDA — Univariate distributions, bivariate relationships, outlier detection, data quality checks.
Feature engineering — Impute missing values, encode categoricals, scale numerics, create domain-specific features. Everything fit on train only.
Baseline — Always start with a dumb baseline (DummyClassifier, mean predictor) to establish a floor.
Model training — Try 2–3 model families; tune hyperparameters with cross-validation, not the test set.
Evaluation — Evaluate on the held-out test set once. Report the metric that was agreed upon upfront.
Communicate findings — Plain-English summary of what the model does, what it doesn't do well, and what data would improve it.

Common miss: candidates skip the baseline step or say "I'd try many models" without explaining the selection criteria.

Q2. What is the bias-variance tradeoff? Give a concrete example.

Show answer

Bias is systematic error from wrong assumptions — the model is too simple to capture the true pattern. Variance is sensitivity to fluctuations in the training set — the model memorises noise.

The tradeoff: reducing bias (more complex model) typically increases variance, and vice versa. The goal is the sweet spot that minimises total error = bias² + variance + irreducible noise.

Concrete example: Predicting house prices. - High bias: linear regression on a dataset with non-linear relationships → systematically underpredicts expensive houses. - High variance: a decision tree with no depth limit → fits training set perfectly (R²=0.99) but performs poorly on new houses (R²=0.60). - Good tradeoff: Random Forest with moderate depth → generalises well to unseen houses.

Diagnosis: plot learning curves. A large gap between train and validation score = high variance. Both scores low and converged = high bias.

Q3. Explain what p-value means. What does p < 0.05 actually tell you?

Show answer

A p-value is the probability of observing results at least as extreme as your data, assuming the null hypothesis is true.

p < 0.05 means: if H₀ were true, you'd see data this extreme or more extreme only 5% of the time. It does NOT mean: - There is a 95% chance H₀ is false. - The effect is large or practically meaningful. - The result will replicate.

The 0.05 threshold is arbitrary and context-dependent. In medical trials, 0.001 is common. In exploratory data work, 0.10 may be acceptable.

Always pair statistical significance with effect size. A p-value of 0.001 on a difference of 0.001% conversion rate is statistically significant but practically irrelevant.

Q4. What is data leakage? Give two types and explain why each is dangerous.

Show answer

Data leakage is when information from outside the training period (or the training set boundary) is used to build or evaluate the model, causing optimistically biased performance estimates.

Type 1 — Target leakage: A feature contains information that is only available after the outcome is known. - Example: In a loan default model, including collection_agency_contact as a feature — this only happens after a default. The model learns a spurious rule and will fail in production.

Type 2 — Train-test contamination: Preprocessing is fit on the entire dataset before splitting. - Example: Fitting a StandardScaler on all 10,000 rows, then splitting into train/test. The scaler has "seen" the test set; scaling parameters are influenced by test distribution. Validation scores are inflated. - Fix: always fit preprocessing inside a Pipeline, or fit only on the training fold.

Why dangerous: models look great in evaluation but fail immediately in production. Leakage is one of the most common reasons for the "it worked in testing" failure mode.

Q5. What's the difference between precision and recall? When would you optimise for one over the other?

Show answer

Given a binary classifier: - Precision = TP / (TP + FP) — of all the times the model said "positive", how often was it right? - Recall = TP / (TP + FN) — of all actual positives, what fraction did the model catch?

F1 = harmonic mean of precision and recall; use when you need a single metric and both matter.

Optimise for recall when missing a positive is costly: - Cancer screening: missing a tumour (FN) is far worse than a false alarm (FP). - Fraud detection: missing fraud is worse than flagging a legitimate transaction for review.

Optimise for precision when false positives are costly: - Spam filter: incorrectly blocking a legitimate email (FP) is worse than letting some spam through. - Content moderation for removal: wrongly removing legitimate content damages trust.

In practice, tune the decision threshold (default 0.5) rather than changing the model. Lowering the threshold increases recall; raising it increases precision.

Round 2 — Technical Deep Dive (35 minutes)¶

These questions test whether you can go one level deeper than textbook definitions. Interviewers use them to separate candidates who have used these techniques from those who have only read about them.

Q6. You have a dataset with 40% missing values in one feature. Walk me through how you'd decide what to do with it.

Show answer

The decision depends on three things: why the data is missing, how important the feature is, and what model you're using.

Step 1 — Understand the missingness mechanism: - Missing completely at random (MCAR): missingness is unrelated to any variable. Safe to drop rows or impute. - Missing at random (MAR): missingness depends on other observed variables. Impute using those relationships. - Missing not at random (MNAR): missingness relates to the missing value itself (e.g., high earners don't report income). Imputation is risky; the missing indicator itself is a feature.

Step 2 — Check if missingness is informative: - Is the rate of missingness different between target=0 and target=1? If yes, feature_is_missing is a useful binary feature.

Step 3 — Choose imputation strategy: - 40% missing is high. Options: - Mean/median imputation: fast, loses distributional info, add a _missing indicator column. - KNN or IterativeImputer: better for MAR, preserves relationships, slower. - Drop the column: if the feature has low predictive power and 40% is missing.

Step 4 — Never impute before splitting. Fit the imputer on train, apply to train and test separately.

40% missing is high enough that I'd create the missing indicator regardless of which imputation I choose, because the missingness pattern may itself be predictive.

Q7. Explain how gradient boosting works. How does it differ from bagging/Random Forest?

Show answer

Bagging (Random Forest): Train N decision trees independently on bootstrap samples of the data (with row and column subsampling). Combine predictions by averaging (regression) or majority vote (classification). Trees are de-correlated because they see different data. Parallelisable. Reduces variance.

Gradient Boosting: Train trees sequentially. Each new tree fits the residuals (errors) of the ensemble so far — more precisely, it fits the negative gradient of the loss function. The final prediction is the sum of all trees' predictions multiplied by a learning rate.

Key differences: | | Random Forest | Gradient Boosting | |---|---|---| | Tree training | Parallel, independent | Sequential, each corrects the last | | Primary benefit | Reduces variance | Reduces bias | | Overfitting risk | Low | Higher (needs careful tuning) | | Key hyperparams | n_estimators, max_features | n_estimators, learning_rate, max_depth | | Speed | Fast | Slower |

GBM tends to have higher ceiling accuracy; RF is more robust and easier to tune. In practice, XGBoost/LightGBM are the production-grade implementations of gradient boosting — they add regularisation (L1/L2 on leaf weights), column subsampling, and hardware optimisations.

Q8. You build a model with 95% accuracy on a test set. Your manager is excited. What questions do you ask before celebrating?

Show answer

High accuracy is meaningless without context. Ask:

What is the class distribution? If 95% of samples are class 0, a model that always predicts 0 gets 95% accuracy. Check precision, recall, and F1 per class.
What was the baseline? If a dummy classifier gets 93%, our 95% adds little value.
Is the test set representative? Was it held out properly, or did it overlap with training data? Is it from the same time period and population as production?
Is the test set large enough? On 100 samples, 95% accuracy has wide confidence intervals.
What metric does the business actually care about? For fraud, the cost of a missed fraud vs a false positive may be asymmetric — accuracy doesn't capture that.
How does performance vary across subgroups? A model might be 95% accurate overall but perform poorly on a minority group that matters.
What does it do on the tail cases? The 5% errors might be the most consequential predictions.

Q9. Walk me through how you would set up an A/B test for a new recommendation algorithm.

Show answer

A rigorous A/B test involves these steps:

1. Define the metric. Pick one primary metric (e.g., click-through rate, revenue per session) and a few guardrail metrics (e.g., page load time, refund rate). The primary metric must be measurable within the experiment window.

2. Power analysis. Determine minimum detectable effect (MDE) — the smallest improvement that's worth caring about. Given MDE, baseline metric value, variance, and desired α (0.05) and power (0.80), compute required sample size. Don't run until you reach it.

3. Randomisation unit. Usually user-level (not session-level) to avoid within-user contamination. If users interact with each other (social features), consider cluster-level randomisation.

4. Run the experiment. Typically 1–2 weeks to capture weekly cycles. Don't peek and stop early — this inflates false positive rate.

5. Check for SRM. Sample Ratio Mismatch: if you expected 50/50 split but got 48/52, something went wrong in assignment. Investigate before interpreting results.

6. Analyse. t-test or Z-test for proportions. Report p-value, confidence interval, and effect size — not just whether p < 0.05.

7. Decision. Even a statistically significant result requires a business judgment: is the effect size worth the deployment cost and risk?

Common pitfalls: peeking (stopping when p < 0.05 during the run), multiple comparisons without correction, confusing statistical and practical significance.

Q10. Your model performs well in offline evaluation but degrades two weeks after deployment. What do you check?

Show answer

This is almost always a data distribution shift problem. Work through these hypotheses:

1. Feature distribution shift (covariate shift): The distribution of inputs has changed since training. Check: plot feature distributions over time. Common causes: seasonal effects, user behaviour changes, upstream data pipeline changes.

2. Label drift: The relationship between features and labels has changed. Example: a churn model trained in Q1 may not capture Q4 holiday behaviour patterns. Harder to detect without fresh labels.

3. Upstream data quality: A pipeline change silently introduced missing values, encoding errors, or a column rename. Check: schema validation logs, data freshness timestamps.

4. Training-serving skew: Features are computed differently at serving time than at training time. Example: training used a 30-day rolling window, but serving mistakenly uses a 7-day window. Check: compare raw feature values between training set and live traffic sample.

5. Feedback loop: Model predictions influence future data that the model is trained on (e.g., a recommendation model that creates a filter bubble). Check: compare metrics across user cohorts with different exposure levels.

Mitigation: Implement monitoring dashboards for input feature drift (PSI score) and prediction distribution drift. Set up automated retraining triggers. Log live predictions and outcomes for continual evaluation.

Round 3 — Case Study (25 minutes)¶

You are given a business problem and must structure a solution live. The interviewer is evaluating your thought process, not just your answer.

Q11. Case: A payments company wants to detect fraudulent transactions in real time. Describe how you would build this system end-to-end.

Show answer

Structure your answer around: Problem framing → Data → Features → Model → Evaluation → Deployment → Monitoring.

Problem framing: - Real-time means latency constraint: prediction must complete in <100ms. - Fraud is rare: typically 0.1–1% of transactions (severe class imbalance). - Cost asymmetry: a missed fraud costs more than a false positive (blocked legitimate transaction). - Business metric: dollar amount of fraud prevented, not raw accuracy.

Data: - Transaction features: amount, merchant category, time of day, day of week, country. - User history features: average transaction amount, velocity (number of transactions in past 1 hour, 24 hours), recent new merchant ratio, geography change. - Device/session features: IP address, device fingerprint, session duration.

Features: - Compute aggregates (rolling windows, velocity counts) in a feature store. - Key: these must be computable in real time at inference. Design the feature pipeline before the model.

Model: - Start with a simple LightGBM classifier — fast inference, handles imbalance well with scale_pos_weight. - Use SMOTE or stratified sampling, not oversampling on test data. - Optimise for recall (catch fraud) with a precision constraint set by operations capacity.

Evaluation: - Primary: Recall @ a precision threshold (e.g., recall @ precision=0.70). - Secondary: AUC-PR (precision-recall curve, more informative than ROC under severe imbalance). - NOT accuracy — useless here. - Use a time-based train/test split, never random shuffle (future can't inform past).

Deployment: - Serve model behind an API with <50ms p99 latency. - Hard rules layer (block known bad IPs/cards) runs before model for speed. - Soft score: route score > threshold to manual review queue.

Monitoring: - Fraud rate over time, false positive rate (customer complaint rate). - Feature drift alerts. - Retrain trigger when precision-recall curve degrades by >5%.

Q12. Case: A food delivery app's average delivery time has increased from 32 minutes to 38 minutes over the past month. How would you investigate?

Show answer

This is a metric movement investigation. Structure: Decompose → Hypothesise → Validate → Recommend.

Decompose the metric: - Break delivery time into components: order preparation time + pickup wait time + travel time + handoff time. - Which component increased? Segment by: city, time of day, restaurant category, driver type (new vs veteran), order size. - Is this a data issue? Check for instrumentation changes, timezone bugs, null values counted as zero.

Segment to find where: - If only one city: local operational issue (driver shortage, new restaurant partner with slow kitchen). - If only evenings: capacity constraint during peak hours. - If all segments uniformly: systemic cause (new routing algorithm, platform change).

Hypothesise root causes: - Supply side: fewer drivers available (competitor app launched, incentive changes). - Demand side: order volume spike (marketing campaign) without supply increase. - Restaurant side: new restaurant partners with longer prep times pulling up the average. - Algorithm: routing change, or a model update that de-prioritised speed. - External: weather events, construction, road changes in key markets.

Validate: - Cross-reference the timing of the increase with product releases, operational changes, and external events. - Pull driver availability stats: were there fewer active drivers? - Check restaurant prep times by category.

Recommend: - If driver shortage: adjust incentives, expand driver pool. - If restaurant onboarding: add prep-time estimation to the ranking model. - If routing: A/B test rollback of the algorithm change.

Always quantify: "the restaurant prep time component increased by 4 minutes on average, accounting for 67% of the total increase."

Self-Scoring Rubric¶

After completing the session, rate yourself on each question:

Score	Meaning
9–10	Answered without hesitation, covered all key points, added nuance
7–8	Covered the main points but missed 1–2 details or needed a moment
5–6	Got the concept but explanation was incomplete or imprecise
3–4	Knew the term but couldn't explain it clearly
1–2	Drew a blank or gave a significantly wrong answer

Anything below 7: add it to a "revisit today" list. Re-answer it out loud 24 hours later.

The Real Signal

Interviewers can tell when you've practiced. The filler pauses, hedging language ("I think maybe..."), and circular explanations give it away. Record yourself answering one question. You will immediately hear what to improve.