What Should You Look for in a Data Scientist for an ML Project?

Gartner’s forecast is the number worth starting with, because it reframes the whole hiring question:

Through 2026, organisations will abandon 60% of AI projects because they aren’t supported by AI-ready data. 

Read that carefully. The projected cause of failure is not model architecture. It is not a GPU budget. It is the state of the data and the discipline of the people handling it. Which means the decision that most determines whether your ML project ships is made months before any model is trained  at the point where you decide who to bring in and what you screen them for.

Most teams get this backwards. They write a job description that reads like a Coursera syllabus  Python, TensorFlow, deep learning, NLP  interview against it, hire a strong modeller, and then spend the next four months watching that person negotiate with a data warehouse nobody has documented. Six months in, there’s a notebook with 0.91 AUC and nothing in production.

The gap is not talent supply. India’s AI talent pool is growing fast: Deloitte and Nasscom project demand rising from 600,000–650,000 professionals to over 1.25 million by 2027. There are plenty of people who can build a model. The scarcity is in people who can decide whether a model is the right answer at all, get to a defensible baseline in two weeks, and hand something to engineering that survives contact with real traffic.

This guide is the vetting playbook for that. It covers what the role actually is, where it ends and machine learning engineering begins, the exact skills checklist to screen against, the interview loop that catches the failure modes, real cost bands, contract terms specific to model IP, and what “on track” looks like at day 14, day 30 and day 90.

What Is a Data Scientist on an ML Project?

A data scientist on an ML project is the person who converts an ambiguous business problem into a measurable prediction task, establishes whether the available data can support it, builds and validates the model, and proves the result holds outside the training set. They own the question, the evidence and the model, not the serving infrastructure.

That definition matters because three adjacent roles get conflated with it:

• Not an ML engineer. An ML engineer owns deployment, serving, latency, retraining pipelines and inference cost. The data scientist decides what to predict; the ML engineer makes it run at scale, reliably, under a latency budget.
• Not a data engineer. A data engineer owns ingestion, warehousing, schema, orchestration and data quality contracts. A data scientist consumes that layer. If the layer doesn’t exist, a data scientist will build a fragile version of it and lose two months doing it.
• Not a BI or analytics professional. Analysts explain what happened. Data scientists estimate what will happen, and attach a confidence interval to it. Both are valuable; they fail differently and interview differently.

There is a fourth clarification worth making. A data scientist is also not an AI product manager. Deciding which use case is worth the investment, sequencing it against the roadmap, and holding the business case is a distinct job  and on projects under about eight people, it usually lands on the founder or product lead, not on the person building the model.

Why the Right Data Science Hire Decides Whether the Project Ships

The business case for getting this hire right is not abstract. It shows up in four measurable places:

• Time for the first defensible answer. A strong hire will tell you within 10–15 working days whether your data can support the prediction you want. A weak one will spend a quarter building toward an answer that was never available in the data  because they were never trained to check first.
• Sunk cost avoided. A mid-to-senior ML data scientist in India costs roughly ₹18–45 lakh/year fully loaded, or ₹2.5–5 lakh/month on a contract basis. A six-month dead-end therefore burns ₹15–27 lakh in salary alone, before counting cloud spend, engineering time and the opportunity cost of the roadmap slot.
• Rework in engineering. Notebooks handed over without tests, pinned dependencies or a documented feature definition typically cost an engineering team 3–6 weeks to reimplement. That rework is invisible in the data science budget and lands entirely on the platform team.
• Model risk exposure. In lending, insurance, hiring and healthcare, a model that can’t be explained is a model that can’t be defended to a regulator. Under India’s DPDP Act 2023 and GDPR, training-data provenance and purpose limitation are audit questions, not engineering preferences.

The compounding effect is what most cost models miss. McKinsey’s survey data shows the gap between adopting AI and getting bottom-line value is enormous. 88% of organisations use AI somewhere, but only around 39% report any enterprise-level EBIT impact. The organisations that close that gap aren’t the ones with better models. They’re the ones whose first hire insisted on defining the success metric in business terms before opening a notebook.

