Hiring data engineers, analysts and data scientists: three different jobs, three different tests

A data boutique wins a project to forecast demand for a client. The delivery head hires a data scientist with an impressive research record. Three weeks in, the new hire is still waiting for the data to arrive in a usable shape, because nobody on the team can build the pipeline that would deliver it. The model is not the problem. The missing engineer is.

This post separates the three common data roles so that your brief, your test and your offer all match the work.

• Data engineer: moves data from source systems to places where others can use it. Writes and monitors pipelines, handles schema changes, fixes failures at odd hours, and worries about cost and reliability.
• Data analyst: takes clean data and answers questions. Builds dashboards, writes queries, explains a drop in a number, and tells a client what to do next.
• Data scientist: frames a problem as a prediction or an experiment, builds and tests models, and judges whether the result is good enough to use.

Titles blur in practice. A small team may ask one person to do two of these. That is fine if the brief says so. It becomes a problem when the advert says one thing and the first project needs another.

Start each brief with the first project the person will own, in two sentences. Then list the tools they will touch in the first quarter, not every tool the company has ever used. Our guidance on role design and job descriptions covers how to separate must-haves from things that can be learned on the job.

1. 1

   Engineer: repair a broken pipeline

   Give a small repository with a failing job, a source file with a changed column and a short note from a client. Watch how they read logs, what they check first, and how they explain the fix and a safeguard against it happening again.

2. 2

   Analyst: question a messy dataset

   Provide a spreadsheet with duplicates, odd dates and a headline number that looks wrong. Ask them to find out why and write three lines for a non-technical client.

3. 3

   Scientist: frame and model a vague problem

   Offer a one-page problem such as predicting which customers will stop buying. Ask how they would define the target, what data they would ask for, how they would split it and how they would check the result is not luck.

4. 4

   All three: a short conversation about a past mistake

   Ask what went wrong in a project and what they changed afterwards. Honest answers are easy to spot.

A take-home task that needs a weekend filters out people with caring duties and keeps people with free time. Cap it at a couple of hours, or run it live with a colleague. Use material you have written yourself, never a real client's data. Tell candidates in advance what you will look for and how long to spend.

After the test, hold a debrief the same day. Each interviewer writes a score and a short note before anyone speaks. This stops a confident senior voice from setting the mood for the rest. If two interviewers disagree sharply, ask each to point to the answer or the code that shaped their view.

Watch for a few common traps. A candidate who talks only about tools and never about the problem may struggle with ambiguity. A candidate who cannot say what their own part of a team project was may be borrowing credit. A candidate who never mentions data quality has probably not yet been burned by it. None of these is a rejection on its own, but each deserves a follow-up question.

Role and first project owned in the first quarter.
Skill 1: core technical craft, scored 1 to 4 with a one-line evidence note.
Skill 2: clear thinking about data quality and limits.
Skill 3: explaining findings to a non-technical client.
Skill 4: working with others, tested in a panel conversation.
Concerns raised and who will probe them in the next round.
Interviewer decision written before the group discussion.

Engineers often come from backend and platform teams. Analysts may come from finance, operations or reporting roles. Scientists come from universities, research groups and analytics teams. Look at a candidate's projects and how they describe their own part. If your hiring pipeline is thin, a talent acquisition process with clear stages and weekly reviews helps you move before good people sign elsewhere.

If the scientist's path is the only way to grow, your best engineers and analysts will drift into roles they do not enjoy. Describe a senior path for each role that does not require moving into another one. Decide the pay bands from your own market checks and your budget, not from a number you saw in a thread.

Talk about growth at the offer stage too. Tell each candidate what a good first year looks like and who will review it. People who can picture their second year in a role are more likely to still be there for it.

If your clients are AI product startups, you will meet data roles that blend product thinking with modelling. Hiring for these needs a scorecard that adds product judgement. Be explicit in the brief if the person is expected to talk to users.

• Check that the first project and the stated role match.
• Confirm which tools the person can pick up and which they must already know.
• Agree how their first review will be judged, and read our note on reviews for research and data roles if their results will take months to appear.
• Make sure the offer letter and contract wording are reviewed by your own qualified adviser.