Six question sets written for the employer side of the table: 40+ questions with the reason each one is worth asking and what a strong answer sounds like, plus a live work sample and an eight-area scorecard. Download as DOCX.
The first data engineer I interviewed talked for forty minutes about a streaming architecture I did not understand, and I came out of the room impressed. I had graded fluency. What I needed was somebody who could make one nightly load finish correctly, every night, without me finding out from a customer that it had not.
The interview that finally worked was not more technical. It was more specific. What happens if this pipeline runs twice? How did you find out the numbers were wrong that time? What would you deliberately not build in your first ninety days? Those questions have answers an owner can grade, and they are extremely hard to fake.
At FirstHR, we build for companies hiring technical people without an HR department, where the founder runs the whole loop between everything else. This page gives you 40+ interviewer questions in six sets, each with the reason it is worth asking and what a strong answer sounds like. If you still need the posting, start with the data engineer job description.
TL;DR
A data engineer interview has to test five things: pipeline design and reliability, SQL and data modeling, data quality and incident ownership, cloud tooling and cost judgment, and stakeholder communication. Ask the same core questions of every candidate, force named examples instead of philosophies, run a 30-minute live exercise on a real problem of your own, and score eight areas from 1 to 5 with written evidence.
What the Interview Has to Test
A data engineer is hired to make data arrive correctly and keep arriving, so the interview should weight reliability and correctness above framework knowledge. The five dimensions that predict whether the hire works are pipeline reliability, SQL and modeling, data quality ownership, cost and tooling judgment, and communication with the people who use the output.
Most interviews get this backward. Technical depth is the easiest thing to test, so it expands to fill the loop, while the dimensions that actually break at a small company (does anyone notice when the numbers are wrong, does this person write anything down) get five minutes at the end. A structured interview with a dedicated stage per dimension fixes that.
The Two Questions That Do the Most Work
If you only get twenty minutes, ask these. First: what happens if this pipeline runs twice on the same input? Second: tell me about a time wrong data reached a report or a customer, how you found out, and what you changed so it could not repeat. The first question is the cleanest test of whether someone has actually operated pipelines, because idempotency is invisible in tutorials and unavoidable in production. The second one gets you an honest incident story or a claim that it has never happened, and both answers tell you something. Neither requires you to grade code.
Which Data Engineer Are You Hiring?
Data engineer covers at least four different jobs, and the weighting of your questions should change with each one. Settle which one you are filling before the first interview, because a candidate who is excellent for one version can be a poor fit for another with an identical resume.
Version of the role
What the interview should weight most
First data hire, no infrastructure
Scoping from nothing, ruthless simplicity, documentation, stakeholder work
Cloud architecture, warehouse spend, access control, build versus buy
The first row is the one small companies most often get wrong. A first data hire spends their opening months writing ingestion jobs, cleaning inputs, and building one report the business will trust, and a candidate arriving from a mature data organization may never have done any of it personally. Ask directly what they built themselves.
The questions below are grouped into five competencies plus a scorecard. A genuine data engineer performs across all five, not only on the technical sets they have rehearsed, so pull at least two questions from every group and ask them of every candidate.
Pipeline Design and Reliability
Does it run tomorrow?
Idempotency, schema drift, backfills, and failures they have actually lived through. The set that predicts your nightly load either finishing or not.
SQL and Data Modeling
Will the numbers agree?
Facts, dimensions, changing values, duplicates, and slow queries. The part of the job that never goes away and quietly decides whether your reports match.
Data Quality and Incidents
Who owns correctness?
Tests, alerting, and a real incident where wrong numbers reached someone. The failure mode that costs a small company more than an outage does.
Cloud, Tooling, and Cost
What will this cost?
Stack choices, warehouse spend, build versus buy, secrets, and access to production data. Decisions you pay for monthly and live with for years.
Stakeholder and Work Sample
Can they work alone?
Pushing back on requests, translating constraints, prioritizing without a manager, plus a 30-minute live exercise on a real problem of yours.
Scorecard and Red Flags
Score, do not guess
Eight areas at 1 to 5 with a required evidence line per score, and an eight-item red-flag checklist. The asset most question lists leave out.
Do Not Interview on Tool Names
A list of technologies on a resume tells you what a candidate has been near, not what they have operated. Asking which orchestration tool or warehouse they prefer produces an answer everyone can give, and it rewards the candidate who reads release notes over the one who has been paged at 3 a.m. Ask instead what they operated, what they disliked about it, and what broke. Real operators have complaints and specific war stories. Enthusiasts have only feature lists. The same principle applies to cloud platforms: what matters is whether they can run one, not whether it matches the logo on your invoice.
40+ Questions and a Scorecard to Download
Download all six as a single Word document or copy individual sets. Each set lists the questions to ask, why the set matters, why each question is worth asking, and what a strong answer sounds like. The final file is the scorecard with the red-flag checklist.
Download All Questions and the Scorecard
Five question sets by competency, a live work sample, and an eight-area scoring rubric. All in one DOCX.
Set 1: Pipeline Design and Reliability
Idempotency, schema drift, backfills, orchestration, and a real production failure. Worth asking because almost every data engineering problem a small company actually feels is a reliability problem.
Pipeline Design and Reliability Questions
DATA ENGINEER INTERVIEW: PIPELINE DESIGN AND RELIABILITY
Candidate: __
Interviewer: __
Date: __
WHY THIS SET MATTERS
Almost every data engineer failure a small company actually feels is a
reliability failure: the nightly load did not finish, it finished twice, or it
finished with half the rows and nobody noticed until a customer asked. This set
tests whether the candidate builds pipelines that survive contact with real
upstream systems, not whether they can recite a framework feature list.
QUESTIONS TO ASK
1. Walk me through a pipeline you built end to end. Where did the data come
from, what did it do to it, and who consumed the output?
Why ask: it is the fastest way to find out whether they built the thing or
maintained someone else’s.
Strong answer: names the sources, the schedule, the transformations, the
destination tables, and the specific people or dashboards downstream.
2. What happens if that pipeline runs twice on the same input?
Why ask: idempotency is the single most useful concept in the job and the
most common gap in candidates who learned on tutorials.
Strong answer: describes merges, upserts, partition overwrites, or dedup
keys, and explains how reruns stay safe after a failure.
3. Tell me about a pipeline that broke in production. What broke, how did you
find out, and what did you change afterward?
Why ask: past incidents reveal operational maturity better than any design
question.
Strong answer: a specific failure with a root cause and a durable fix, not
just a rerun. Bonus if the fix was a test or an alert rather than a patch.
4. How do you handle a source system that changes its schema without warning?
Why ask: at a small company nobody upstream is going to tell you.
Strong answer: schema checks, contracts, failing loudly instead of silently
dropping columns, and a habit of alerting rather than absorbing.
5. Batch or streaming for our use case, and why?
Why ask: tests judgment. Most small businesses need reliable batch, and a
candidate who reaches for streaming by default will build something you
cannot operate.
Strong answer: asks what the freshness requirement actually is before
answering, then picks the cheaper option that meets it.
6. How do you handle backfills when you change transformation logic?
Why ask: it separates people who have run pipelines for years from people
who have launched them.
Strong answer: versioned logic, partition-level reprocessing, a plan for
the cost and the runtime, and a way to verify the backfill worked.
7. How do you decide when a pipeline needs orchestration versus a scheduled
script?
Why ask: over-engineering is expensive at your scale, and so is a cron job
holding up the whole business.
Strong answer: names the trigger (dependencies, retries, visibility) rather
than defaulting to a heavy tool for everything.
WHAT A STRONG ANSWER SOUNDS LIKE
•Specific systems, specific schedules, specific tables, specific people
•Reruns are safe by design, not by luck
•Failures are detected by the system, not reported by a confused colleague
•Chooses the simplest option that meets a stated requirement
NOTES
__
__
Set 2: SQL and Data Modeling
Facts and dimensions, changing values, duplicate resolution, and a query that suddenly got slow. Worth asking because modeling decides whether your finance number and your marketing number ever agree.
SQL and Data Modeling Questions
DATA ENGINEER INTERVIEW: SQL AND DATA MODELING
Candidate: __
Interviewer: __
Date: __
WHY THIS SET MATTERS
SQL is the part of the job that never goes away, and modeling is the part that
decides whether your reports agree with each other a year from now. A candidate
can be strong on modern tooling and still leave you with tables nobody can
join. Ask these even if you cannot grade the syntax yourself; the reasoning is
gradeable by anyone who runs the business.
QUESTIONS TO ASK
1. Explain the difference between a fact table and a dimension table as if I
do not work in data.
Why ask: modeling literacy plus communication in one question.
Strong answer: plain language, a real example from their own work, no
textbook recital.
2. We have orders, customers, and refunds in three systems. How would you model
that so the finance number and the marketing number agree?
Why ask: this is the actual problem a first data hire is being hired to fix.
Strong answer: asks about definitions and grain first, then describes a
single source of truth and where the joins happen.
3. When would you denormalize on purpose, and what does it cost you?
Why ask: tests whether they hold a trade-off rather than a rule.
Strong answer: names the read performance gain and the update anomaly risk,
and ties the choice to how the table gets queried.
4. How do you handle a dimension whose values change over time, like a customer
moving to a new pricing tier?
Why ask: slowly changing dimensions are where small-company reporting
quietly goes wrong.
Strong answer: explains the difference between overwriting history and
keeping it, and asks which one the business needs.
5. Show me how you would find duplicate records in a table, and then how you
would decide which one to keep.
Why ask: the second half is the real question, and most candidates only
answer the first.
Strong answer: a window function or group-by for detection, then a business
rule for resolution rather than an arbitrary pick.
6. A query that used to take two minutes now takes forty. Where do you look?
Why ask: debugging method matters more than memorized optimizations.
Strong answer: checks data volume growth, the query plan, partitioning and
clustering, and recent upstream changes, in some sensible order.
7. How do you keep transformation code reviewable by someone else?
Why ask: at a small company the next reader may be a contractor or your
next hire.
Strong answer: version control, modular models, naming conventions, tests,
and documentation that lives next to the code.
WHAT A STRONG ANSWER SOUNDS LIKE
•Asks about grain and definitions before designing anything
•Explains modeling choices in language a non-specialist can act on
•Treats duplicates and history as business questions, not technical ones
•Writes code expecting somebody else to read it
NOTES
__
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Which tests come first, how alerting stays readable, and the first thirty minutes after somebody says the dashboard looks wrong. Worth asking because silent wrong numbers cost more than an outage.
Data Quality, Testing, and Incident Questions
DATA ENGINEER INTERVIEW: DATA QUALITY, TESTING, AND INCIDENTS
Candidate: __
Interviewer: __
Date: __
WHY THIS SET MATTERS
A pipeline that fails loudly is an inconvenience. A pipeline that succeeds with
wrong numbers is a business decision made on bad information, and it is the
failure mode that costs small companies the most. This set finds out whether
the candidate treats correctness as their job or as somebody else’s.
QUESTIONS TO ASK
1. How do you know your pipeline produced the right numbers today?
Why ask: the answer separates engineers who test from engineers who hope.
Strong answer: row counts, freshness checks, referential checks, null and
uniqueness tests, and reconciliation against the source system.
2. Tell me about a time wrong data reached a report or a customer. What
happened next?
Why ask: everyone has one. A candidate who says it never happened is either
inexperienced or not being straight with you.
Strong answer: owns it, describes the detection gap honestly, and names the
control they added so it could not repeat.
3. Which tests would you write first on a brand new pipeline, and why those?
Why ask: prioritization under limited time is the real skill at your scale.
Strong answer: starts with the cheap high-value checks (freshness, row
counts, primary key uniqueness) rather than an exhaustive suite.
4. How do you set alerting so it gets read instead of ignored?
Why ask: alert fatigue is why small teams stop noticing failures.
Strong answer: alerts on business impact, routes to a person, tunes noise
down deliberately, and distinguishes warnings from pages.
5. A stakeholder says the dashboard number looks wrong. Walk me through your
first thirty minutes.
Why ask: tests calm, method, and the instinct to confirm before rebuilding.
Strong answer: reproduces the claim, checks freshness and recent changes,
traces the number back to the source, and communicates status while working.
6. How do you document data so somebody else can trust it?
Why ask: undocumented data at a small company becomes unusable the moment
and documentation kept next to the code rather than in a stale file.
7. What is your rule for when a data issue gets escalated to leadership?
Why ask: judgment about what the business needs to know, and when.
Strong answer: a clear threshold tied to decisions or customers, not a
personal comfort level.
WHAT A STRONG ANSWER SOUNDS LIKE
•Correctness is owned, not delegated to whoever reads the dashboard
•Honest about a real incident, with a durable control added afterward
•Tests are prioritized by value, not written to look thorough
•Communicates during an incident instead of going quiet
NOTES
__
__
Set 4: Cloud, Tooling, and Cost
Stack choices, warehouse spend, build versus buy, secrets, and access to production data. Worth asking because these decisions arrive on your statement every month for years.
Cloud, Tooling, and Cost Questions
DATA ENGINEER INTERVIEW: CLOUD, TOOLING, AND COST
Candidate: __
Interviewer: __
Date: __
WHY THIS SET MATTERS
A data engineer picks tools that you will pay for every month and live with for
years. At a company with no platform team, the wrong stack is not a technical
preference, it is a recurring bill and an operational burden carried by one
person. This set tests whether they choose for your situation or reproduce the
stack from their last employer.
QUESTIONS TO ASK
1. If you joined us with almost no data infrastructure, what would you build in
the first ninety days, and what would you deliberately not build?
Why ask: the second half of the question is the one that matters.
Strong answer: one warehouse, a small number of reliable sources, one
trustworthy report, and an explicit list of things postponed.
2. Which cloud data stack have you actually operated, and what did you dislike
about it?
Why ask: real operators have complaints. Enthusiasts have only features.
Strong answer: specific tools, specific friction, no vendor evangelism.
3. What drives cost in a cloud warehouse, and how do you keep the bill from
surprising us?
Why ask: warehouse spend is one of the few technical decisions an owner
sees directly on a statement.
Strong answer: compute versus storage, query patterns, scheduled refresh
frequency, table partitioning, and monitoring spend before it grows.
4. When would you buy a managed connector instead of writing an ingestion job?
Why ask: build-versus-buy judgment at a small company is a budget skill.
Strong answer: weighs engineering time and maintenance against subscription
cost rather than defaulting to building everything.
5. How do you handle secrets, credentials, and access to production data?
Why ask: this hire will hold keys to the most sensitive data you have.
Strong answer: a secrets manager, least privilege, no credentials in code
or notebooks, and separate access for development and production.
6. How would you handle personal or regulated data in the warehouse?
Why ask: customer data and employee data both end up here.
Strong answer: minimization, masking or tokenization, restricted access,
documented retention, and knowing when to involve counsel.
7. What would you do in your first week if our only documentation is somebody’s
memory?
Why ask: this is the real starting condition at most small companies.
Strong answer: interviews the people, maps the sources, and writes down what
exists before changing anything.
WHAT A STRONG ANSWER SOUNDS LIKE
•Recommends the smallest stack that solves your problem
•Can explain cost drivers in dollars, not in architecture diagrams
•Treats production access and secrets seriously and specifically
•Starts by writing down what exists rather than rebuilding it
NOTES
__
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Pushing back on a request, translating a constraint, prioritizing without a manager, plus a 30-minute live exercise. Worth asking because half this job at a small company is not code.
Stakeholder, Ownership, and Work Sample Questions
DATA ENGINEER INTERVIEW: STAKEHOLDER, OWNERSHIP, AND WORK SAMPLE
Candidate: __
Interviewer: __
Date: __
WHY THIS SET MATTERS
At a large company a data engineer can hand a table to an analytics team and
move on. At a small company the same person has to ask the finance lead what
revenue means, say no to a request that is not worth building, and explain a
delay to a founder. This set tests the half of the job that has nothing to do
with code, plus a live exercise that outperforms a take-home.
QUESTIONS TO ASK
1. Tell me about a request you pushed back on. What was asked, what did you say,
and what happened?
Why ask: an engineer who builds everything requested will drown in your
backlog within a quarter.
Strong answer: a specific request, a reason grounded in cost or value, and a
working relationship that survived the conversation.
2. How do you find out what a stakeholder actually needs when the request comes
in as a table specification?
Why ask: the stated request is rarely the real one.
Strong answer: asks what decision the data will change, then proposes
something simpler or better than what was asked for.
3. Describe a time you had to explain a delay or a technical constraint to a
non-technical leader.
Why ask: this hire will be the only person who understands the constraint.
Strong answer: plain language, an option set rather than an excuse, and a
revised commitment.
4. What did you own end to end at your last job, and what did somebody else own?
Why ask: pins down the real scope behind an impressive title.
Strong answer: an honest boundary. Candidates from large data organizations
often owned one layer, which is fine if it is said out loud.
5. How do you decide what to work on when three people all say their request is
urgent?
Why ask: prioritization without a manager is the daily reality here.
Strong answer: a stated basis (revenue impact, blocked decisions, risk) and
a habit of making the queue visible rather than negotiating in private.
6. What part of data engineering do you not enjoy?
Why ask: the answer predicts what will quietly stop happening after month
three.
Strong answer: honest, and not one of the things this job is mostly made of.
LIVE WORK SAMPLE (30 MINUTES)
Bring one real, anonymized data problem you already have. A messy export, two
systems that disagree, or a number nobody trusts. Share the screen and ask:
•What would you ask us before you started?
•What would you look at first, and what do you expect to find?
•What is the smallest thing you could ship in a week that helps?
•What could make this wrong in a way we would not notice?
Score the reasoning and the questions they ask you, not the answer they reach.
Use the same problem for every candidate, and write the rubric before the first
interview so the comparison stays fair.
NOTES
__
__
Set 6: Scorecard and Red Flags
Eight scoring areas at 1 to 5, one line of evidence required per score, and an eight-item red-flag checklist. Worth using because a technical hire decided on impressions is the one you spend a year undoing.
Data Engineer Scorecard and Red Flags
DATA ENGINEER INTERVIEW SCORECARD
Candidate: __
Interviewer: __
Date: __
Score each area from 1 (poor) to 5 (excellent). Every score needs one line of
evidence from the interview. A score with no evidence line does not count.
Fit for a small team with no platform Score: [ 1 2 3 4 5 ]
Evidence: _____
RED FLAG CHECKLIST
[ ] Cannot describe what happens when a pipeline runs twice on the same input
[ ] No example of a production failure they caused or fixed
[ ] Treats SQL, documentation, or data cleaning as beneath the role
[ ] Recommends a heavy stack before asking what the business needs
[ ] Every project described was built by "the team" with no personal boundary
[ ] Cannot explain a modeling choice without technical vocabulary
[ ] Needs a platform team, a data catalog, or an analytics team to exist first
[ ] Has never been the person who found out the numbers were wrong
SUMMARY
Total score: ______ / 40
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Strengths: _____
Concerns: ______
Interviewer signature:
Fill this in alone, before anyone in the room says what they thought. Compare
written evidence first, then discuss.
The Work Sample That Beats a Take-Home
A live 30-minute exercise on a real problem from your business outperforms a multi-hour take-home for this role. Long assignments filter for availability rather than skill, and they hand the candidate a clean dataset with a defined task, which removes exactly the scoping and trade-off judgment you are hiring for.
Bring one anonymized problem you already have: a messy export, two systems that disagree on the same total, or a number nobody trusts. Share the screen and let the candidate work out loud. You are scoring the reasoning and the questions they ask you, not whether they reach the answer inside half an hour.
Ask this
What you are listening for
What would you ask us before starting?
Whether they establish the decision the data has to support
What would you look at first, and what do you expect?
A hypothesis, not a fishing expedition
What is the smallest thing you could ship in a week?
Willingness to deliver something narrow and useful
What could make this wrong without us noticing?
Instinct for silent failure, which is the expensive kind
What would you not build in the first ninety days?
Judgment about scope at a company with no platform team
If You Do Use a Take-Home, Treat It as a Selection Procedure
An exercise that decides who advances is a selection procedure, and EEOC guidance on employment tests expects selection procedures to be job-related and applied consistently. In practice that means the same problem for every candidate, a rubric written before anyone sits it, a time cap you would be comfortable stating publicly, and no request for work you could ship. Pay for anything substantial. This is general information, not legal advice.
What to Probe For and the Red Flags
The listed questions open the door; the follow-ups are where the interview happens. Push for the named table, the actual date, the specific control they added, the person who was affected. The most useful follow-up in the whole loop is some version of how did you find out?
Ownership signals
Names the tables, schedules, and people downstream
Describes a failure they found before a stakeholder did
Says clearly what they built versus what the team built
Judgment signals
Asks the freshness requirement before choosing streaming
Picks the smallest stack that meets the need
Can explain warehouse cost drivers in dollars
Follow-ups that work
How did you find out?
What did you change so it could not happen again?
What would you not build in the first ninety days?
Red flags
No answer for a pipeline running twice on the same input
Treats SQL and documentation as beneath the role
Needs a platform team to exist before delivering anything
One pattern deserves calling out on its own. A candidate who treats SQL, documentation, and data cleaning as beneath the role is describing a company you are not. At a small business those three things are most of the first year, and a reference check is the fastest way to confirm what somebody really did day to day.
Pay Context Before You Ask About Expectations
Know your band before the first screen, because compensation is the question that ends processes late and expensively. Federal wage data has no separate data engineer occupation, so the benchmark comes from the closest classification and then gets adjusted for your metro and the level you are hiring.
What the Federal Data Says About the Closest Occupation
Federal data does not track data engineer separately. The closest classification is database architects (SOC 15-1243), which lists data engineer among its reported job titles. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), database architects had a national median annual wage of $139,500, with the 10th percentile at $86,240, the 25th at $109,370, the 75th at $169,290, and the 90th at $204,000 (U.S. Bureau of Labor Statistics, OEWS). The broader occupational outlook for database and network roles is published in the BLS Occupational Outlook Handbook.
Anchor to the level rather than the headline median. An early-career first data hire sits near the 25th percentile, a solid mid-level generalist near the median, and a senior engineer who will own the entire platform alone sits toward the 75th. Say the range out loud in the first screen; a candidate who is out of range will tell you in thirty seconds and save you four rounds.
Fair, Legal, and Structured Interviewing
A fair interview and an accurate one are the same interview. Asking the same job-related questions of every candidate keeps you compliant, reduces bias, and gives you a better read, because the comparison between candidates finally means something.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that probe them create risk even when they arrive as friendly small talk. Technical interviews drift here more easily than most, usually through resume chat: what year did you graduate, where are you originally from, is your family here, how do you manage on-call with young kids. Keep every question tied to building and running data pipelines. You may ask whether the candidate can perform the essential functions of the job and whether they are legally authorized to work in the United States. This is general information, not legal advice.
Same core questions, every candidate
A structured interview, where every candidate answers the same questions scored against the same rubric, predicts on-the-job performance far better than a conversation that goes wherever the rapport takes it. On technical hires the gap is wider than usual, because shared vocabulary is easy to mistake for capability, and a candidate who talks like your last good engineer can feel like a match without demonstrating anything. Write the question set before the first interview, ask it of everyone, and score it. The downloadable sets and scorecard here exist to make that the path of least resistance.
Treat a take-home as a selection procedure
If an exercise decides who advances, it is a selection procedure, and it should be job-related, applied consistently, and scored against a rubric written before anyone sits it. For data engineers the practical implications are specific: use the same problem for every candidate, cap the time and mean it, do not ask for work you could actually ship, and pay for anything substantial. A 30-minute live exercise on a real anonymized problem gives you more signal than a six-hour assignment, and senior candidates decline the long ones anyway, which filters for availability rather than skill.
Score alone, then discuss
When more than one person interviews, have each interviewer complete the scorecard independently before the group talks. This stops the most senior or most technical voice from anchoring everyone, which is the usual way a strong candidate gets talked out of and a fluent one gets talked into. Require one line of written evidence per score, then compare the evidence before comparing opinions. For an owner who is also the hiring manager, the scorecard is the discipline that keeps a single impressive answer from carrying an entire decision it should not carry.
Structure Beats Rapport, Especially on Technical Hires
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Asking the same job-related questions of everyone also keeps you inside the EEOC's rules against basing decisions on protected characteristics. On technical hires the gap is wider than usual, because shared vocabulary is easy to mistake for capability.
Keep the small talk off graduation years, family plans, and where somebody is originally from. Our guide to illegal interview questions covers the full list and what to ask instead. This is general information, not legal advice.
Interviewing a Data Engineer Without HR
At a large company this candidate runs a coordinated loop with a recruiter managing scorecards and a panel of engineers who can grade every answer. At a small company the founder usually runs the interview alone, cannot grade half of it, and has to decide anyway. Here is how to make that work.
You cannot grade half of what the candidate says
You do not have to. Four signals are gradeable by anyone who runs the business: whether the candidate asked what decision the data would change, whether they explained a modeling choice in plain language, whether they can name a failure they caused and the control they added, and whether they told you what they would deliberately not build in the first ninety days. Those separate strong data engineers from fluent ones more reliably than a whiteboard round you cannot score. Borrow one senior technical friend for a single 45-minute round if you want depth on the code, and use a reference call for the rest.
The candidate is picturing a job you do not have
Someone arriving from a large data organization may have owned one layer of a mature platform, with a separate team for ingestion, another for the warehouse, and analysts who never asked them for a dashboard. At your company the same person writes the ingestion job, models the tables, fixes the numbers, and explains the delay to you personally. That is a fine job for the right candidate and a miserable one for the wrong candidate, and the only way to find out is to describe it plainly in the first screen and ask directly what they built themselves.
The pipeline outlives the person who built it
A single data engineer at a small company accumulates institutional knowledge fast, and if none of it is written down, their departure takes your reporting with it. Interview for the habit rather than hoping it appears later: ask how they document, ask what they would write first, and make documentation an explicit expectation in the offer rather than a nice-to-have discovered in month eight. Then keep the interview scorecards, the offer, and the signed paperwork in one place, so the next hiring round starts with a record instead of a memory. Applicant tracking is coming soon to FirstHR.
If the role is closer to reporting than to pipelines, compare these questions against the data analyst job description before you run the loop, and browse the rest of the hiring templates for the adjacent roles.
From Interview to Offer
Once the scores are in, the work shifts from evaluating to hiring well. A technical hire who will be your only data person needs the terms in writing and a real plan for the first quarter, because a vague mandate at this level costs months before anybody notices it was vague.
Fix the question set first
Choose the sets that match the version of the role you are filling, write the weighting on the scorecard, and ask the same core questions of every candidate.
Score alone, with evidence
Eight areas at 1 to 5, one line of evidence per score, completed independently before anyone in the room says what they thought.
Put the scope in writing
Confirm compensation, the reporting line, on-call expectations, and what this person owns end to end, signed electronically so nothing lives in a verbal promise.
Plan the first ninety days
One warehouse, a short list of sources, one report the business will actually trust, and a named stakeholder for each. Vague mandates cost a quarter.
Put the ownership boundary and any on-call expectation into the offer letter alongside compensation, then hand the new engineer a written 30-60-90 day plan naming the first report the business needs to trust. Those two documents prevent most of the misalignment that surfaces in month four.
FirstHR connects the offer, the signatures, the paperwork, and the onboarding workflow in one place, and keeps the signed documents and interview records on the employee profile, so a company without HR can run hiring through to a productive first quarter from one system. FirstHR is an onboarding and HR platform, not a payroll provider and not a data tool. Applicant tracking is coming soon to FirstHR.
Keep the completed scorecards. When a technical hire does not work out, the written evidence from the interview is what tells you whether you asked the wrong questions or ignored the right answers, and the next loop gets sharper because of it. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Interview a data engineer on five dimensions: pipeline reliability, SQL and modeling, data quality ownership, cloud and cost judgment, and stakeholder communication.
Decide which version of the role you are filling first, because a first data hire, a pipeline specialist, an analytics engineer, and a platform owner need different question weightings.
Ask what happens when a pipeline runs twice on the same input; idempotency is invisible in tutorials and unavoidable in production.
Ask for a real incident where wrong data reached a report, and score the control they added afterward rather than the apology.
Run a 30-minute live exercise on a real anonymized problem instead of a multi-hour take-home, and score the questions the candidate asks you.
Federal data has no data engineer occupation: benchmark against database architects at a $139,500 median and a $169,290 75th percentile (BLS OEWS, May 2025), then adjust for level and metro.
Frequently Asked Questions
What questions should you ask a data engineer in an interview?
Ask across five areas: pipeline design and reliability, SQL and data modeling, data quality and incident handling, cloud tooling and cost, and stakeholder communication. The highest-signal questions are specific rather than theoretical: walk me through a pipeline you built end to end, what happens if it runs twice on the same input, tell me about a time wrong data reached a report, and what would you deliberately not build in your first ninety days. Skip trivia about framework internals, because the job is judgment and operations rather than recall, and a candidate can fail a definition quiz while running your data platform perfectly well. Every question on this page comes with a stated reason it is worth asking and a note on what a strong answer sounds like, so whoever runs the interview can score it consistently.
How do you interview a data engineer if you are not technical?
Grade the things you can judge without the vocabulary, and borrow help for the rest. Four signals separate strong data engineers from fluent ones and need no technical background to assess: whether the candidate asked what decision the data would change before designing anything, whether they explained a modeling choice in plain language, whether they can name a failure they caused and the specific control they added afterward, and whether they told you what they would deliberately not build in the first ninety days. For code depth, bring one senior technical person from your network in for a single round, or run a reference call with a former colleague. Then run a live 30-minute exercise on a real problem from your own business and score the questions the candidate asks you rather than the answer they reach.
What is the difference between a data engineer, a data analyst, and a data architect?
A data engineer builds and operates the pipelines that move and transform data so it can be used. A data analyst uses that data to answer business questions, build reports, and recommend decisions. A data architect designs the blueprint: what data you hold, how it is modeled, where it lives, and how the pieces connect. At a large company these are three separate hiring bars with three separate interviews. At a small company one person often does all three, and confusion between them is the most common reason a data hire disappoints. Decide which need is most pressing before you interview. If your problem is that nobody trusts the numbers and the nightly load keeps failing, you want an engineer. If your problem is that nobody is asking the right questions of data you already have, you want an analyst.
Should a data engineer interview include a take-home assignment?
A live 30-minute work sample usually beats a take-home for this role. Long unpaid assignments filter for availability rather than skill, and strong candidates with options decline them. They also test the wrong thing: a clean dataset with a defined task removes the scoping, trade-off, and communication work that a small company is actually hiring for. Instead, bring one real anonymized problem you already have, share your screen, and ask what they would ask before starting, what they would look at first, what they could ship in a week, and what could make the result wrong in a way you would not notice. If you do use a take-home, cap it strictly, use the same problem for every candidate, write the rubric before anyone sits it, and pay for anything substantial.
What are the red flags in a data engineer interview?
Eight show up repeatedly. The candidate cannot say what happens when a pipeline runs twice on the same input. They have no example of a production failure they caused or found. They treat SQL, documentation, or data cleaning as beneath the role, which is disqualifying at a company where the job is mostly those three. They recommend a heavy stack before asking what the business needs. Every project they describe was built by the team, with no personal boundary. They cannot explain a modeling choice without technical vocabulary. They need a platform team, a catalog, or an analytics function to exist before they can deliver anything. And they have never been the person who discovered the numbers were wrong, which usually means nobody was checking.
How long should a data engineer interview process be?
Three or four stages inside two to three weeks is a reasonable target for a small company. Start with a 30-minute screen covering scope, the hands-on reality of the job, and the compensation range, so nobody spends four rounds discovering a mismatch. Follow with a technical round on pipelines, SQL, and modeling, then a quality and incident round, then a final session combining the live work sample with the people this hire will work beside every week. Score after each stage while the answers are still fresh rather than at the end. Data engineers are in a competitive market and drop out of slow processes, so compress the calendar rather than the content, and tell the candidate the full shape of the loop up front.
What questions are illegal to ask a data engineer candidate?
Do not ask questions that probe characteristics protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, or genetic information. Technical interviews drift into this territory through resume small talk more often than through deliberate questioning. Avoid asking what year someone graduated, where they are originally from, whether their family is here, whether they plan to have children, how they would manage on-call around childcare, or any health or accommodation question outside the essential functions of the job. You may ask whether the candidate can perform the essential functions and whether they are legally authorized to work in the United States. Asking the same job-related questions of every candidate is the simplest protection. This is general information, not legal advice.
What should you pay a data engineer?
Federal wage data has no separate data engineer occupation, so benchmark against the closest classification, database architects, which lists data engineer among its reported job titles. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), database architects had a national median annual wage of $139,500, with the 10th percentile at $86,240, the 25th at $109,370, the 75th at $169,290, and the 90th at $204,000. The spread maps closely onto seniority and metro, so anchor to the level you are hiring rather than to the headline median: a first data hire who is early in their career sits near the 25th percentile, a solid mid-level generalist near the median, and a senior engineer who will own the whole platform alone toward the 75th. State the range in the first screen. This is general information, not legal advice.