The single question that predicts hire quality: ask a candidate what business metric their last model moved, and by how much. Strong candidates answer in one sentence with a number and a caveat. Weak candidates answer with a model architecture.

The Core Problem: Everyone Hires for Modelling, Almost Nobody Hires for Everything Around It

Modelling is roughly 15–20% of the work on a typical applied ML project. Data understanding, cleaning, labelling logic, feature definition, evaluation design and stakeholder alignment are the other 80%. Yet the standard interview loop takes a take-home on a clean dataset, an algorithms round, a stats quiz  tests almost exclusively the 15%.

Here is what that mismatch produces, in the order it usually happens:

1. Weeks 1–4: access limbo. The new hire can’t get production data. Nobody scoped who owns the warehouse credentials, the PII masking policy or the sandbox environment. In our engagements, this is the single most common ramp-up blocker, and it is entirely preventable with a pre-start access checklist.
2. Weeks 4–8: the leakage honeymoon. Early results look extraordinary. A field in the training set encodes the outcome: a status flag updated after the event, a timestamp, a downstream ID. Nobody catches it because nobody was hired to be paranoid about it.
3. Weeks 8–16: the moving target. The business stakeholder, seeing early numbers, expands scope. The prediction task quietly changes three times. No decision log exists, so no one notices that the evaluation set no longer matches the deployment population.
4. Weeks 16–24: the handoff wall. The model works in a notebook. Nobody can serve it under 200ms, nobody knows how features will be computed at inference time, and the feature transformations exist only inside a .ipynb file with hard-coded paths.
5. Month 6+: quiet abandonment. The project doesn’t get cancelled in a meeting. It gets deprioritised, and the data scientist gets reassigned to dashboards.

The underestimate pattern: most first-time buyers underestimate the data-preparation and evaluation-design phase by 3–4x, and the production-handoff phase by 2–3x. If your plan says “model in six weeks,” the honest version of that plan is four to five months to a production system  unless your data layer is already mature, in which case eight to ten weeks is achievable.

None of this is fixed by hiring someone smarter. It’s fixed by changing what you screen for.

How to Hire Data Scientists for ML Projects: The Full Walkthrough

Six phases, in order. Skipping Phase 1 is the most expensive shortcut available to you.

Phase 1  Decide whether you need a data scientist at all

The machine learning hiring process should start with a disqualification test, not a job description. Teams that successfully hire data scientists for ML projects almost always run this filter before they write a word of the JD:

1. Is there a decision that changes based on the prediction? If no one will act differently, you need a dashboard, not a model.
2. Do you have labelled outcomes? For supervised problems, you need historical examples of the thing you want to predict, ideally 1,000+ positive cases for tabular classification, and far more for anything with high dimensionality.
3. Is the outcome observable within a useful window? Predicting 18-month churn when you have 11 months of data is not a modelling problem. It’s a data collection problem.
4. Would an off-the-shelf API solve 80% of it? OCR, transcription, translation, standard sentiment, generic document extraction  these are solved products. Buying beats building unless your data is genuinely unusual.
5. Is your data in one queryable place? If the answer involves joining four systems by hand, your first hire should be a data engineer.

The honest branch: if you fail items 2, 3 or 5, hire data infrastructure capability first. Bringing in a modeller ahead of a usable data layer is the ordering mistake that produces the 60% abandonment rate Gartner is forecasting.

If you pass, define the following before sourcing  this becomes the brief:

• The prediction target, in one sentence, with its unit and time horizon
• The business metric the prediction should move, and the current baseline value
• The decision threshold  what action is taken at what predicted probability
• The deployment surface  batch job, API, embedded in an existing service
• The latency and volume budget  50ms real-time, or nightly batch of 2M rows
• The hard constraints  explainability requirements, data residency, PII handling

