01Owns
Problem framing
Turns a business goal into a target variable, a prediction horizon and a cost of being wrong, and says when a simple rule will beat a model.
Hire · Machine learning
Hire Data Scientists
Senior data scientists who join your team to frame prediction and inference problems, pick sensible models and prove they hold up on data they have never seen. Each candidate has worked through a paid exercise built around a leaky dataset, a misleading baseline and an experiment that needs a proper power calculation.
Exercise built around hidden leakage
Senior, lead and principal levels
Pairs with your engineers on deployment
On your team
What a data scientist owns on your team.
02Owns
Validation design
Chooses time-based, grouped or stratified splits that match how the model will be used, so offline scores mean something in production.
03Owns
Feature work
Builds features from your event and transaction data while checking that nothing used at training time would be unavailable at prediction time.
04Owns
Experiment design
Sets sample sizes, picks the unit of randomisation, plans variance reduction such as CUPED and decides in advance what result would change the plan.
05Owns
Model hand-off and monitoring
Agrees input contracts, thresholds and drift checks with engineers, and keeps evaluating the model after launch against fresh labels.
A validation score is only as good as the split
The most common way a data science hire goes wrong is a model that looks excellent offline and disappoints in production. Usually the cause is not the algorithm but the evaluation: a random split on data where the same customer appears on both sides, or a feature computed with information from the future. Interview for that instinct directly.
Ask candidates how they would validate a model predicting next month’s demand. A strong answer mentions time-ordered folds, a gap between training and test periods and what to do about promotions or holidays the training window never saw.
Vetting
Skills we test before a data scientist joins.
01Tested
Model selection
Starts with linear and gradient-boosted baselines, knows when deep learning earns its cost, and explains the choice in terms of data size and interpretability.
02Tested
Leakage detection
Spots target leakage, train–test contamination across users or time, and preprocessing fitted on the whole dataset before splitting.
03Tested
Statistics for decisions
Power analysis, multiple comparisons, heterogeneous effects and the difference between statistical and practical significance.
04Tested
Evaluation beyond accuracy
Calibration curves, precision–recall under class imbalance, cost-weighted thresholds and slice metrics for groups the business cares about.
05Tested
Python modelling stack
pandas or Polars, scikit-learn pipelines, LightGBM or XGBoost, and reproducible experiments tracked in MLflow or a similar tool.
06Tested
Causal reasoning
Recognises confounding in observational data and can apply difference-in-differences or matching when a randomised test is impossible.
Work sample
How the data scientist work sample runs.
- 01Step 1
Find the leak
The candidate receives a churn dataset where one feature is recorded after cancellation. They must notice the suspiciously high score, find the cause and rebuild the split.
- 02Step 2
Beat an honest baseline
They train a model against a simple heuristic, report calibrated metrics on a time-based holdout and justify the decision threshold. The exercise is paid.
- 03Step 3
Plan an experiment
Given a baseline conversion rate and a minimum effect worth detecting, they size the test, pick the randomisation unit and list the guardrail metrics.
- 04Step 4
Defend a trade-off
A conversation with a product manager about why a slightly less accurate but explainable model might be the better launch choice.
Levels
Data Scientists: what changes at each level.
01Level 1
Senior
Owns models for one product area from framing to monitoring, and reviews colleagues’ notebooks and validation choices.
02Level 2
Lead
Sets evaluation standards, experiment policy and the modelling roadmap, and decides which problems deserve a model at all.
03Level 3
Principal data scientist
Shapes company-wide methods such as causal inference, forecasting or ranking, and advises leadership on where machine learning will and will not pay back.
Which level fits your organisation
A senior data scientist suits a team with clear problems and some data infrastructure already in place. A lead is the better choice when several modelling ideas compete for attention and nobody is deciding which ones are worth the effort. A principal is for companies where models drive core revenue, such as pricing or ranking, and methodology itself needs an owner.
Other options
When to hire someone other than a data scientist.
01Consider
Your questions are descriptive
If leadership mainly needs trustworthy dashboards, funnels and test readouts, a data analyst delivers faster.
Open register02Consider
You are building on large language models
Retrieval, prompting and LLM evaluation are a distinct craft; hire a generative AI developer for that work.
Open register03Consider
The model exists but cannot ship
If the blocker is packaging, APIs and serving rather than modelling, a Python developer is the hire.
Open registerPrefer the simple model until it loses
Experienced data scientists start with a baseline that a stakeholder could compute in a spreadsheet, then a regularised linear model, then gradient boosting. Each step must earn its place. A candidate who jumps straight to a neural network on a few thousand rows is signalling enthusiasm over judgement.
Setting up the first quarter
Give the new hire one problem with labelled history and a business owner who will use the result. Ask for a short framing document before any modelling: the target, the decision it supports, the evaluation plan and what success would be worth.
Schedule a review with engineering before training starts, not after. Agreeing which features are available at prediction time and how fresh they are prevents the most expensive rework.
FAQ
Questions to resolve before the build.
01How do you check a data scientist understands leakage?
The work sample hides it. Candidates who accept a near-perfect validation score without questioning it do not progress; those who trace it to a feature recorded after the outcome do.
02Will a data scientist put models into production?
They own the model, its evaluation and its monitoring plan, and they work closely with engineers who own the serving code. Some senior candidates do both, and we say so on the shortlist when they do.
03Do your data scientists work with deep learning?
Several do, mostly for vision, text and ranking problems. For tabular business data we expect them to justify anything beyond gradient-boosted trees with evidence from a fair comparison.
Works alongside
Roles a data scientist works best alongside.
01Pair with
Data analysts
Analysts maintain metric definitions and reporting, freeing the data scientist to focus on prediction and causal questions.
Open register02Pair with
Python developers
To wrap a validated model in a production service with tests, versioning and an API.
Open register03Pair with
DevOps engineers
For scheduled retraining jobs, GPU or batch infrastructure and alerting on model health.
Open registerPrimary sources
References behind this page
Dated official documentation, standards, and research that support the factual claims on this page.
- 01scikit-learn: Common pitfalls and recommended practices
Official guidance on data leakage and inconsistent preprocessing.
- 02scikit-learn: Cross-validation
Reference for grouped, stratified and time-series split strategies.
How to read this page
Scope, cost and timeline figures are planning guidance until confirmed in a written proposal. Diagrams and screens are illustrations, not client deliverables, and source-code rights and handover follow the signed agreement. See the delivery process and the full disclaimer.
Next decision
Turn the brief into an accepted product scope.
Define outcomes, constraints, evidence, rights and handover before delivery begins.
Commercial rights, repositories, environments, documentation, acceptance and handover remain contract-defined.