Talent

Data Engineer vs Data Scientist: Which One to Hire First

Two profiles that get merged into one job ad and paid differently. The real responsibilities, how to tell which bottleneck you actually have, Spanish salary bands, and a technical exercise for each.

·16 min·Pedro Cailá · Kulturo
Talent

Data Engineer vs Data Scientist: Which One to Hire First

A CTO opens a role for a data scientist because the company needs to "get AI going". Two months later the new hire is still cleaning tables, chasing incomplete events and trying to work out why every dashboard shows a different number. The problem was never the candidate's ability. The company needed a data engineer.

The opposite mistake is just as common. A startup already has accessible data, a reasonably organised warehouse and clear questions about retention, fraud or pricing — and hires an engineer to solve a problem that calls for statistical experimentation and predictive models. The result is a tidier platform and not one better business decision.

In Spain the market now holds 151,700 professionals specialising in data and artificial intelligence, with 4,000 unfilled vacancies and year-on-year growth of 4.05%, according to the salary and market references compiled by Calcutech Salary. Picking the wrong profile does not just delay the roadmap. It burns budget in a market where closing a technical hire demands precision.

The most common mistake when hiring data profiles

The CTO of a product scaleup usually receives an ambiguous request from the leadership team: "we need someone for data". It becomes a data scientist job ad, Python, SQL and machine learning get added, and the hope is to attract someone who can build pipelines, analyse users, ship models and explain results to the board. That ad describes three jobs, not one.

The right candidate reads the real responsibility behind the title. If the day-to-day is integrating product, payments and CRM data, automating loads, resolving duplicates and making sure reports land on time, a competent data scientist will feel underused. If the challenge is forecasting demand, designing an experiment or building a propensity model, a data engineer can deliver flawless infrastructure without answering the main question.

The confusion arises because both profiles share Python, SQL and daily contact with data. In Spanish startups, one person often covers analysis, engineering and machine learning during the early stages as well. That reality does not make the roles interchangeable. It only means the company has to separate a temporary need for breadth from a permanent responsibility for depth.

Hiring rule: do not start from the job title. Start from the bottleneck blocking a decision, a launch or a reliable operation.

Before opening the role, document which decisions you want to improve and which tasks are blocked. A useful frame is to separate three questions:

  • Access: is the data complete, documented and available when the team needs it?
  • Reliability: do the pipelines, data models and quality processes work consistently?
  • Value: does the company have usable data but no way to extract predictions, experiments or actionable recommendations?

The first two point to a data engineer. The third points to a data scientist. To frame the business problem it is also worth reviewing material on business metrics and KPIs, because a data hire only pays off when it connects to indicators somebody actually uses to decide.

By the end of that analysis you should be able to write one concrete sentence: "we need to build a reliable base so other teams can work" or "we need to turn available data into analysis and models that change a decision". That sentence sets the profile, the technical exercise, the seniority and the offer.

What a data engineer and a data scientist actually do

A data engineer builds and maintains the pipes the data travels through. The work starts at imperfect sources — application events, transactional databases, external APIs, internal systems — and ends in structures that analysts, scientists and product teams can query with confidence.

A given day might mean designing ETL or ELT processes, fixing a failed job, optimising a SQL query, modelling tables for a warehouse, configuring quality checks or documenting what a metric means. They also answer for infrastructure, availability, latency and data governance. The deliverable is not a set of tables. It is an operating system for analytical work.

The usual stack includes Python and SQL as a base, Airflow for orchestration, dbt to transform and document models, and Spark when processing has to work at a larger scale. The cloud platform, storage, permissions and observability round out the technical context. A candidate has to show they can operate what they build, not just write a correct transformation in a controlled environment.

A data scientist works on accessible data to find patterns, test hypotheses and turn results into decisions. Their day might open with exploratory analysis, continue with feature preparation, and close with evaluating a model or presenting a recommendation to product, marketing, operations or leadership.