Phase 2  Build the skills checklist and the seniority band

Now translate that brief into a role spec. The skills that matter are project-dependent, so screen in tiers rather than against a flat list. When teams hire data scientists for ML projects using a generic JD, they end up optimising for the wrong tier entirely.

Tier 1  non-negotiable for every ML project:

• SQL beyond SELECT *  window functions, CTEs, understanding of join fan-out
• Python with pandas, NumPy, scikit-learn; ability to write a function, not just a cell
• Applied statistics: sampling bias, hypothesis testing, confidence intervals, base rates
• Evaluation design: train/validation/test discipline, temporal validation for anything time-dependent, and active data leakage detection
• Baseline discipline  always establishing a naive or rules-based benchmark before modelling
• Metric selection under class imbalance (AUC-PR over accuracy, precision/recall trade-off framed in business cost)

Tier 2  choose based on your problem type:

Tier 3  production-adjacent hygiene (skip this and you pay for it later):

• Git fluency, and code that runs outside the author’s laptop
• Experiment tracking (MLflow, Weights & Biases) as a habit, not a tool they’ve heard of
• Awareness of feature stores and the training/serving skew problem
• Basic containerisation literacy  enough to hand off cleanly to whoever will hire Python developers or ML engineers to productionise the work

Tier 4  the ones that actually separate candidates:

• Can state a business metric and a model metric in the same sentence
• Has killed a project, and can explain the evidence that killed it
• Writes decisions down  model cards, assumption logs, evaluation memos
• Asks about label provenance unprompted

Seniority bands, practically defined:

1. Junior (0–2 yrs): executes a well-specified modelling task. Needs a defined problem and a reviewed evaluation plan. Not a first hire.
2. Mid (2–5 yrs): owns a defined prediction task end-to-end, including evaluation design. Appropriate first hire only if a technical lead reviews their work.
3. Senior (5–8 yrs): frames the problem, challenges the business assumption, designs the evaluation, and negotiates scope with stakeholders. This is the correct first hire for most projects.
4. Staff/Principal (8+ yrs): sets ML strategy across multiple projects, builds the team. Overkill for a single initiative and hard to retain one.

If your project needs a specialist rather than a generalist  production serving, retraining automation, inference optimization  the correct move is to hire machine learning engineers alongside or instead. See the role comparison below before you commit to a title.

Phase 3  Sourcing and vetting

Vetting a data scientist is where most non-specialist buyers lose. You cannot assess modelling judgement by reading a resume, and a standard four-round loop tests the wrong 15%. The loop below is the one we run when clients ask us to hire data scientists for ML projects on their behalf, and it holds up even without an in-house ML panel.

1. Screen (30 min). One project, in depth. Ask: what was the business metric, what was your baseline, how did you split the data, and what nearly went wrong? You are listening for specificity and self-correction, not vocabulary.
2. Data exercise (2–3 hours, take-home). Give them a deliberately messy extract from your own domain of inconsistent nulls, duplicate keys, a date column in two formats, and one planted leakage field. Score the write-up, not the score.
3. Problem-framing case (60 min, live). Present a real business problem with no obvious target variable. Watch them define the prediction task, question the data, and say what they’d refuse to promise.
4. Past-project deep dive (60 min). Have them walk through their own code or architecture. Ask why three times on any decision. Shallow depth surfaces within ten minutes.
5. Stakeholder round (30 min). A non-technical business owner asks them to explain their last model and its limitations. If your commercial lead doesn’t understand the answer, neither will your board.
6. References focused on outcomes. Not “were they good to work with.” Ask: did their work reach production, who maintained it afterwards, and what broke.

Red flags  pattern-matched from real screening loops:

