Hiring a Data Team: Roles, Sequencing, and What to Actually Test in Interviews

Building a data team is harder than most hiring managers expect. Data roles have proliferated — data engineer, analytics engineer, data scientist, data analyst, BI developer, ML engineer, data architect — and the boundaries between them are genuinely blurry. Candidates who perform well in interviews sometimes fail to deliver in roles. And the sequencing error — hiring the wrong role first — can set a data function back by 12 months.

This guide is written for CTOs, VPs of Data, and first-time data hiring managers who need to build a data capability and want to do it correctly.

The Sequencing Problem

Most organisations hire in the wrong order. They have a reporting need, so they hire an analyst. The analyst cannot answer questions independently because there is no data pipeline, so they spend their time waiting for engineering to export data. Or they hire a data scientist first because "AI is important", and the data scientist spends their time wrangling raw data that should have been cleaned and modelled by a data engineer or analytics engineer.

The correct first hire depends on your current state:

**If you have no data infrastructure:** Hire a data engineer or analytics engineer first. They will build the pipelines, set up the warehouse, and create the modelled layer that everything else depends on. An analyst hired before the infrastructure exists will underperform through no fault of their own.

**If you have data infrastructure but no analytics layer:** Hire an analytics engineer (dbt-focused, strong SQL, data modelling experience). They will build the semantic layer, clean and model the data, and create the certified data sources that analysts and BI tools depend on.

**If you have infrastructure and a data model but no visualisation layer:** Hire a BI developer or data analyst with strong Tableau or Power BI skills. They will build the dashboards and reports that make the data accessible to the business.

**If you have a functioning analytics stack and need more sophisticated analysis:** Now is the time for a data scientist or senior analyst who can do statistical analysis, build predictive models, and run experiments.

The first hire sets the foundation. Getting this wrong is expensive — not because the hire fails, but because the scope of work they can deliver is constrained by the infrastructure that does not yet exist.

Role Definitions That Prevent Overlap

Data team roles need explicit boundaries. Without them, you get conflicts over who owns what, work falling through the gaps, and candidates who do not know what they are being hired for.

**Data Engineer:** Owns ingestion pipelines (Fivetran, Airbyte, custom connectors), orchestration (Airflow, dbt Cloud, Dagster), and data infrastructure (warehouse configuration, access management, monitoring). Does not typically build analytical models or dashboards. Core skills: Python, SQL, cloud infrastructure (AWS/GCP/Azure), distributed systems.

**Analytics Engineer:** Owns the transformation layer (dbt models, data quality tests, documentation) and the semantic layer (certified data sources, metric definitions). Sits between data engineering and analytics. Core skills: SQL (advanced), dbt, data modelling, git workflow, some Python.

**Data Analyst:** Owns analytical deliverables — dashboards, reports, one-off analyses, stakeholder communication. Depends on the infrastructure built by data engineers and analytics engineers. Core skills: SQL (intermediate), Tableau or Power BI, analytical thinking, business communication.

**Data Scientist:** Owns predictive modelling, statistical analysis, and experimental design. Requires a clean, well-modelled data layer to work from efficiently. Core skills: Python (pandas, scikit-learn), SQL, statistics, ML algorithms.

**BI Developer:** Specialises in building dashboards and visualisations, often with deep expertise in a specific BI tool. Similar to data analyst but with more technical depth in BI tooling and less breadth in SQL and modelling. Core skills: Tableau or Power BI (expert-level), some SQL, data visualisation design.

**Data Architect:** Owns platform-level design decisions — warehouse selection, schema architecture, governance framework, data modelling standards. Typically a senior role that provides architectural oversight rather than hands-on implementation. Core skills: systems design, cloud platforms, data modelling, security and governance.

For small teams (1–5 people), these roles overlap significantly and one person may carry multiple hats. Define which hat is primary based on the team's current most urgent need.

What to Actually Test in Interviews

The most common data hiring mistake is testing what candidates know rather than what they can do. A candidate who has memorised SQL syntax is not the same as a candidate who can design a data model, debug a broken pipeline, or translate a business requirement into an analytical plan.

For data engineers and analytics engineers:

Give a take-home data problem that requires building something. A 2–3 hour exercise with a realistic dataset: ingest the data, clean it, model it with dbt, write tests, document it. Evaluate the result in a review session. What you are looking for: Does the model design make sense? Are tests meaningful or just satisfying the exercise requirement? Is the code readable? Can they explain their decisions?

In the live interview, describe a real data quality problem your team has faced and ask how they would diagnose and fix it. A good candidate will ask clarifying questions about the system, propose a diagnosis approach, and discuss trade-offs rather than jumping to a single answer.

For data analysts and BI developers:

Provide a real dashboard brief — a business stakeholder need, a data source, specific questions they need to answer. Ask the candidate to produce a dashboard design (wireframe is sufficient) and walk you through their design decisions. What you are evaluating: do they understand the business question, or are they just showing off visualisation capability?

In the interview, give them a scenario where two metrics in a dashboard disagree. Walk through how they would investigate and resolve the discrepancy. This tests data intuition and systematic thinking.

For data scientists:

Avoid puzzles and algorithmic coding challenges — they test things data scientists rarely do in practice. Instead, give a real dataset from your domain and ask for an exploratory analysis: what do you see, what do you want to investigate further, what is the right model to answer the business question? A strong data scientist is curious about the data and thinks carefully about what question the business actually needs answered before reaching for a model.

Red Flags in Data Interviews

**The candidate cannot explain why, only what.** If someone can describe what they built but not why they made the design choices they did, they were executing instructions, not thinking independently. Data roles require judgment.

**No questions about the data.** A data professional who receives a dataset for a take-home exercise and does not ask any clarifying questions about what the data means, where it comes from, or what business question it is meant to answer is not approaching the work the way a practitioner would.

**Overfitted solutions to interview-style problems.** A data scientist who immediately jumps to the most sophisticated model for an interview problem without first examining the data, checking assumptions, or thinking about whether a simpler model is sufficient has been optimised for interviews, not for delivering useful models.

**The candidate has no opinion about trade-offs.** Good data engineers, analytics engineers, and architects make decisions under uncertainty. They choose between options with real trade-offs. A candidate who agrees with every option you present and has no view of their own on architecture decisions does not have the judgment your team needs.

The First 90 Days Setup

Data hires fail most often not because of capability gaps but because of setup failures: unclear scope, no access to data, no clear first deliverable, and no feedback loop. For a new data hire to succeed:

**Access on day one.** They need read access to the data warehouse, access to the BI tool, write access to the git repository, and access to the documentation that exists. Waiting two weeks for IT to provision access wastes the most motivated period of any new hire's tenure.

**A clear first deliverable in the first two weeks.** Not a project to plan; a specific thing to build or analyse. This gives the hire a reason to learn the data, establish relationships with stakeholders, and demonstrate capability quickly.

**A regular feedback session in weeks two, four, and eight.** Catch misalignment early. A hire who misunderstands the scope of their role for three months is a problem that should have been caught in week two.

Building a data team is a multi-year investment. Getting the first few hires right — in sequence, with the right role definitions and interview process — determines whether the function becomes a capability the business relies on or a cost centre that struggles to demonstrate value.

Our data architecture consulting practice helps organisations design their data team structure and hiring plan as part of broader data platform engagements — contact us if you are planning a data team build.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.