How to hire a data scientist

Key takeaways

• Scope against a business decision, not a data domain. "Help us understand our data" produces a data scientist who builds dashboards. "Help us decide whether to expand to a second geography next quarter" produces one who builds an analysis that drives action.
• Three data scientist subtypes: analytics/business intelligence (structured data, business metrics, decision support), ML modeling (predictive models, statistical inference), and applied research (bespoke analysis for novel questions with no standard method).
• Evaluate for communication of uncertainty alongside analytical output. The most valuable senior data scientists know what they don't know and say it clearly.
• First 30 days: a first data audit with findings, a first analysis with a stated business question, a first recommendation shared with a stakeholder.
• Most common failure: scoping too broadly and getting accurate answers to questions nobody asked.

Why this question matters

Data science hiring fails when the scope isn't connected to a decision. A data scientist who produces technically correct analyses on questions the business isn't using produces exactly zero value relative to their cost. The discipline requires both analytical rigor and the judgment to work on the questions that matter and communicate the results to people who will act on them. Both skills are rare; the evaluation needs to test both.

A common mismatch worth checking first

Many requests for a "data scientist" describe work that's actually data engineering plus applied AI, pipelines, retrieval, LLM integrations, applied analytics, not classical statistics or ML modeling. The language has drifted faster than the underlying disciplines, and mis-hires here are common because of it. Before scoping a data scientist hire, walk through what the work involves day-to-day:

• If it's building data pipelines, instrumenting events, or moving data between systems, you want a data engineer.
• If it's integrating LLMs into a product surface, building RAG or agent systems, or evaluating AI output quality, you want an AI engineer.
• If it's classical analytics, statistical inference, A/B testing, or predictive modeling against structured business data, you want a data scientist.

The skills overlap, and a senior practitioner can sometimes span two of the three. But the rubrics and the engagement scopes are different for each.

The decision frame: Decision first, method second

Three questions before writing the JD.

What decision does the company need to make that data could inform? A specific choice, not a general curiosity. "Should we change the pricing model for our mid-market tier?" is a decision. "Understand our pricing better" is not. The more specific the decision, the more useful the data scientist's output will be.

What data exists and what shape is it in? Is the data clean and in a warehouse, or is it scattered across systems that require significant wrangling before analysis is possible? A data scientist walking into a well-structured data warehouse has a different ramp than one walking into raw event logs across three systems. The state of the data shapes the scope and the seniority level needed.

Who will act on the output? The CEO, the product team, the engineering team, or a regulatory body? Each one has different expectations about the format, the confidence intervals they care about, and the level of technical detail they can absorb. A senior data scientist who's good at the analysis but weak at stakeholder communication produces results that stay in notebooks.

Scoping the role

Data scientist engagements fall into three subtypes.

Analytics and business intelligence. The data scientist's primary output is structured analysis of existing business data: cohort analysis, funnel analysis, revenue attribution, churn modeling. They work with a data warehouse and SQL, produce dashboards or reports, and communicate findings to business stakeholders. This is the most common profile for growth-stage companies trying to understand what's happening in their product.

ML modeling and prediction. The data scientist builds predictive models: propensity models, recommendation systems, anomaly detection, demand forecasting. They work in Python or R, manage training/validation/deployment workflows, and own the model's performance over time. This is closer to ML engineering than to BI; the output is a deployed model, not a report.

Applied research. The data scientist tackles bespoke analytical questions that don't have a standard method: causal inference when there's no clean experiment, natural language analysis of unstructured customer data, statistical analysis of a novel question the business has never asked before. This is the most senior and most specialized profile.

Evaluating a senior data scientist

The wrong bar is statistical knowledge alone. A senior data scientist who can run any test you ask them to is useful; one who can tell you which test to run, why, and what the results mean for the decision you're trying to make is much more valuable. The evaluation needs to test the latter.

Analysis debrief. Ask the candidate to walk through an analysis they ran that changed a business decision. Ask: what was the question they started with, what was the method, what were the caveats they communicated, and what decision changed as a result? The "what changed" part is the most predictive signal. Many data scientists can describe technically correct analyses; fewer can describe ones that actually drove action.

Ambiguity test. Give the candidate an ambiguous business question, one that could be answered several different ways depending on assumptions, and ask how they'd approach it. Do they ask clarifying questions about the decision it informs before reaching for a method? Do they identify what assumptions the answer depends on? Do they communicate uncertainty honestly rather than projecting false precision?

Communication test. Ask the candidate to explain a statistically complex concept (confidence intervals, A/B test power, causal versus correlational inference) to a stakeholder who doesn't have a statistics background. The ability to translate across technical registers is one of the clearest signals of senior data scientist maturity.

The first 30 days

Week one: data audit. The data scientist should have access to the data warehouse, event tracking system, and any existing dashboards or analyses on day one. Week one is spent understanding what data exists, what shape it's in, and what questions it can answer. End of week one: a written summary of what data is available and what the three highest-value questions the data can answer are.

Week two: first stated analysis. One question, one method, one answer, with the caveats stated explicitly. Not a polished presentation. A working draft that the team can read and critique. The goal is to make the data scientist's analytical approach visible before they've invested heavily in a direction.

Week three: stakeholder communication. The data scientist presents the week two analysis to the person who will act on it. Not as a finished deliverable, as a draft for input. Does the answer address the question the stakeholder actually has? Are the caveats landing as useful context or as confusing qualifiers?

Week four: first recommendation with a stated decision. The output of month one should be a clear recommendation: "Based on this analysis, we recommend X over Y, with the following confidence and the following caveat." The recommendation can be tentative. What can't be tentative is that it's connected to an actual decision.

Common failure patterns

Two failure patterns account for most data scientist mis-hires.

The scope was open-ended and the output was accurate but unused. A data scientist hired to "help us understand our data" produces a year's worth of technically correct analyses that nobody acts on. The problem is scope, not skill. Scope against decisions.

The data scientist was hired before the data was ready. A senior data scientist hired to build predictive models walks into a company where the event data isn't tracked, the data warehouse doesn't exist, and the first three months are spent on data infrastructure rather than analysis. This isn't a hiring failure, it's a scope mismatch. If the data isn't ready, hire a data engineer first.

What to do next

Write the decision before writing the JD. One sentence: "We need to decide X by Y date, and we believe data could inform that decision by showing us Z." If you can write that sentence, you have a brief. If you can't, the data science need isn't clear enough to hire for yet.