• A portfolio composed entirely of Titanic, MNIST, Iris or Kaggle-competition notebooks. It means they have never met raw organisational data.
• Reports accuracy on an imbalanced dataset without volunteering the base rate.
• Cannot describe how any of their models reached an actual user.
• Never mentions a baseline. Strong candidates bring it up in the first three minutes.
• Describes the business objective only in model terms (“we improved F1 to 0.84”).
• Talks fluently about architectures but hesitates on GROUP BY semantics.
• Has never killed or rejected a project. Everyone senior has.

Green flags  the four that correlate most strongly with delivery:

1. Asks how labels were generated, and whether the labelling process changed over time.
2. Asks about the latency budget and retraining cadence before discussing algorithms.
3. Proposes a temporal split unprompted when the problem is time-dependent.
4. Explicitly states what the model will not be able to do.

The 3-day rule we apply on ML roles: if a shortlisted candidate hasn’t been given a decision within three working days of the final round, assume they’re gone. In our own delivery data across 527+ IT projects, ML and data roles have the shortest offer-acceptance windows of any engineering category  and offer-shopping is the norm, not the exception. Compressing the loop is a quality lever, not just a speed one.

For teams without the internal bandwidth to run this loop, structured IT staffing services exist precisely to front-load steps 1–4 so your team only spends time on final-round candidates. The relevant metric to ask any partner for is not shortlist volume, it’s shortlist-to-offer conversion.

Phase 4  Engagement models and contracts

The engagement model should follow the project’s certainty, not your headcount policy.

Contract clauses specific to ML  the ones generic MSAs miss:

1. IP assignment must name model artefacts explicitly  trained weights, feature definitions, prompt templates, evaluation datasets and notebooks. “Deliverables” alone has been argued both ways.
2. Training data usage restrictions. State whether your data may be used to train anything outside your project, and prohibit retention after termination.
3. Data residency and processing location. For DPDP Act 2023 and GDPR exposure, specify the geography where processing occurs and who the sub-processors are.
4. Third-party model and API terms. If the work uses commercial LLM APIs, confirm who holds the account, who pays inference costs, and whether the provider’s terms permit your use case.
5. Reproducibility as an acceptance criterion. Deliverables include the environment specification and a runnable pipeline, not a notebook that only executes on the author’s machine.
6. Replacement terms with a defined window. Ours is a 7–10 day replacement guarantee; whatever the number, get it in writing with the clock starting from your notice, not from the partner’s acknowledgement.
7. Notice period and transition obligations  minimum two weeks of documented handover, with named artefacts.

The negotiation point most buyers concede by accident: partners often propose that model IP transfers on final payment. On a multi-month engagement, that means you hold nothing if you terminate at month four. Push for IP vesting progressively, at each accepted milestone.

Phase 5  Onboarding and the first 14 days

Ramp-up is where good hires are wasted. The objective of week one is not a model. It is access, context and a baseline.

Pre-start checklist  complete before day one:

• Warehouse/lakehouse read access provisioned, with the PII masking policy documented
• A sandbox compute environment with a stated budget ceiling
• Repository access, and a named code reviewer
• One-page data dictionary for the three most relevant tables, however imperfect
• Named business stakeholder with a recurring 30-minute slot
• The Phase 1 brief, written down and shared

Days 1–3  orientation and access verification. They should independently reproduce one existing business number (last month’s churn rate, last quarter’s conversion) from raw tables. If they can’t, you’ve found a data problem before it becomes a model problem.

Days 4–7  data audit and baseline. Deliverable: a short memo covering row counts, null patterns, label distribution, suspected leakage fields, and a naive baseline metric. This memo is the highest-value artefact of the entire first month.

Days 8–14  first evaluated model. Not a good model. A measured one, with a documented split strategy and a comparison against the baseline.

The 14-day baseline rule: if there is no documented baseline and evaluation plan by day 14, escalate immediately. In every stalled ML engagement we’ve reviewed, this artefact was either missing or produced retroactively. It is the earliest reliable signal available.

Phase 6  Managing delivery

