Data scientist job description

The market is full of people who can build a model and short of people who will tell you a model is the wrong answer. That second judgement is worth more to a company building this function for the first time, because the expensive outcome here is not a weak model. It is two quarters spent producing something accurate that nobody could act on. Below is a description you can post, and the screening that goes with it.

The job description

We are looking for a data scientist who takes a business problem through to a decision, including the cases where the decision is that no model is needed. You will work close to the teams whose behaviour changes because of the work.

What you will own

Problem framing with the business owner, including what a better answer is actually worth
The data: what exists, what it really measures, and what is missing
A baseline before anything sophisticated, and an honest comparison against it
Deployment, monitoring and the retraining plan for anything that goes live
Measurement design, agreed before the work starts rather than after the result

What the job needs

Statistical grounding you can explain rather than recite
Something you built that ran on live data and had to be maintained afterwards
Engineering habits solid enough that your work can be handed to somebody else

Signals we weight heavily

You have argued against building a model
You can describe how a live model degraded and what you did
You have designed a holdout that could have proved you wrong

What a data scientist is actually accountable for

Modelling technique is abundant and easy to test for. What is scarce is judgement about whether the problem is a modelling problem at all, and ownership of the thing once it is live and the world has moved.

Deciding whether a problem needs a model, and saying so clearly when it does not
Turning a business outcome into a label something can learn, and being explicit about what that definition throws away
Getting something into production that changes a decision somebody makes
Measuring uplift in a way that could have shown the work did not help
Noticing a live model has drifted before somebody in the business notices for them

Four ways a data scientist hire looks right and is not

Every one of these passes a resume screen. Ladders eye-tracking study timed the average initial scan at just 7.4 seconds, which is long enough to check the four signals below and not long enough to check anything that would contradict them.

Looks right

Strong competition rankings and public leaderboard finishes

Competitions hand you a cleaned dataset, a fixed target and a scoring metric chosen by somebody else. Every difficult part of the commercial job has already been removed: defining the label, finding the data, deciding what a false positive costs the business. It is real evidence of modelling skill and no evidence of judgement.

Looks right

A doctorate and publications in machine learning

Research optimises a benchmark. The job optimises a decision under constraints on latency, data quality and who will maintain it. A publication record proves they can move a metric on a well-defined problem. It does not predict whether they will notice that the model does not need to exist.

Looks right

Deep learning and large-model projects across the resume

Most commercial problems are settled by a well-specified baseline and clean features, and the person who reaches for the largest available approach first will produce something impressive that cannot be maintained. Ask what the simplest thing they ever shipped was, and whether it beat what came after it.

Looks right

Notebooks with strong offline metrics

An offline score is not a result, it is a hypothesis with good manners. The question is whether anything they built ran against live data for six months and what happened to it as inputs shifted. Plenty of data science careers contain no answer to that at all.

What to ask for evidence of instead

Four questions, and what the answer actually tells you. Take these into your own process whether or not you ever talk to us.

Tell me about a problem where you concluded that a model was the wrong answer.: What it tells you: The single most valuable habit in a first data science hire, and the rarest. Candidates who have never reached that conclusion have either had unusually good problems or have never been the one deciding what to work on.
Take me from a business metric to a label. How did you define the target, and what did you have to throw away?: What it tells you: Where most commercial modelling actually fails. Listen for the compromises: the events they could not observe, the delay between action and outcome, the population they had to exclude and what that did to the result.
Which of your models reached production, and what did it look like a year later?: What it tells you: Separates project work from ownership. The good answer includes drift, a retraining decision, or a deliberate retirement. Nobody who has maintained a live model describes it as finished.
How did you measure whether it worked, and what result would have made you say it did not?: What it tells you: Holdout discipline, stated before the fact. Data scientists who only ever report improvement have usually been measuring after choosing what to measure, which is the most common way a project survives longer than it deserves.

How Continuity1 runs this funnel

The screening above is the job. These are the numbers it produces when a function owns it end to end, set against the published benchmarks for the same market.

1 in 3: Shortlisted candidates you meet who become the hire; Aligned engagements run nearer 1 in 2, distant ones nearer 1 in 10. The market takes about 180 applicants to make one hire, and that sifting lands on your team rather than ours.; Continuity1 tracked engagements
~3: Interviews your team sits in, per hire; Ashby puts technical roles at 17.6 interviews per hire across the whole process, up 52% since 2021. The rest of that load sits with the function, not with you.; Ashby talent-trends report
1 in 9: Accepted offers that ghost before joining; Indian employers report nearly 4 in 10 offers dropped. We lose 1 in 9.; nasscom community
95%: Offers that close inside your stated band; 20 of the last 21. A flat fee earns nothing from an inflated offer; a percentage of CTC earns more.; Continuity1 tracked engagements

Every brief becomes a success profile before sourcing starts, calibrated with the people who will manage the role. That calibration is the step most hiring skips, and it is why a shortlist either matches the job or matches the job advert.

You review a scored shortlist and make the calls. The filtering never lands on your calendar.

Share a role See the workings and the citations

Questions teams ask

Data scientist, data analyst or machine learning engineer?

An analyst answers questions with data. A data scientist frames a problem and builds something that predicts or decides. A machine learning engineer makes that run reliably at volume. Most companies hiring their first data scientist actually need the analyst, and discover it after two quarters of dashboards produced by somebody hired to model.

Do we need a PhD for this role?

Only where the work is genuinely novel research. A doctorate demonstrates the ability to push a metric on a defined problem over a long horizon. The commercial constraint is different: an answer that is good enough, ships, gets maintained, and can be explained to whoever will be held responsible for acting on it.

Take-home or case interview?

A case discussion built on a real problem from your own business tells you more, faster, and costs the candidate an hour. Give them the messy version with the data you actually have, and watch whether they ask what decision this feeds before they ask what the data looks like.

Are we ready to hire one?

If the data is unreliable and nobody owns the pipelines, a data scientist will spend the first year building them and doing a job you did not hire for. That is the most common way this hire fails, and it fails quietly, because the work looks productive the whole way through.