The profile is not limited to training algorithms. They have to decide which question deserves an answer, which metric represents the objective, which biases could affect the analysis, and how to communicate a conclusion along with its limits. A technically sophisticated model is worthless if the commercial team does not know what action to take, or if the experiment cannot separate correlation from causation.

On this side you find Jupyter, scikit-learn and TensorFlow, alongside Python or R, statistical libraries and visualisation tools. The key difference is the deliverable. The engineer leaves behind a platform and reliable data. The scientist leaves behind analysis, experiments, predictive models or interpretable recommendations.

For more on the first profile, there is this guide to what a data engineer does. The decisive hiring question stays simple: do you need the data to arrive properly, or do you need someone to work out what to do with it?

The skills, technical and otherwise, that separate them

The overlap between the two profiles is real, but it should not dominate the job description. Python and SQL appear on both CVs, though a data engineer uses them to build reliable processes and a data scientist to explore, transform and model. A job ad that only lists tools will attract a mixed field and force the interviewer to guess at the specialisation.

Key skills by profile

Competency Data Engineer Data Scientist
Main purpose Build infrastructure, pipelines and reliable processes Analyse data, experiment and build models
Programming Python and SQL aimed at production Python or R aimed at analysis and modelling
Orchestration and transformation Airflow, dbt and ETL/ELT design Feature preparation and notebooks
Processing Spark and workload optimisation Data manipulation for analysis
Machine learning Operational integration and deployment support scikit-learn, TensorFlow and model evaluation
Cloud and infrastructure Architecture, permissions, scalability and operations Using cloud environments for analysis and experimentation
Quality of the result Availability, latency, consistency and traceability Statistical validity, useful accuracy and interpretation
Communication Data contracts, documentation and technical coordination Storytelling, recommendations and conversation with the business

The data engineer needs systems thinking. They have to anticipate what happens when a schema changes, a load runs twice, a source arrives late or a dependency fails. Orientation towards reliability matters more than an eye-catching demo. In interview, look for explanations about idempotency, failure recovery, data tests and observability.

The data scientist needs analytical curiosity and the judgement to frame questions. They have to tell a signal from an artefact, choose coherent metrics and explain a conclusion to people who do not work with models. Statistics is not CV decoration. It is the basis for interpreting uncertainty, designing experiments and avoiding misleading recommendations.

Writing the job ad without merging the profiles

Specify the problem the person will solve in their first months, without turning the ad into an endless technology list. For an engineer, describe sources, pipelines, warehouse, quality standards and operational responsibility. For a scientist, define business decisions, experiments, models, metrics and stakeholder relationships.

A sign the ad is badly framed: it requires Airflow, Spark, TensorFlow, storytelling and cloud architecture as essential for a single position.

Overlaps should show up as collaboration, not confusion. Both profiles need to understand the source data, question definitions and work with product. What changes is where the buck stops. The engineer answers for the system delivering usable data. The scientist answers for the analysis or model helping someone decide better.

When to hire a data engineer and when to hire a data scientist

The decision does not follow from whether the company is at seed, Series A or Series B by the name of the round. It follows from the real maturity of the data. A small company can have a solid base; a much better funded one can still be running on manual exports and contradictory definitions.

The practical decision tree

Start with the infrastructure. If data is scattered across the application, commercial tools and spreadsheets, if there are no reliable pipelines, or if every team calculates the same KPI differently, hire a data engineer first. A data scientist should not be spending their main capacity rebuilding the measurement system.

Then ask whether the data is already clean and accessible. If a usable warehouse exists, tables have owners, loads are predictable and teams can query consistent information, the next bottleneck may well be analytical. Hire a data scientist when nobody is turning that base into experiments, forecasts, segmentations or models that guide decisions.