ML delivery does not fit a standard sprint report, because progress is not linear and a negative result can be the correct output of a two-week experiment.

Cadence that works:

1. Weekly, 30 min  experiment review. What was tested, what the metric did, what’s next. Negative results are reported as results, not as delays.
2. Bi-weekly, 45 min  stakeholder alignment. Business metric movement, assumption changes, scope drift check.
3. Monthly  model review. Evaluation on a fresh holdout, drift check, error analysis on the worst-performing segment.
4. Ad hoc  decision log entries. Every changed assumption gets one line and a date.

KPIs that actually indicate health:

• Time to first baseline (target: ≤ 14 days)
• Experiment velocity  measured hypotheses per fortnight, not lines of code
• Offline-to-online metric gap  a large gap means the evaluation design is wrong
• Model documentation currency  is the model card current as of the last change
• Production readiness score  reproducible pipeline, pinned dependencies, tests on feature transforms

What to stop measuring: model accuracy as a standalone KPI. It rises when you overfit and falls when you fix leakage. Track the business metric and the offline-online gap instead.

Phase 7  Scaling or exiting

Two decisions, both with clear triggers.

Add headcount when any of these is true:

• The data scientist is spending more than 30% of their time on pipeline maintenance → add a data engineer
• A model is validated offline and blocked on serving → add an ML engineer
• Two or more models are live and need monitoring and retraining → add MLOps capability
• Annotation volume exceeds a few hours a week → add an annotation vendor or workflow, not a scientist

For organisations reaching three or more concurrent ML initiatives, the economics start favouring a permanent offshore team over rolling contracts  which is the point at which a global capability center becomes a sensible structure rather than an overbuild.

Offboarding  the handover artefacts to demand, non-negotiably:

1. Runnable end-to-end pipeline with pinned dependencies and an environment spec
2. Feature definitions documented in text, not only in code
3. Evaluation datasets with their generation logic
4. Model card: intended use, known failure modes, performance by segment, retraining trigger
5. Decision log covering every scope and assumption change
6. A recorded 60-minute walkthrough with the receiving engineer

Replacement reality check: even with a partner-backed replacement guarantee, a mid-engagement change costs 2–4 weeks of context rebuilding. That is an argument for vetting depth up front, not for tolerating a bad fit.

Data Scientist vs ML Engineer: Settling the Overlap

The data scientist vs ML engineer confusion costs more money than any other role-definition error in ML hiring, because both titles are used loosely by candidates and job boards alike. Two candidates with identical titles can have zero skill overlap.

The decision rule: hire a data scientist when you don’t yet know whether the prediction is possible. Hire an ML engineer when you know it is, and it isn’t reaching users. Getting this order wrong is what produces a well-paid modeller writing Airflow DAGs for a quarter.

The hybrid reality: roughly one in five senior candidates genuinely spans both and they can frame a problem and ship a containerised service. They exist, they cost 20–35% above the band, and on a first ML project they are usually worth it, because they remove the handoff entirely. 

Screen for it explicitly rather than hoping for it: ask for one example of something they built and then operated in production for at least six months. It is the highest-leverage question available to anyone about to hire data scientists for ML projects on a compressed timeline.

ML Project Team Structure by Stage

A sensible ML project team structure grows in a fixed order. Adding roles out of sequence is how teams end up with five people and no deployed model.

Stage 1  Feasibility (weeks 0–6). Team of 1–2.

• 1 senior data scientist (or 1 mid + fractional senior review)
• Part-time access to a data engineer or analytics engineer
• Named business stakeholder, 30 min/week
• Exit criterion: documented baseline, feasibility verdict, and a go/no-go recommendation in writing

Stage 2  Build (weeks 6–16). Team of 2–4.

• 1 senior data scientist (owner)
• 1 data engineer (0.5–1.0 FTE)
• 1 ML engineer joining from about week 10, not week 1
• Exit criterion: model beating baseline on a temporally held-out set, plus a production readiness review

