What senior actually means
Senior is not a number of years, and it is not a long list of tools. A senior data engineer is someone you can hand an ambiguous workstream and trust to come back with something that runs, that others can maintain, and that the business believes.
In practice, that shows up in a few places:
- Decisions that are costly to reverse. How data is modelled, how it is partitioned, how late or bad data is handled, how much the platform will cost to run. A senior engineer makes these deliberately and can explain the trade-off.
- Data quality as part of the job. They expect sources to be wrong, test for it, and notice a problem before the business does.
- Ownership. They break down unclear work, ask the questions that matter early, write things down, and leave systems that someone else can run.
- Judgment about what not to build. They will tell you when a simpler pattern, or an existing tool, does the job.
Our position: you cannot see any of this in a conversation alone. You have to see the work.
Why the usual process misses it
- Keyword matching. A screen that checks for the right tools on a resume finds people who have used the tools, not people who used them well.
- The wrong screener. A first screen run by someone who has never built a pipeline cannot tell a confident answer from a correct one.
- Puzzles. Algorithm puzzles test something real, but it is not the ability to build a reliable pipeline on messy data.
- Unpaid take-home projects. Large, unpaid assignments put off exactly the experienced people you want, and they tell you little about how someone works with your team.
- References that confirm dates. A call that establishes someone worked somewhere tells you nothing about what they delivered.
The fix is three checks, each designed to see a different part of the work: a technical screen, a paid trial task and a check of past engagements. They are the same three we use for our own bench.
Check one: a technical screen by a practitioner
Who runs the screen matters more than the questions. It should be a senior practitioner who does the same work, because only they can hear the difference between a rehearsed answer and lived experience. Ask about real systems and real failures, and follow the answers down.
- Walk me through a pipeline you built that is still running. What would you change now?
- A source system starts sending duplicate records. How do you find out, and what do you do?
- How do you handle data that arrives late, and how do you run a backfill safely?
- How would you model this entity when its attributes change over time?
- Tell me about a platform that cost more than it should have. What drove the cost, and what did you do?
- How do you test a pipeline, and what do you monitor once it is live?
Listen for specifics: names of tables, failure modes, numbers they watched, decisions they regret. Strong candidates describe trade-offs. Weaker ones describe tools.
Check two: a paid trial task on real work
The trial task is where most of the signal comes from. Done well, it shows how someone works, not how they interview. Design it with five properties.
- Paid. You are asking for real work, so pay for it. It also signals that you respect the candidate's time.
- Real. Use a genuine problem from your backlog, or a realistic slice of one, under a confidentiality agreement and with access limited to what the task needs.
- Small. Scope it so a strong engineer can finish it in a short, agreed time. The point is to see quality, not stamina.
- Deliberately imperfect. Include the kind of mess real data has: a missing field, a duplicate, an ambiguous definition.
- Reviewed by a practitioner. Against criteria written down before the work starts.
What to look at in the result: Is it correct? Is it tested? How did it handle the bad data? Is it documented well enough for someone else to run? And, often the most telling, what did they ask before they started? A senior engineer asks about definitions, volumes and who will use the output. A less experienced one starts building.
Check three: past engagements
Treat this as a check of delivered work, not of character. Ask the candidate to name two or three things they built, and then ask about those things specifically, with the people who worked alongside them where possible.
- What did they build, and what part of it was theirs?
- Is it still running? Who runs it now?
- What happened the first time it broke?
- Did the business trust the numbers it produced?
- Would you give them an ambiguous workstream again?
The answers either line up with what you saw in the screen and the trial task, or they do not. Inconsistency is information.
A scorecard for the decision
Write the criteria down before the first candidate, and score each one on evidence from the three checks. It keeps the decision about the work rather than about rapport.
| Area | Strong signal | Weak signal |
|---|---|---|
| Data modelling | Explains the trade-off behind a design, and when they would choose differently | Names a pattern without saying why |
| Data quality | Tests for bad data by default and describes real failures they caught | Assumes the source is right |
| Reliability | Talks about monitoring, backfills and safe reruns | Talks only about the happy path |
| Cost | Knows what drove the bill on a past platform | Has never looked |
| Communication | Asks about definitions and users before building; documents decisions | Starts coding at once; leaves no notes |
| Ownership | Past work still runs, and others can maintain it | Past work was rewritten after they left |
Red flags
- Every past project was a success, and nothing ever broke.
- Answers stay at the level of tool names, however far you follow them down.
- No questions before starting the trial task.
- A trial result with no tests and no handling of the bad data you planted.
- Nobody from past work can describe what the candidate actually delivered.
Running all three checks well takes senior time, which is the scarce thing you were trying to add. If you would rather not run them yourself, our staff augmentation bench is vetted this way before anyone is put forward, and you still interview everyone we propose. Where the person sits matters too; see Nearshore or offshore for data and AI work.
