Data Scientist Interview Questions

Supervised learning uses labelled data to train a model to predict an output, a class or a value, from input features. I use it when I have a clear target variable and enough labelled examples: churn prediction, price estimation, image classification. Unsupervised learning finds structure in data without labels. I reach for it when I want to discover patterns I have not defined in advance: customer segmentation with k-means, topic modelling with LDA, or anomaly detection where I do not have labelled examples of fraud. In practice, many projects combine both. I might use unsupervised clustering to identify customer segments and then build a supervised classifier to label new customers into those segments in real time. The decision always starts with the business question and the data I have available, not with picking a favourite algorithm.

I start with exploratory data analysis before touching any modelling code. I check the shape and schema, then look at missing value rates per column and decide whether to impute, drop, or flag them. I examine distributions for numeric features: skewness, outliers, and whether the scale differs wildly across columns. For categorical features I check cardinality and whether any categories appear only in the test set. I also look at the target variable distribution early: class imbalance in a classification problem changes almost every decision downstream. I cross-tabulate key features against the target to build a mental model of what signal exists before I write a single line of sklearn. I document findings as I go so colleagues can follow my reasoning. This phase typically saves far more time than it costs by catching data quality issues before they corrupt a model.

Overfitting happens when a model learns the training data so closely that it captures noise rather than the underlying pattern, and performance degrades on new data. I detect it by comparing train and validation metrics side by side: a big gap between training accuracy of 97% and validation accuracy of 81% is a clear signal. To prevent it, I use cross-validation rather than a single train-test split, which gives a more reliable estimate of generalisation. For tree-based models I tune max depth, min samples per leaf, and use early stopping in gradient boosting. For neural networks I apply dropout and monitor validation loss to stop training before it starts climbing. Regularisation, L1 or L2, helps with linear models. I also keep feature count in check: adding noisy features consistently makes overfitting worse, so I use feature importance scores and permutation tests to prune the input space.

I built a customer churn model for a subscription product and needed to present the results to the marketing and customer success leadership team. The model used a gradient boosted classifier with around 40 features, which I knew would mean nothing to them. I stripped the technical detail entirely from the slides. Instead I focused on three things: what the model predicts, how confident we should be in it based on precision and recall on held-out data, and, most importantly, what it meant for their decisions. I presented the top five churn risk drivers as plain-English statements: customers who had not logged in for 21 days and had not used the reporting feature were 4.2 times more likely to churn within 30 days. The team immediately saw which customer segments to prioritise for outreach. Questions were about strategy, not methodology, which told me the communication had worked.

I built a propensity model to predict which free-tier users would convert to a paid plan within 60 days. After training on six months of data the AUC on the validation set was 0.71, which seemed reasonable, but when we ran a live test for four weeks the precision was far lower than expected: we were flagging too many false positives. I did a post-mortem and found two issues. First, the training data had a label leakage problem: one of the features included an in-app upgrade prompt click that technically happened just before conversion, meaning the model had learned from a signal that would not be available at prediction time. Second, the class imbalance was more severe in the live population than in the training window I had used. I rebuilt the model after removing the leaky feature and rebalancing with SMOTE. The live AUC improved to 0.79 and precision at the top decile rose from 31% to 58%.

After building a real-time fraud detection model in Python, I worked with two backend engineers to get it into production. The first challenge was that I had built the model in a Jupyter environment and the feature engineering pipeline was not reproducible outside it. I spent two days refactoring the preprocessing code into a proper Python module with unit tests so engineering could integrate it confidently. We agreed on an API contract: the model would receive a JSON payload and return a score between 0 and 1 with a response time under 50ms. I containerised the model with Docker and we used a shadow deployment to route 10% of live traffic to the new model alongside the rules-based system already in production. We monitored prediction distribution and latency for two weeks before cutting over fully. The shadow period caught one edge case where a missing field caused a null prediction, which we handled with a fallback score.

I start by asking what the cost of each type of error is in the business context, because accuracy alone almost never tells the full story. For fraud detection, a false negative (missed fraud) is far more expensive than a false positive (a legitimate transaction flagged for review), so I weight recall heavily. For a lead scoring model where sales capacity is limited, precision matters more: I want the leads we do call to be high quality. When classes are imbalanced, accuracy is especially misleading. I use the AUC-ROC curve to compare models in a threshold-independent way, and the precision-recall curve when the positive class is rare. For the final operating threshold I look at the F-beta score and pick a beta that reflects the business trade-off. I also track calibration: a model that says "70% probability" should be right about 70% of the time, which matters when the score is used to set thresholds or communicate confidence to stakeholders.

Feature engineering is often where the most value is created, and I treat it as a continuous process rather than a one-time step. I start with domain knowledge: what does a human expert think predicts the outcome? That gives me a fast starting set. Then I look at the raw features and create derived ones: ratios, rolling averages over different time windows, time since last event, and interaction terms between features that business logic suggests might matter together. For text data I use TF-IDF or embeddings depending on whether the task needs semantic similarity. I validate each feature by measuring its importance in a baseline model and running permutation tests to confirm it adds signal rather than noise. I also check for multicollinearity: highly correlated features can destabilise some models and make interpretation harder. Feature stores have changed how I work in team settings: reusing engineered features across models prevents duplication and reduces training-serving skew.

The gap between a working notebook and a reliable production model is significant and worth planning for from the start. I begin by writing the feature pipeline as clean, testable Python rather than notebook cells so that the same preprocessing code runs identically at training time and inference time. This prevents training-serving skew, which is one of the most common sources of silent model degradation. I version the model artefact and the feature pipeline together using MLflow or a similar tool so I can reproduce any past prediction. I define monitoring requirements before launch: I want to track input feature distributions, output score distributions, and actual-versus-predicted performance on labelled feedback data as it arrives. I set alerting thresholds for data drift using statistical tests like the Kolmogorov-Smirnov test. I also document model assumptions, known failure modes, and the population the model was trained on, because that information is critical when an engineer has to diagnose an issue six months after I have moved on to a different project.