Hiring a data scientist is a procurement decision dressed as a technical one. The maths is the easiest part to test and the least likely to sink the hire; what sinks it is scoping, judgement, and the gap between a model that works in a notebook and a model the business can defend a year later. This guide covers the decision in order: whether you are ready to hire at all, what the day-to-day actually is, which credentials predict delivery, the interview questions that expose judgement, and what the market pays.
First question: are you ready to hire one?
A data scientist with nothing to work with is an expensive way to discover your data problems. Before writing the job description, check three prerequisites.
Is the data reachable and usable? Not perfect, but queryable, with someone who knows where the bodies are buried. If every analysis starts with three weeks of chasing access and reverse-engineering undocumented tables, the role you need first is a data engineer, and the hiring logic for that role is different enough that we wrote it up separately in how to hire a data engineer.
Is there a question backlog, or one big vague hope? “Use AI on our data” is not a backlog. Three concrete decisions the business makes repeatedly, where better prediction has a namable value, is. Without it, your new hire spends month one doing discovery you could have done in the interview process, and month four wondering what they were hired for.
Is there a path to production? A model that never leaves the notebook has the business value of a well-formatted opinion. If nobody on staff can deploy and monitor a model, either the data scientist you hire must carry that skill, which narrows the field and raises the price, or the plan needs an MLOps answer before the first model, not after.
What senior data scientists actually do all day
The public image of the role is modelling. The delivery reality, in an enterprise, is that modelling is the minority share of the week. The rest is scoping (“what are you actually trying to decide?”), data archaeology, stakeholder translation, and governance: documenting why the model makes the predictions it makes, in terms an auditor or a risk officer will accept.
That last part is worth dwelling on, because it splits the profession in two. Research-style data scientists optimise for model performance and novelty; delivery-style data scientists optimise for a defensible, maintainable model that survives contact with regulation and organisational reality. Both are real skills. Enterprises overwhelmingly need the second and interview for the first, which is one of the two structural reasons these hires disappoint. The other is hiring the role before the prerequisites above exist.
Seniority in this role, which at Mahala means five to six years of production experience minimum, shows up as restraint: choosing the boring model that the team can operate, knowing when a well-built SQL query answers the question without any model at all, and being able to say “the data cannot support that conclusion” to someone senior who wanted the opposite answer.
Credentials: what predicts delivery and what does not
A PhD predicts research ability, tolerance for ambiguity, and depth in one area. It does not predict production judgement, and for delivery-focused roles it should be treated as one signal among several rather than a filter. Some of the strongest delivery data scientists come from adjacent quantitative fields with years of applied work; some struggle most with shipping something imperfect on a deadline.
Kaggle rankings prove modelling skill under leaderboard conditions: a clean dataset, a fixed metric, unlimited attempts. Production offers none of those conditions. Respect the skill, and then ask what the candidate has shipped where the dataset was dirty and the metric was contested.
The signals that hold up on a CV: models that ran in production for years with the candidate accountable for them, a named business outcome with a number attached and the candidate’s actual role in it stated honestly, experience presenting to non-technical decision-makers, and regulated-industry tenure, because model risk management in a bank teaches documentation discipline nothing else does.
When you take references, skip “were they good” and ask: what happened to the model after they left? Models that die the week their creator leaves were never production models; they were personal projects with a corporate login.
Interview questions that expose judgement
Technical screens verify the floor. These find the ceiling:
“Tell me about a model you built that never made it to production, and why.” Everyone senior has one. Candidates who blame stakeholders for all of them are telling you how they will describe your team in three years. The best answers include a failure they now attribute to their own scoping.
“Here is a business problem, deliberately vague. Scope it.” Use a real one. Listen for whether they ask what decision the model would change, what the cost of a wrong prediction is in each direction, and what the baseline is today. A candidate who starts naming algorithms in the first five minutes has answered the question, just not in the way they intended.
“How would you explain this model’s rejection of a loan applicant to a regulator?” Or the equivalent in your domain. This tests whether interpretability is something they practise or something they mention.
“Your model’s performance degraded three months after deployment. What are the suspects?” Drift in the input distribution, a broken upstream pipeline, a feedback loop the model itself created, a seasonal effect nobody encoded. Candidates who have operated models list suspects in order of likelihood; candidates who have not, list whatever they read most recently.
“What is the strongest result you have shipped, and what was wrong with it?” Senior people know exactly what was wrong with their best work. The absence of an answer is an answer.
For the practical component, prefer a structured take-home on a realistically messy dataset with a business framing, timeboxed and paid if substantial, over live-coding under observation. You are hiring for judgement across days, not composure across 45 minutes.
How Mahala screens: evidence first, consulting fit second
The pattern behind most failed data science hires is a one-dimensional process: the technical screen went well and nobody tested anything else. Mahala’s protocol scores four things: technical acumen, demonstrated impact, consulting aptitude, and professional growth, against a 75/100 pass mark, with claims cross-checked against references rather than taken from the CV. The category that most often catches a notebook-brilliant candidate is consulting aptitude: whether they can scope an ambiguous request, defend a trade-off in front of stakeholders, and carry accountability inside a regulated team. One in seven clears the bar. Catching the consulting gap before the contract is the point of the design.
What a senior data scientist costs
In the UK contract market, the median day rate for data scientist contracts was 600 pounds in the six months to August 2026, up 14 percent year on year, per ITJobsWatch. The direction matters as much as the level: demand for the delivery-capable end of the profession is repricing it. Rates run higher with deployment skills attached, with regulated-industry experience, and in scarce specialisations such as NLP and computer vision, and they vary across EU and GCC markets.
Set against that: a mis-hire in this role typically takes six months to become undeniable, because the early output (analyses, decks, promising prototypes) looks like progress. The expensive failure is not the salary; it is the two quarters of roadmap built on work that never reaches production.
When a specialist network is worth it
If you have a senior data science lead who can run the process above, run it. If you do not, you are asking your process to evaluate a skill nobody in the room has, and the polished candidate beats the capable one more often than anyone likes to admit.
Mahala exists for that situation: pre-vetted remote senior Data Scientists, assessed on production evidence and consulting capability before you ever see a CV. First response within 24 hours of a brief, a shortlist of two to three blind CVs within 72 hours, blind so the evidence decides. What the discipline covers end to end is on our data science page.