Stage 3  Deploy and operate (weeks 16–28). Team of 3–5.

• 1 ML engineer (lead through this stage)
• 1 data scientist (0.5 FTE, error analysis and iteration)
• MLOps capability, often shared across projects rather than dedicated
• Exit criterion: live model with monitoring, rollback path, and a defined retraining trigger

Stage 4  Scale (month 7+). Team of 5–10.

• Dedicated MLOps, multiple data scientists, an AI product manager holding the portfolio
• Exit criterion: second and third use cases shipping without a proportional headcount increase

The ratio worth remembering: in mature teams, data scientists to ML/data engineers converges to roughly 1:1.5. Teams that stay at 3:1 in favour of scientists accumulate models that never ship.

Case Studies

Three engagements from Supersourcing’s delivery history that map directly onto the phases above. Metrics first.

Paytm  100+ engineers, sustained hiring velocity. A hiring programme spanning 100+ engineering hires, run against a 7–10 working day cycle from job description to interview-ready shortlist. The relevant lesson for ML hiring: at that volume, the constraint was never sourcing reach; it was the depth of technical screening applied before the client’s panel spent time. Front-loading the technical filter is what held a 98% candidate joining rate at scale.

Swiggy  engineering scale-up under product pressure. Rapid-growth hiring across engineering functions in a high-velocity consumer environment, where the cost of a slow loop is measured in shipped features. The applicable pattern: compressed decision windows plus dedicated account management, with no shared bandwidth across accounts, kept candidate drop-off on contract roles under 1%  the same discipline that protects ML offers from being lost to counter-offers.

Somnoware  recruitment automation for a healthtech data product. A healthtech engagement where the hiring requirement itself was data- and compliance-adjacent, requiring candidates screened for both technical depth and regulated-data handling. The transferable lesson: when the role touches sensitive data, compliance literacy has to be a screening criterion in its own right, not a checkbox at offer stage  exactly the argument for making DPDP and GDPR awareness a Tier 1 requirement on any healthcare or fintech ML project.

The Decision Framework: Which Hiring Route Fits Your Project

There is no universally correct route to hire data scientists for ML projects; the right structure is a function of your problem certainty and your data. Score your project on five factors, then read across. Each factor is 1–3 points.

1. Problem certainty  1: exploratory · 2: defined but unvalidated · 3: proven, needs scaling
2. Data maturity  1: scattered · 2: warehoused but undocumented · 3: governed with quality contracts
3. Internal ML expertise  1: none · 2: one technical reviewer · 3: existing ML team
4. Duration  1: under 3 months · 2: 3–12 months · 3: ongoing capability
5. Sensitivity  1: public/low-risk data · 2: internal business data · 3: regulated PII or PHI

Override rule: if internal ML expertise scores 1, do not choose freelance. Without an internal reviewer, unsupervised freelance work on an unvalidated problem is the highest-variance option available, and you have no way to detect a bad result until it’s expensive.

What Most Teams Get Wrong

Five patterns, in descending order of cost. This is the section worth screenshotting.

1. They hire for the model, not for the data. The job description lists frameworks. The project fails on label quality and pipeline reliability. Gartner’s projection that 60% of AI projects will be abandoned through 2026 for want of AI-ready data is, read correctly, a hiring critique: teams staffed for the last 20% of the work.
2. They test candidates on clean data. A take-home built on a tidy CSV measures scikit-learn familiarity. It cannot distinguish someone who will notice that your created_at column changed timezone semantics in 2023. Give messy data, and plant one leakage field.
3. They treat “senior” as a year’s count. The distinguishing behaviour of a senior applied data scientist is refusal to say a prediction isn’t supported by the data, in writing, to a stakeholder who wants a different answer. Screen for it directly: “tell me about a time you told the business no.”
4. They defer the production conversation. Deployment surface, latency budget and retraining cadence get discussed after a model exists. By then the feature engineering has assumed information that won’t be available at inference time. Every one of those constraints belongs in the Phase 1 brief.
5. They optimise the offer instead of the loop. Competing on compensation for ML talent against funded AI-native companies is a losing position for most buyers. Competing on decision speed, problem quality and access to real data is a winning one. Strong applied data scientists consistently choose interesting, well-scoped problems over marginal salary differences  and a three-day decision window signals a well-run organisation more credibly than any recruiter pitch.