At seed stage, the usual recommendation is not to hire a pure data scientist while you still cannot say with confidence where each metric comes from. The first profile should stabilise capture, modelling and access, even if early on they also support basic analysis. At Series A, if the infrastructure exists but product needs to prioritise features with evidence, a scientist can generate more value than another engineer.

At Series B the question changes. It may be necessary to expand both sides, separate ownership of platform and analytics, and prepare models for production. Add an ML engineer when the main problem is no longer discovering a model but deploying, monitoring, versioning it and keeping its behaviour in line inside the product. A hybrid profile only makes sense if the company accepts a broad remit and can prioritise it. Do not use one to paper over a deficient architecture.

As a complementary resource for defining the analytical profile, see what a data scientist is. The final decision can be summarised like this:

  • Chaotic or inaccessible data: data engineer.
  • Usable data, unanswered questions: data scientist.
  • Validated models that need to run inside the product: ML engineer, or a combination of engineering and data science.
  • Small team with broad scope: hybrid profile, with explicit objectives and no pretence of covering the whole platform.

Real salaries in Spain for both profiles

The salary band should follow the scope of the role, not the title. In Spain, one reference puts the average data scientist salary at around €43,000 gross a year, with a base of €38,000 to €48,000, a 25th percentile of €33,875 and a 75th of €55,075, according to these data scientist salary references for Spain. For a data engineer, the same comparison puts the average base between €29,000 and €44,000, with an average of €34,000 and variable pay of €2,000 to €4,000 in some estimates.

Use these figures to build a hypothesis, not to copy an offer. An engineer maintaining simple loads belongs in a different band from someone designing architecture with Spark, governing quality and answering for platform availability. A scientist focused on descriptive reporting does not carry the same market value as one who designs experiments, validates models and presents conclusions to leadership. To frame the offer, start from what Spain's pay transparency rules already require of the bands you publish.

Ranges by seniority

The published references draw wide bands:

  • Data engineer: junior, €18,000 to €26,000; senior, €42,000 to €60,000; lead or staff, €72,000 to €95,000, according to this data engineer salary guide for Spain. The skills that drive progression include Python, SQL, Airflow, dbt, Spark and cloud.
  • Another read of the market puts data engineering between €28,000 and €85,000, with a median around €50,000. Its brackets are €28,000 to €38,000 for junior, €38,000 to €50,000 for mid, €50,000 to €65,000 for senior and €65,000 to €85,000 for lead, according to Shakers' data engineer salary analysis.
  • Data scientist: junior, €30,000 to €40,000, and senior, €60,000 to €80,000 or more, according to LHH Spain. Another guide puts junior between €35,000 and €45,000, mid between €38,000 and €55,000, and senior between €60,000 and €95,000, according to this data scientist salary guide for Spain.

At mid level the gap is not automatic: €48,000 to €65,000 for a data engineer against €50,000 to €65,000 for a data scientist, according to Elektium's salary comparison. Define scope, stack, autonomy and responsibility for production first. Then fix the band, and keep headroom for someone who can lead architecture or turn models into decisions.

As a published hiring reference, data engineer vacancies appear in the €35,000 to €40,000 a year bracket, according to the salary brackets Michael Page publishes for data engineers. If the offer sits below the band the role demands, do not paper over it with generic benefits. Reduce the responsibilities, adjust the seniority, or raise the budget.

How to assess candidates in technical interviews

A data interview fails when it asks the candidate to list tools. The process should reproduce problems the person will meet on the job, with enough information to watch how they reason, ask and decide.

An exercise for a data engineer

Hand over a small schema with product events, state changes and duplicate records. Ask them to design a pipeline in Airflow or dbt that loads the data into a queryable model, to explain how they would detect late-arriving records, and to define what happens if the job runs twice.

Assess four things:

  • Design: separates ingestion, transformation and consumption, and justifies the decisions.
  • Idempotency: avoids duplicates and makes a re-run harmless to the result.
  • Quality: proposes tests on required fields, uniqueness, freshness and relationships.
  • Operations: explains alerts, retries, backfills, cost and failure recovery.

