More data science hires fail on definition than on capability. The title covers at least three jobs, a company usually wants one of them, and the advert describes all three — so the shortlist contains people who are excellent at something other than what was needed.
Around 117 British employers are advertising for one as we index them, which makes this the deepest market on this site. Plenty of candidates, then. The difficulty is knowing which you are looking at.
Three jobs, and the one you probably want
Write down what the person will have produced in six months before you write anything else.
The analyst. Answers questions with data: why revenue moved, which cohort is churning, whether the change worked. Mostly SQL, mostly communication, enormously valuable and frequently what a company actually needs when it says it wants data science.
The modeller. Builds predictive models and hands them to somebody else to deploy. Statistics, experimental design, feature work. This is the closest to the classical definition of the title.
The engineer. Builds and ships models into production themselves. Genuinely a software engineering role with statistics attached, and if this is what you want, the machine learning engineer guide describes it more honestly than this one does.
Most organisations at the start of this need the first. Most adverts describe the third. That mismatch is the single most common reason a data science hire disappoints everybody within a year.
The stakeholder half is the job, not an adjunct
This is the part that separates people who deliver from people who produce notebooks, and it is very hard to screen for with technical questions.
The work consists of taking a vague commercial request — “can we predict which customers will leave” — and turning it into something answerable: what counts as leaving, over what period, using data that exists at the time the prediction is needed. Then, frequently, explaining to somebody senior that the answer is not the one they were hoping for.
So ask about a project where the result was unwelcome. What was it, who did they tell, and what happened? Strong candidates have several and describe them without drama. Somebody who has never delivered bad news has either been lucky or has been rounding their conclusions toward what was wanted, and the second is more common.
Defining the target variable, which is where projects go wrong quietly
Ask how they decided what to predict. It sounds procedural and it is the most consequential decision in most projects.
The examples are everywhere once you look. Churn for a subscription business is a cancellation date; for a retailer with no contract it is an arbitrary definition somebody has to choose, and the choice changes the model, the metric and the business meaning entirely. Fraud is what was confirmed, which is not what occurred. Lead quality is what the sales team logged, which reflects the sales team’s behaviour as much as the lead’s.
A candidate who interrogates the target definition before discussing methods has done this for real. One who accepts the label column as given will build something technically sound that answers a question nobody asked.
Screening questions that survive a competitive market
With this much supply you can afford to be specific. Four that sort a large field quickly:
- “How did you know your result was not an artefact?” You want the leakage conversation, the validation scheme, and ideally a story about a result that looked wonderful and was not.
- “What did you decide not to model?” Knowing that a question is better answered with a query, a chart or a conversation is a senior instinct.
- “Walk me through a dashboard you built that people actually used.” Adoption is the test. Plenty of analysis is admired and ignored.
- “What is in your SQL repertoire?” Unfashionable and revealing. A great deal of real work is window functions and careful joins, and candidates whose experience is entirely in notebooks over extracted CSVs struggle badly with production data.
Where this role genuinely does not work remotely
Worth being direct, because it is the one recommendation on this site that runs against our own interest.
If the role is principally the stakeholder work described above, it depends on shared context, informal conversation and being present when decisions are made. Across a significant time difference and a second language, that erodes first and fastest — not because of capability but because the job is largely made of the things distance removes. We would rather say so than place somebody into a role that frustrates everyone by month three.
Where the work is genuinely technical — modelling, causal inference, experiment design, large-scale analysis — distance matters much less and the answer changes. So split the role if you can. If you cannot, and the stakeholder half dominates, hire locally.
What it costs, and the seniority question underneath
Indicatively £45,000 to £65,000 for somebody one to three years in, £65,000 to £90,000 at mid level, and £90,000 upwards for genuine seniority, with London and financial services above that. Day rates from about £400.
The wide band reflects a real phenomenon: the title is applied to graduates and to people running functions, so a candidate pool for “data scientist” spans a decade of experience. Filter on the outcome you defined at the top of this page rather than on the years, and be sceptical of seniority claimed on the basis of technique breadth rather than delivered results. The most useful question remains what changed in the business because of their work.