Hire Data Engineers: Rates, Vetting and What Good Looks Like

What a data engineer does, and where hiring goes wrong

A version of this plays out at most companies we walk into. Monday morning, the CEO opens the revenue dashboard and sees $412,000 for last week. Finance has $451,000 in their sheet. Nobody can explain the gap during the meeting, so people quietly stop opening the dashboard, and six months of tooling spend turns into decoration.

The causes are usually mundane. The Fivetran connector re-synced the orders table and duplicated rows for a partial day. The dbt model was incremental on order_id but never handled the refund that arrived nine days after the original order. The warehouse stores timestamps in UTC, the dashboard filters by local date, so Sunday night orders fell into the wrong week. Three small correctness bugs, one broken dashboard, one lost quarter of trust.

Preventing that is the work. A data engineer moves data from source systems into a warehouse such as Snowflake, BigQuery, Redshift or Databricks, models it into tables an analyst or a BI tool can query without thinking, and keeps the numbers right at 6am on a Tuesday when a source system changed its schema overnight. The code is SQL, dbt, Python, some Airflow or Dagster, some Terraform. The skill is defensive thinking about data that lies to you.

Hiring goes wrong in a predictable way: companies hire for tool logos instead of for correctness. The resume says Kafka, Spark, Airflow, Kubernetes. The company has 40 GB of Postgres data and needs eleven dashboards. Six months later there is a streaming architecture nobody can debug, a $9,000 monthly warehouse bill, and finance still keeps their own spreadsheet. The engineer was competent. They were solving a problem the business did not have.

Engagement models and their trade-offs

In-house hire. Right when data is a permanent, daily function: your product ships data features, your analysts file requests weekly, your board looks at metrics that change decisions. The catch is that a good data engineer working alone on a greenfield warehouse builds in their own idiom, with no reviewer. If they leave in month nine, you inherit an Airflow instance only they understood. Hire in-house second, not first.

Freelancer. Good for scoped, bounded work: build the dbt project, wire up Airbyte or Fivetran, ship the first eight models, hand over. Cheapest per hour and fastest to start. The failure mode is continuity. Pipelines are not a website. They need someone at 6am when the sync fails, and a freelancer is one person with other clients and no on-call. A freelancer with nobody reviewing their SQL will also ship models that pass because they never wrote a test.

Agency. You buy a delivered outcome instead of hours: discovery, a metric dictionary, warehouse, models, dashboards, handover documentation. More expensive per hour, and the accountability sits with the agency. You also get more than one brain, typically a data engineer plus an analytics engineer plus someone doing review. Weak agencies staff one junior against your project and bill senior. Ask who is writing the dbt models, by name, and ask to interview them.

Staff augmentation. A vetted engineer works inside your team, your repo, your standups, your Jira, but is employed by the partner. This is the sweet spot for most data work, because data engineering depends on business context that only your team has. You get continuity without a headcount commitment, and you can ramp from two people down to half a person once the build stabilises. The trade-off is that your engineering manager still has to manage them. Staff augmentation with nobody steering is an expensive freelancer.

What data engineers cost

Rates move a lot with region and seniority, so treat any single number with suspicion. The bands below are what Digital Heroes quotes and pays across our own data and business intelligence delivery. They are not lifted from a published survey.

Freelance and contract hourly for a senior data engineer, meaning someone who has owned a warehouse in production and been on call for it:

• South Asia: roughly $25 to $55
• Latin America and Eastern Europe: roughly $45 to $90
• US, Canada, UK and Western Europe: roughly $85 to $165

Mid-level engineers typically sit 30 to 40 percent below those bands. Below that you are usually paying for someone who has written SQL but never handled a backfill, a schema drift or a cost incident, and the difference shows up in month three, not week one.

Agency and staff augmentation blended rates land above freelance, because you are buying review, redundancy and delivery accountability. Cheaper than a bad hire, more expensive than a lucky one.

The in-house number people quote is the base salary, and base salary is not the cost. Add employer taxes, benefits, insurance, equipment, software seats and payroll overhead. When we help clients model this, we plan on roughly 1.25x to 1.4x base depending on the country, and we add a recruiter fee on top if they use one. Then add ramp: a data engineer joining a company with no documented lineage and undocumented source systems takes four to eight weeks before their pull requests are net positive, because they have to learn what your data means before they can model it. Budget the search too. In the markets we hire from, data engineering roles routinely take one to three months to fill, because good candidates hold several offers at once.

One cost nobody puts in the budget: the warehouse bill. A careless engineer will triple your Snowflake credits or your BigQuery bytes scanned in a month with full refresh dbt runs, unpartitioned tables and a BI tool pointed at raw data. That is a real line item, and vetting for it pays for itself.

How to vet a data engineer

Skip the LeetCode. Test the three things that break in production: SQL depth, incremental correctness, and cost awareness.

