How to hire your first data person

Companies hiring their first dedicated data person often reach for the title they have heard most — "data scientist" — regardless of what the business actually needs. That mismatch is one of the most common early hiring mistakes in this field: a data scientist hired to build predictive models spends their first six months instead untangling a spreadsheet-based reporting process nobody had gotten around to fixing, because there was no infrastructure, and no earlier hire, to have fixed it first.

Match the role to the actual problem

The roles differ in what they are built to do, and the first hire should match whichever problem is most acute — see analyst vs analytics engineer vs data engineer vs data scientist for the fuller breakdown. In summary:

• A data analyst answers business questions with data that already exists somewhere — spreadsheets, a production database, a handful of SaaS tools. If the actual problem is "we make decisions without looking at data, and the data mostly already exists," this is the first hire.
• A data engineer builds and maintains the pipelines that get data from source systems into a queryable place. If the actual problem is "the data does not reliably exist anywhere queryable," hiring an analyst first gives them nothing to analyze.
• An analytics engineer sits between the two: takes data a pipeline has already loaded and transforms it into clean, modeled, documented tables. Rarely the very first hire, because it presupposes both data being loaded and people to consume the models — but often the right second or third hire once basic pipelines and a couple of analysts exist.
• A data scientist builds statistical or machine learning models. This is almost never the correct first hire at a small company: models need a reliable data foundation and a clearly defined problem, both of which a first hire is usually still building.

Most companies with under roughly a dozen data-adjacent requests per week and no existing pipeline should hire a generalist analyst or a generalist analytics engineer first — someone comfortable pulling data from a live production database, cleaning it, and answering a question end to end — rather than a narrow specialist in any single role above.

What to actually test for

Résumés and take-home titles predict less than a live exercise does. A working interview structure:

1. A real, messy dataset and a real, ambiguous question. Give the candidate a dataset with the ordinary flaws production data has — missing values, an inconsistent date format, a duplicate key — and a question like "did this change help or hurt." Watch what they do before writing any code: do they ask what the numbers actually mean, or start aggregating immediately?
2. SQL fluency, live, not as a take-home. A candidate who writes correct joins and aggregations under mild time pressure, explaining their choices as they go, has demonstrated something a take-home cannot: how they think when stuck.
3. A "so what" moment. After they produce a number, ask what they would tell a stakeholder and what they would do next. The strongest data hires can turn a result into a recommendation; the weakest stop at the chart.
4. A skepticism check. Show a plausible-looking but flawed result — a metric computed over the wrong denominator, a trend driven by one outlier — and see whether they catch it unprompted. This is closer to exploratory data analysis in practice than any formal test: does curiosity about the data itself show up without being asked for.

Avoid over-indexing on a specific tool stack in the interview. A strong analyst who has never used your particular BI tool will be productive within weeks; a weak analyst fluent in your exact stack will not compensate for it. A take-home assignment, if you use one at all, should take an hour or two, not a weekend — a long unpaid take-home filters for who has free time, not who is skilled, and strong candidates increasingly decline them outright.

Where to source candidates

A first data hire does not need to come from a traditional data science background. Strong candidates come from finance, operations and customer-facing roles where someone was already the person who built the ad hoc spreadsheet analysis everyone relied on — they have already demonstrated the business judgment that is hardest to train, and the technical skills are the faster half to build from there. Weight a candidate's concrete examples of a messy, ambiguous problem they solved end to end well above a polished list of tools on a résumé.

What to give them in the first ninety days

A first data hire without infrastructure, access or a clear mandate spends months building the basics informally before doing any of the work they were hired for. Set them up instead with:

• Read access to the systems that matter, granted on day one rather than requested and waited on — a common, avoidable source of a slow start.
• A short list of the three to five questions leadership actually wants answered, prioritized, so the first hire is not guessing what matters or building for imagined future needs before proving value on real ones.
• A named point of contact for domain context — someone who can explain what "active" means in this business, what a normal week looks like, and which numbers have been historically unreliable.
• Permission to say a question cannot be answered yet, rather than an expectation of a polished dashboard for everything asked in the first month. The first hire's most valuable early output is often identifying what data does not exist yet, not a chart.

Signs you hired the wrong first role

• The person spends most of their time waiting on data that does not exist yet, rather than analyzing — you needed a data engineer or a stronger platform first.
• The person produces technically sound models nobody acts on — you needed an analyst who could translate findings into decisions before you needed someone building predictive models.
• The person is constantly rebuilding the same report by hand because nothing is automated — you needed someone (or some tooling) focused on pipelines and modeling before more analysis capacity.

None of these mean the hire was a bad hire; they usually mean the role came before the infrastructure or mandate it needed. See how to structure an analytics team for what to build around this first hire as headcount grows, and how to become a data analyst for the skills and portfolio candidates for this role are usually building toward.