Add a SQL query that forces them to join several tables and resolve an ambiguous business condition. For profiles with Spark experience, present a slow job and ask for a diagnosis. You are not looking for memorised syntax. You are looking for a candidate who asks about volume, partitioning, the execution plan and the expected behaviour.

Green flags: talks about data contracts, observability, documentation, ownership and consequences for consumers. Red flags: focuses on "it works locally", ignores repeated loads, or treats quality as a manual clean-up at the end of the process.

An exercise for a data scientist

Use an anonymised business dataset and frame a concrete decision, such as prioritising users for a commercial action or evaluating a product change. Ask for a brief exploratory analysis, a proposed A/B experiment, and an explanation of the metrics they would use to judge the result.

Then present two models with different results and ask which they would pick. A solid answer does not simply choose the higher metric. It weighs class distribution, the cost of false positives and negatives, stability, interpretability, leakage, and whether the model can actually run in operation.

The final part should be a presentation to a non-technical stakeholder. The candidate has to explain what they know, what they do not, and what decision they recommend. Green flags: connects the analysis to an action, identifies assumptions and communicates uncertainty. Red flags: promises causality from correlations, optimises a metric with no context, or cannot explain a relevant variable.

A good interview does not ask whether the candidate knows a library. It checks whether they can produce a reliable result under constraints resembling the job.

Use a common rubric for all candidates, but separate the criteria by role. That reduces the bias towards whoever speaks best and stops you hiring the wrong profile off a brilliant but irrelevant demonstration.

Job descriptions and a team structure that works

A data job ad should let the candidate understand the problem before the first call. Replace "we are looking for someone passionate about data" with a concrete mission, measurable responsibilities and the level of autonomy expected. The description should also make clear which decisions the role will own and which teams it will work with.

Template for a data engineer

Mission: build and operate the platform that integrates product, business and operations data.

Responsibilities:

  • Design and maintain ETL/ELT pipelines with Python, SQL, Airflow and dbt.
  • Improve data quality, documentation, observability and accessibility.
  • Work with product and engineering to define events, models and contracts.
  • Optimise processes on the warehouse or processing technologies such as Spark.
  • Take part in cloud, security and architecture decisions.

Requirements: hands-on experience with Python and SQL, data design, orchestration and incident resolution. For senior profiles, ask for architectural autonomy and the ability to set standards. Avoid an endless list of certifications that predicts nothing about daily performance.

Template for a data scientist

Mission: turn reliable data into analysis, experiments and models that improve product or business decisions.

Responsibilities:

  • Frame hypotheses with product, marketing or operations.
  • Run exploratory analysis and modelling with Python or R.
  • Design experiments and evaluate metrics with statistical judgement.
  • Build models with scikit-learn or TensorFlow where the case justifies it.
  • Communicate conclusions to technical and non-technical stakeholders.

Requirements: applied statistics, SQL, machine learning, experimental capability and clear communication. Define whether the role centres on analytics, product, risk or research. "Data scientist" with no decision area attracts wildly different applications and makes profiles hard to compare.

How to organise the team

In a startup still building its operational base, hire a data engineer first. Without reliable pipelines, the scientist will spend their time correcting data instead of producing useful analysis. In a growth phase, engineer and scientist work well with separate ownership and a direct line to product.

In a mature organisation, add an ML engineer or MLOps if models have to be maintained inside production systems. The org chart should follow the real bottleneck, not a hiring trend.

Do not let the scientist administer pipelines, and do not hand the engineer modelling objectives with no prepared data and no time allocated. Kulturo works with CTOs and tech leads on specialised technical recruiting in Spain.

Review your current job ads, remove the requirements that merge responsibilities, and describe the outcome each role has to deliver. A good structure connects mission, technical exercise, autonomy and growth stage.

We have the professional you need

Tell us the profile you need and we send candidates in under a week.

Start hiring