The contrarian summary: when you hire data scientists for ML projects, the best predictor of success is not the calibre of the modeller. It is whether the problem was framed and the data verified before anyone was hired at all. Sequence beats seniority.

Cost and Timeline Reality Check

Budgeting to hire data scientists for ML projects fails most often on timeline, not on rate. The ranges below reflect Indian and US market bands as of 2026 and should be treated as planning bands, not quotes. 

Actual pricing moves with domain (fintech and healthtech carry a premium), specialisation (LLM and causal inference specialists sit at the top of the band), and location tier.

Compensation and contract bands  India

Comparative offshore rates: India typically lands at $25–60/hour for mid-to-senior applied data science, against $80–150/hour in Eastern Europe and $110–200/hour in the US for equivalent experience. That cost arbitrage is real, but it only converts into savings if the vetting is equivalent to a cheap hire that fails, vetting costs more than the differential saved.

What drives cost up:

• Regulated domains requiring compliance literacy (+15–30%)
• Genuine LLM production experience, as opposed to prompt experimentation (+20–40%)
• Hybrid scientist/engineer profiles (+20–35%)
• Urgency under two weeks, which narrows the pool to immediately available candidates
• Requiring on-site presence in Tier 1 cities

What drives cost down:

• A documented data layer, which reduces the seniority you need
• Willingness to hire remote across Tier 2 cities
• Contract-to-hire structures that reduce the buyer’s commitment risk
• A clearly scoped brief  ambiguity is priced in by every vendor

Timelines by route

Project timelines by data maturity  this is the number to give your board:

• Governed data layer already in place: 8–12 weeks from hire to a deployed first model
• Warehoused but undocumented data: 16–24 weeks
• Data scattered across systems: 24–36 weeks, and hire data engineering first
• Feasibility spike only (go/no-go verdict): 4–6 weeks, one senior data scientist

Add 2–4 weeks to any of these if the model requires an explainability review for compliance sign-off.

The ML Project Hiring Checklist

A condensed ML project hiring checklist to run against before you make an offer. If more than three items are unchecked, pause the loop.

Before sourcing

• Prediction target defined in one sentence, with horizon and unit
• Business metric and its current baseline value documented
• Deployment surface, latency budget and volume stated
• Labelled historical outcomes confirmed to exist, and counted
• Data location and access owner identified by name
• Decided whether a data engineer should precede this hire

During vetting

• Take-home used real, messy data  with a planted leakage field
• Candidate proposed a baseline unprompted
• Candidate asked about label provenance
• Candidate stated at least one limitation of their own past model
• Non-technical stakeholder understood their explanation
• References confirmed the work reached production

Before signing

• IP assignment names model artefacts, weights, features and evaluation sets
• Training-data usage and retention restrictions written in
• Data residency and sub-processors specified
• Reproducibility included as an acceptance criterion
• Replacement window defined, with the clock starting on your notice
• IP vesting tied to milestones, not final payment

Before day one

• Data access provisioned and tested
• Sandbox environment with a budget ceiling
• Named code reviewer and named business stakeholder
• Phase 1 brief shared in writing
• Day 14 baseline expectation communicated explicitly

Your Next Step Depends on Where You Are Right Now

Three situations, three different next moves.

If you can’t yet answer Phase 1’s five questions, don’t hire anyone this month. Write the brief first: prediction target, business metric, deployment surface, latency budget, hard constraints. That document will save you more money than any sourcing decision.

