What is the difference between supervised and unsupervised learning, and when would you use each?

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.

How do you approach a new dataset before building any model?

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.

What is overfitting, and what techniques do you use to detect and prevent it?

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.

Tell me about a time you had to explain a model or its findings to a non-technical audience.

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.

Describe a model you built that did not perform as well as expected. What did you do?

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%.

Tell me about a time you worked with an engineering team to deploy a model to production.

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.

How do you choose evaluation metrics for a classification problem?

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.

Walk me through how you approach feature engineering.

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.

How do you think about productionising a model, from notebook to live system?

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.

Data Scientist Interview Questions

Data Scientist

Data Scientist interviews go well beyond SQL and dashboards. Interviewers expect you to discuss model selection, feature engineering, evaluation metrics, and what happens after a model is built. This guide covers the questions that come up most often and gives you concrete, specific answers to practise with.

What Hiring Managers Look for in Data Scientist Interviews

What hiring managers really look for in Data Scientist candidates:

Production mindset, not just notebook thinking. Candidates who understand training-serving skew, monitoring, and model versioning stand out from those who stop at model accuracy.
Honest handling of failure and uncertainty. The best data scientists talk clearly about models that did not work and what they changed. Candidates who only describe successes are a red flag.
Business context first. Strong candidates connect every technical choice (metric selection, feature engineering, threshold setting) back to a business outcome, not just a benchmark score.
Communication with non-technical stakeholders. The ability to translate model output into decisions that a marketing or finance team can act on is what separates impactful data scientists from those who live only in notebooks.
Awareness of data quality issues. Candidates who mention label leakage, class imbalance, and training data drift early in their answers have seen real production data.

Questions to Ask Your Interviewer

→What does the model deployment process look like here: who owns productionisation, the data science team or engineering?

→How mature is the data infrastructure? Do you have a feature store, or is feature engineering done per project?

→What does the feedback loop look like for models already in production: how do you monitor for drift and degradation?

→What is the balance between building new models and maintaining and improving existing ones?

→How does the data science team collaborate with product and business stakeholders when defining what to work on next?

Data Scientist

Common Data Scientist Interview Questions

Behavioral Interview Questions for Data Scientist Roles

Technical Questions for Data Scientist Candidates

What Hiring Managers Look for in Data Scientist Interviews

Questions to Ask Your Interviewer

Practice These Questions Before Your Interview

Related Roles