Hiring a data engineer means evaluating something most interview processes never touch: whether this person has kept production data systems running, and what it cost them to learn how. The stakes are asymmetric. An application bug fails loudly and gets rolled back; a bad pipeline fails quietly, and the finance report built on it stays wrong for a quarter before anyone traces the number back. So the hiring process has to test for operational judgement, not just tool familiarity, and this guide covers how: what senior actually means for this role, which CV signals hold up, which interview questions separate builders from operators, and what the market currently charges.
Why this is not a software engineering hire with different keywords
The instinct to run your standard engineering loop with “Spark” swapped in for “React” is where most mis-hires start.
Application code and production pipelines break differently. An application serves requests and its failures are visible within seconds. A pipeline serves downstream consumers who may not look at the output for days, across source systems the engineer does not control and that change without notice. The core skill is defensive: asserting freshness on sources, making tasks idempotent so a rerun cannot double-count, designing for the backfill before the backfill is needed.
There is also a cost dimension that application work rarely has. In a modern warehouse, one badly written query pattern is a budget line. A dashboard on a five minute refresh scanning an unclustered multi-terabyte table will burn compute quietly until finance escalates it, and unwinding that pattern after it is embedded in six downstream pipelines is a project. A senior data engineer prices queries the way an application engineer profiles latency, and your interview should find out whether the candidate has ever been accountable for a platform bill.
What “senior” means, in evidence rather than years
Mahala’s threshold for senior is five to six years minimum of production experience, but years are the entry condition, not the definition. The distinctions that matter show up as evidence:
They have owned a pipeline at 3am. Not “worked on a team that had on-call”, but personally carried the pager for data systems and can walk you through a specific incident: what broke, what the blast radius was, what they changed so it could not recur. Candidates who have only built systems, never operated them, talk about architecture; operators talk about failure.
They have survived schema change. Source systems change without warning. A senior candidate has a concrete answer to how they handled an upstream team renaming a column on a Friday, and the answer involves contracts, tests, or staged rollout rather than heroics.
They can say no to a pipeline. Mid-level engineers build what is asked. Senior engineers ask what the data is for, and can name a case where the right answer was a view, a contract change, or nothing at all. This is judgement, and it is the difference between a warehouse and a swamp of 400 unowned models.
They think in cost. They can tell you what their last platform cost per month, roughly, and what they did that moved the number.
Reading the CV: signals that hold up and signals that do not
“Snowflake” on a CV proves exposure. It does not tell you whether the candidate designed the clustering strategy or wrote queries against tables someone else maintained. The signal is in the framing: named systems with scale, duration, and consequence (“built and ran the ingestion layer for X sources, Y years, cut load times from A to B”) holds up; a paragraph of tool names does not.
Three CV patterns worth weight: production tenure on the same system (staying two years past go-live means they lived with their own decisions), regulated-environment experience (banks and insurers teach evidence discipline that transfers), and migrations completed rather than started.
Three that deserve less weight than they get: certifications without production stories attached, a long list of orchestration tools (fluency in one is worth more than exposure to five), and greenfield-only histories, because an engineer who has never inherited someone else’s pipeline has skipped the hardest part of the job.
References are not a formality for this role. Ask the reference one question above all: would you put this person on call for your data platform again?
Interview questions that separate builders from operators
Generic data engineer interview questions test recall. These test judgement, and each one has a follow-through that is hard to fake:
“Walk me through the worst data incident you owned.” Listen for blast radius awareness, for whether they mention the downstream consumers, and for what changed afterwards. An answer with no process change is a story, not an incident review.
“A backfill of 18 months of data has to run this weekend. What do you check before you start it?” Good answers cover idempotency, concurrency limits against production load, cost estimation, and a rollback plan. Candidates who have never run a real backfill start describing the happy path.
“The numbers in the CFO’s dashboard are wrong. Walk me through the first hour.” This tests debugging order: check freshness first, then recent deploys, then upstream changes. It also reveals whether they communicate during an incident or only after solving it.
“What did your last platform cost, and what would you have changed about it?” Any real number with reasoning beats a polished non-answer.
“When would you refuse to build a requested pipeline?” Tests whether they see the warehouse as a product with an owner or a ticket queue.
Add one practical exercise on your actual stack, scoped to an hour, reviewing a flawed pipeline design rather than writing one from scratch. Review exposes judgement faster than greenfield coding, and it respects the candidate’s time.
Screening that catches wrong-fit candidates before they cost you
A structured process beats interviewer intuition for this role because the failure modes are specific and checkable. At Mahala the assessment is discipline-specific and scored, with 75 out of 100 as the pass mark, and evidence from the interview is cross-checked against the CV and followed up with references rather than taken on trust. One in seven candidates clears the process. The most common reason for failing is not weak SQL; it is a portfolio of proofs of concept with nothing that ran unattended, which is exactly the profile that interviews well and fails in month three.
Whatever process you run internally, keep two of its properties: score against written criteria decided before the interviews, and verify at least one claimed system with a reference who worked downstream of it. The downstream consumer knows the truth about a pipeline in a way the engineer’s manager sometimes does not.
The dimension most teams skip: consulting fit
A data engineer in an enterprise team spends a surprising share of the week outside the codebase: scoping a vague request from an analyst, explaining to a product owner why real-time is not worth 40 thousand a month for this use case, walking an auditor through lineage. In a regulated environment this is not a soft skill, it is load-bearing.
Test it directly. Give the candidate an ambiguous stakeholder request from your real backlog and ask them to scope it in conversation. You are listening for clarifying questions, an explicit trade-off, and a recommendation with a reason. A candidate who jumps straight to the technical design without asking what the requester is trying to decide will do the same thing on your team, at production prices. This is one of the four categories in Mahala’s vetting, and it fails otherwise strong engineers regularly.
What a senior data engineer costs
For the contract market: the median day rate for data engineer contracts in the UK was 500 pounds in the six months to August 2026, per ITJobsWatch. Treat that as one market’s midpoint rather than a universal price. Rates climb with platform scarcity (Databricks and Foundry specialists price above generalists), with regulated-environment experience, and with genuine streaming expertise, and they differ across the EU and GCC markets.
The number to hold next to the rate is the cost of the alternative: three to six months of recruiting pipeline for a permanent senior, plus the risk that the hire you finally make is the polished-interview profile the process above is designed to catch.
Doing it yourself vs hiring through a specialist
Everything above is doable in-house if you have a senior data practitioner to run it. That is the catch: the process needs someone who can score the backfill answer, and teams hiring their first senior data engineer usually do not have that person yet, which is circular.
A specialist network breaks the circle by doing the technical vetting before you see anyone. At Mahala, a brief gets a first response within 24 hours and a shortlist of two to three blind CVs of pre-vetted remote senior Data Engineers within 72 hours, so your interviews start from “which of these fits us” rather than “is this person real”. The full process is at how it works, and what the role covers in practice is on our data engineering page.