If the brief exists and the data layer is ready, run the Phase 3 loop as written  messy take-home, framing case, stakeholder round, outcome-focused references  and hold yourself to the three-day decision rule.

If you need a shortlist that’s already been through that filter, that is the specific problem Supersourcing exists to solve. AI-powered sourcing surfaces the top 2% of vetted candidates, ML and data roles are screened by practitioners rather than keyword matched, and the typical cycle is 7–10 working days from brief to interview-ready shortlist  with a replacement window in the same range if a hire isn’t a fit. If you’d rather see the shortlist than debate the theory, bring your brief to a 30-minute scoping call: supersourcing.com/contact-us. Come with your prediction target and your data situation; you’ll leave knowing which role to hire first and what band it sits in.

If you’d prefer to run it yourself, take the checklist above and start with the pre-sourcing block. Either way, the sequence is the same  and the sequence is what decides whether the model ships.

FAQ

What does a data scientist actually do on an ML project? 

They convert a business problem into a measurable prediction task, verify the data can support it, engineer features, design the evaluation, and validate that results hold outside the training set. They own the question and the evidence. Serving the model in production, under a latency budget, is ML engineering work  a related but distinct skill set.

Do I hire a data scientist or a data engineer first? 

If your data is spread across systems, undocumented, or untrusted, hire the data engineer first. A data scientist without a usable data layer will spend 60–70% of their time building a fragile version of one, at a higher hourly cost. If your data is already warehoused and queryable, the data scientist goes first.

How do I test a data scientist if I’m not technical? 

Use three non-technical filters. Ask what business metric their last model moved and by how much  you’re listening for a number and a caveat. Ask them to explain a past model to your commercial lead; if that lead doesn’t follow it, the model won’t get adopted. And run a take-home on your own messy data, scoring their written reasoning rather than their accuracy figure.

How long does it take to hire an ML data scientist? 

Timelines to hire data scientists for ML projects vary by route more than by seniority. Through in-house recruiting without an existing ML network, expect 10–18 weeks to a start date. Through a specialist partner, 7–10 working days to an interview-ready shortlist and 4–7 weeks to start. Contract and staff-augmentation routes compress that to 2–4 weeks, because availability rather than notice period governs the timeline.

How many data scientists does one ML project need? 

One senior data scientist for the feasibility stage. Two to four people once you’re building  the scientist plus data engineering support, with an ML engineer joining around week 10. Deployment shifts the centre of gravity to engineering. Very few single-model projects benefit from more than one data scientist at a time.

What are the biggest red flags when interviewing data scientists? 

A portfolio made entirely of public competition datasets, accuracy quoted without a base rate, no mention of a baseline, inability to describe how any model reached a real user, and no example of a project they killed. Individually these are yellow flags. Two or more together reliably predict a stalled engagement.

Should I hire a freelance data scientist or a dedicated one? 

Both routes work, but for different risk profiles. Freelance suits bounded, low-risk work: a feasibility spike, a second opinion, an audit of an existing model. For anything intended to reach production, dedicated engagement wins on continuity, IP clarity and accountability. The hard rule: if you have no internal technical reviewer, don’t use freelance for an unvalidated problem.

What should a new data scientist deliver in their first 30 days? 

By day 3, an independently reproduced existing business number. By day 7, a data audit memo covering nulls, label distribution, suspected leakage and a naive baseline. By day 14, a first evaluated model measured against that baseline. By day 30, a go/no-go recommendation with evidence. If the day 14 artefact is missing, escalate  it is the earliest reliable warning signal.

Is it cheaper to build an offshore ML team than to hire locally? 

Usually yes on rate, at roughly $25–60/hour in India against $110–200/hour in the US for comparable experience, but the saving only holds if vetting depth is equivalent. If you’re weighing a permanent offshore ML function against rolling contracts, a short scoping conversation is worth more than another spreadsheet. That comparison depends on your project count and data-sensitivity profile more than on rate cards.