How to find a data engineer.

Data engineering has a vocabulary problem that hides its most experienced practitioners. Someone who has built data infrastructure since 2010 spent the first half of that career as an ETL Developer or Data Warehouse Developer, and a search for 'Data Engineer' never reaches them.

The second problem is more expensive. A great many advertised data science roles are data engineering roles in disguise: the organisation wants models but has no reliable pipelines, and the first year is infrastructure work. Naming that honestly attracts someone who wants the job as it actually exists.

Job titles worth searching

Grouped by what the person actually does, because searching all43 at once produces a result set you cannot triage. Decide which group you need first — that decision does more for the search than any string below.

Where data engineers actually are

GitHub reveals working style as much as capability here. Published dbt models, Airflow DAGs, and pipeline code show an engineer who treats data work as software — version controlled, tested, reviewed — which is precisely what modern data teams expect and what many legacy-tool practitioners have never done.

Open source contribution is the strongest available signal. The core tools in this field are open — Airflow, dbt, Spark, Delta Lake, Kafka — and contributors to the stack your team depends on are both highly capable and rarely approached. As with all maintainer outreach, a message that shows no familiarity with their work will be ignored.

The conference circuit is unusually tractable. Data Council, Coalesce, Kafka Summit, and Data + AI Summit are the main gatherings, and their speaker lists are small enough to function as a regional shortlist of senior practitioners. For the legacy pool, dimensional modelling vocabulary — Kimball, star schema, slowly changing dimensions — finds experienced people that tool-name searches miss entirely.

Boolean search strings

Written to be pasted as-is. Each one is built around an intent rather than a platform, since the useful question is what you are trying to find, not which site you happen to be on.

site:linkedin.com/in/ ("data engineer" OR "analytics engineer" OR "ETL developer") (Airflow OR dbt OR Snowflake OR Spark) "{city}"

site:github.com ("dbt" OR "airflow" OR "dagster" OR "prefect") ("models" OR "dags" OR "pipeline") -awesome -tutorial

("ETL developer" OR "data warehouse developer" OR Informatica OR SSIS OR Datastage) ("dimensional" OR "star schema" OR "Kimball") -jobs

("Kafka" OR "Flink" OR "Kinesis" OR "Pulsar") ("exactly-once" OR "event-driven" OR "stream processing") -jobs -course

("BigQuery" OR "Redshift" OR "Snowflake" OR "Databricks") ("cost optimization" OR "partitioning" OR "clustering") -jobs -sales

("speaker" OR "talk") ("Data Council" OR "Coalesce" OR "Data + AI Summit" OR "Kafka Summit") 2024..2026 -jobs

site:github.com ("contributor" OR "maintainer") ("apache/airflow" OR "dbt-labs" OR "delta-io" OR "apache/spark")

("how we" OR "lessons" OR "migrating") ("data pipeline" OR "data platform" OR "warehouse") ("scale" OR "cost" OR "reliability") -course

Mistakes that cost the most time

1. Advertising a data engineering role as data science

   This is the most common miscast in the whole data field. An organisation without reliable pipelines advertises for a data scientist, hires a modeller, and the actual first-year work turns out to be building infrastructure. The data scientist leaves. If the pipelines do not exist, the honest advert is for a data engineer, and it will attract someone who genuinely wants that work.

2. Excluding ETL developers by vocabulary

   Data Engineer is a recent title. Practitioners with fifteen years in this work spent most of it as ETL Developers or Data Warehouse Developers, and many have modelling discipline that self-taught modern-stack engineers lack. Searching only current terminology quietly removes the most experienced part of the market.

3. Treating batch and streaming as one skill

   Streaming introduces problems batch does not have — exactly-once processing, late-arriving data, watermarking, and state management under failure. A capable batch engineer needs real ramp time to reason about these correctly. If the role is genuinely real-time, the streaming experience is a requirement rather than a preference.

4. Screening on tool names alone

   Tooling in this field turns over quickly, and a competent engineer moves between orchestrators without difficulty. What does not transfer easily is the modelling discipline and the systems thinking. Screening for an exact tool match selects for keyword-matched CVs rather than for the people who will still be effective when the stack changes.

5. Confusing analytics engineers with data engineers

   Analytics engineers model data inside the warehouse, usually in SQL and dbt, and sit close to the business. Data engineers build the systems that get data there and keep them running. The roles are complementary and often confused, and hiring one when you need the other leaves a visible gap that neither can cover.

6. Underestimating the on-call reality

   Data pipelines fail at night and someone has to fix them. Candidates ask about on-call rotation, alerting quality, and how much of the job is firefighting versus building, because these determine daily experience far more than the tech stack does. Adverts that avoid the subject are read as concealing a bad answer.

Common questions

What job titles should I search for when hiring a data engineer?

Search both current and legacy terminology, because the title changed recently. Current terms include Data Engineer, Analytics Engineer, Data Platform Engineer, and DataOps Engineer. Legacy terms cover a large and experienced population: ETL Developer, Data Warehouse Developer, BI Developer, and tool-specific titles such as Informatica or SSIS Developer. Streaming specialists use Kafka Engineer, Flink Developer, and Real-Time Data Engineer. The most reliable identifiers are not titles at all but tooling names — Airflow, dbt, Spark, Snowflake, Databricks.

What is the difference between a data engineer and an analytics engineer?

A data engineer builds and operates the systems that move data — ingestion, orchestration, storage, and reliability — and needs genuine software engineering ability. An analytics engineer works inside the warehouse, modelling data into usable form with SQL and dbt, and sits closer to the business and its definitions. They are complementary rather than interchangeable: hiring an analytics engineer when the pipelines do not exist leaves the ingestion problem unsolved, and hiring a data engineer when the need is business modelling leaves the warehouse full of raw tables nobody can use.

Can an ETL developer transition to modern data engineering?

Frequently yes, and this is the most overlooked pool in the market. ETL developers often have stronger data modelling discipline than self-taught modern-stack engineers, including dimensional design, slowly changing dimensions, and data quality practice that predates current tooling. The genuine question is appetite rather than capability: the modern stack is code-first, version controlled, and tested, which is a real shift from GUI-driven tools. Candidates who have already started working in SQL and Python rather than drag-and-drop interfaces usually transition well.

Why do so many data science hires turn out to need data engineering?

Because organisations underestimate how much infrastructure precedes analysis. A company decides it needs machine learning, advertises for a data scientist, and hires someone strong at modelling — who then discovers there are no reliable pipelines, no consistent definitions, and no accessible historical data. The first year becomes data engineering work the person did not want and may not be good at, and they leave. If the foundational data infrastructure is not in place, hiring a data engineer first produces better outcomes for everyone.

Where can I find data engineers outside LinkedIn?

GitHub is the strongest source, because published dbt models, Airflow DAGs, and pipeline code demonstrate both capability and working style — engineers who version control and test their pipelines are visibly different from those who do not. Contributors to core tools such as Airflow, dbt, Spark, and Delta Lake are the highest-signal candidates available. The conference circuit is small enough to be useful: Data Council, Coalesce, Kafka Summit, and Data + AI Summit publish speaker lists that amount to a shortlist of senior practitioners.