Read their dbt repo before you read their resume. Ask for a project, sanitised if needed, and look for specifics. Is there layering into staging, intermediate and marts, or is it one folder of 60 models? Does sources.yml declare freshness thresholds? Are there unique and not_null tests on every primary key, and relationships tests on foreign keys? Do incremental models declare a unique_key and use is_incremental with a lookback window, or do they append naively? Is incremental_strategy set to merge wherever the grain can mutate? Are dashboards declared as exposures, so the engineer knows what breaks when a column gets dropped? Does CI run dbt build on pull requests against a small dataset, or does the model get tested in production at 3am? If they use Airflow, check whether catchup is set deliberately rather than left at the default, and whether backfills have a written procedure.

Questions worth asking. "This incremental model appends by order_id. A refund lands ten days after the original order and mutates the row. Walk me through what breaks and how you fix it." A strong answer covers merge strategy, unique_key, a lookback window on the incremental filter, and why a full refresh is the safe fallback. "Our Snowflake bill tripled last quarter, where do you look first?" You want query_history and warehouse_metering_history, warehouse sizing and auto-suspend, full refresh runs, exploded joins from a broken grain, clustering keys, and BI tools querying raw tables. On BigQuery the equivalents are partition pruning, bytes scanned per query, and whether anyone set a maximum bytes billed. "Finance is $40,000 off from the dashboard. Walk me through your first hour." You want lineage first, then the definition of revenue, then dedupe, refunds, currency conversion timing, and the timezone boundary. If their first instinct is to blame the analyst, that is your answer. "When would you not use Kafka?" is the taste question. Someone senior will happily say most of the time.

The take-home, and pay for it. Three to four hours, no more. Give them a small, deliberately dirty dataset: an orders table with duplicate rows from a re-sync, a refunds table that lands late, a currency column, timestamps in UTC. Ask for a dbt project with staging and marts, one incremental fact table, tests on the keys, and one dashboard-ready table answering net revenue by week by channel. Then review the assumptions file, not just the SQL. The candidate who writes down "I assumed refunds attach to the original order week, tell me if finance disagrees" is the one you want. That sentence is the difference between a working dashboard and a meeting where two numbers disagree.

Red flags

Everything happens in pandas inside an Airflow PythonOperator. They pull the table into memory, transform it in Python, write it back. It works at 2 GB, dies at 60 GB, and cannot be tested. Ask instead: "why not push this transformation into the warehouse as SQL?" Listen for whether they have a reason or just a habit.

Streaming and Spark for a problem that is nightly and small. If your data lands once a day and you have a few hundred gigabytes, Kafka and Debezium are a hobby, not a requirement. Ask: "what is the smallest architecture that solves this, and what would make you outgrow it?"

No tests, no alerts, no freshness checks. Ask how they know a pipeline broke and the answer is "I check the dashboard in the morning". Ask instead: "what fails silently in your current setup, and how would you know?" Silent failure is the whole risk in data work. A job that errors is fine. A job that succeeds with zero rows is what destroys trust.

Cannot talk about cost. They have never opened a query profile, never looked at bytes scanned, never sized a warehouse or set auto-suspend. This person will hand you a bill.

Treats BI as someone else's job. They ship a mart and consider it done, with no agreed metric definitions, no semantic layer, no conversation with the people reading the chart. You end up with two dashboards and two revenue numbers. Ask instead: "who agreed what active customer means, and where is that written down?"

When to hire a data engineer, and how Digital Heroes staffs it

Do not hire a data engineer if your data already sits clean in one Postgres database and you need charts. That is an analyst or an analytics engineer, and it costs less. Do not hire one if your product does not emit the events you want to measure, because there is nothing to pipe. You need a backend or product engineer to instrument first, otherwise the data engineer spends three months waiting.

Hire a data engineer when data lives in four or more systems, say Stripe, HubSpot, your app database and an ad platform, and someone is reconciling them by hand. Hire when a dashboard already exists and nobody believes it. Hire when the question "what was revenue last week" takes more than a minute to answer. If the work is mostly modelling and metrics on top of a warehouse that already exists, an analytics engineer who lives in dbt and SQL is the better and cheaper first hire. A platform data engineer only becomes necessary when ingestion, orchestration and infrastructure become their own problem.

Digital Heroes staffs this as a small pod rather than a lone contractor: a senior data engineer who owns ingestion, orchestration and cost, an analytics engineer who owns dbt models and the metric dictionary, and a reviewer on every pull request so nothing ships untested. We start with a short audit, agree metric definitions in writing before writing a single model, then build in your repo, in your warehouse account, under your billing, with CI running dbt build on every pull request. When the build stabilises, we scale the pod down to a maintenance retainer, or hand it to your first in-house hire with documentation and lineage they can read. You keep the code either way.