Most teams asking for a data scientist need a data engineer first.
A data scientist working on unreliable, undocumented, half-joined data spends their first six months doing plumbing badly and their seventh explaining why there are no results yet. We will tell you if that is where you are.
- 01First questionIs the data ready?
- 02ThenIs the question answerable?
- 03OutputA decision, not a notebook
- 04EngagementMonthly rolling, 30 days notice
- 05InterviewYou meet them, you can decline
- 06Overlap4–6 hours with US and EU
Data scientist, or data engineer?
These titles are used almost interchangeably in job adverts and describe different people. Hiring the wrong one is the most common way a well-funded analytics programme produces nothing for a year.
You need one if
- Nobody agrees what the numbers mean
- The same metric differs between two reports
- Joining two systems is a manual, monthly job
- “The data is in the warehouse” is not quite true
- Analysis starts with three weeks of cleaning, every time
- There is no lineage, nobody can say where a figure came from
You need one if
- The data is reliable and the question is open
- You need to know whether a difference is real or noise
- A prediction would change a decision somebody makes
- Someone has to say what accuracy would count as good enough
- An experiment needs designing, not just measuring
- The honest answer might be “this is not predictable”
The modelling is the smallest part, and the easiest to buy.
Fitting a model is close to commodity. The libraries are excellent, the tutorials are good, and a competent engineer can produce something that scores well on a holdout set within a week.
What is not commodity is deciding what should be predicted, establishing whether the historical data can support predicting it, choosing a metric that corresponds to a business consequence, and recognising when the honest answer is that the signal is not there.
That last one is the test. A data scientist who has never told a stakeholder that their hypothesis is not supported has either been extraordinarily lucky or is not looking hard enough, and we ask about it directly.
The second half of the job is delivery. A model that lives in a notebook has produced no value, and the gap between an experiment and something running against live data with monitoring is where most analytics investment quietly disappears. We screen for people who have crossed it.
What we ask a data scientist.
Technique is table stakes and easy to verify. Judgement is what you are buying, and it takes different questions to find.
Tell us about a result you had to walk back.
Everyone who has done this work seriously has had one. How they handled it (and how quickly they mention it) tells you more than any methodology question.
How did you choose the metric?
We are listening for a link between the metric and a decision someone makes. Accuracy chosen because it is the default is a bad sign on an imbalanced problem.
What did the baseline look like?
Strong candidates establish a trivial baseline before modelling. It is the cheapest way to find out that a problem does not need machine learning.
How did it get into production?
Separates people who have shipped from people who have analysed. Both are useful; you need to know which one you are hiring.
What would have changed your conclusion?
Tests whether the analysis was falsifiable or whether it was assembled to support a position somebody already held.
Explain it to a sceptical finance director.
Communication is not a soft skill in this role. An unexplainable result does not get acted on, which makes it worth nothing.
Six things we check about your data.
We run this before quoting, because the answers change what we would staff and occasionally change our advice to “not yet”. It takes a conversation instead of a project.
- Is there enough history, and is it stable? A dataset that changed definition eighteen months ago has eighteen months of usable history, whatever the row count says.
- Is the outcome recorded? Supervised learning needs labels. A surprising number of prediction projects discover that the thing to be predicted was never systematically captured.
- Do the joins hold? Whether records can be reliably linked across systems is usually the difference between a month of work and a quarter.
- Does anyone agree what the metrics mean? Two definitions of “active customer” in one organisation is normal and has to be resolved by people, not by code.
- Would a prediction change a decision? If nobody would act differently, the correct recommendation is to spend the money elsewhere, and we will make it.
- Who owns the pipeline afterwards? A model with no owner degrades silently. This needs answering before it is built, not after it drifts.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring data scientists.
Answered as we would answer them on the first call.
How do we know if we are ready for a data scientist?
The clearest test is to ask how long the last piece of analysis took and where the time went. If most of it went on finding, cleaning and reconciling data, you have an engineering problem and a data scientist will spend their time on it too, less happily and at a higher rate. If most of it went on the analysis itself, and the argument was about interpretation, not about whose number was right, you are ready. The middle case is common and the right answer there is usually one of each for a period, with the engineer starting first.
Do we need someone with domain experience in our sector?
Less than people expect, and it is often the wrong thing to optimise for. Domain knowledge is learnable in weeks by someone with good judgement and access to the people who have it; statistical judgement is not learnable in weeks by anyone. What matters is whether the candidate asks good questions about a domain they do not know, which we test directly by giving them an unfamiliar problem in the interview. Where domain experience does matter is heavily regulated work, where knowing what cannot be used as a feature is a compliance question rather than a modelling one.
Should the data scientist sit with our team or work as a separate unit?
With your team, without much room for debate. Data science done at a distance produces technically sound work that answers a slightly different question from the one the business is asking, and the gap is usually only discovered at the presentation. Our engineers work inside your rituals (your stand-ups, your planning, your channels) and we would push back on an engagement structured to keep them separate, because we have seen how those end. If you want a piece of analysis delivered at arm's length, that is a different and smaller engagement, and it should be scoped as one.