Data Engineer Interview Guide
A structured guide to interviewing Data Engineer candidates — assessing pipeline design, data modelling, reliability and collaboration with data consumers, with evidence to look for and a practical scorecard.
Published 2026-08-26 · Reviewed 2026-08-26
Hiring a Data Engineer is hard because the work is invisible until it breaks. A good data engineer builds pipelines and infrastructure that analysts and data scientists trust; a weak one creates fragile pipelines that produce numbers no one believes. This guide focuses on pipeline design, data modelling, reliability and collaboration rather than vendor-specific platform trivia. It gives you a structured framework: evidence to look for, questions to ask with follow-up probes, and a practical scorecard.
These indicators are prompts for structured evaluation, not model answers. Candidates may demonstrate competence through different examples or approaches. An unfamiliar answer is not automatically a weak answer — use follow-up questions before reaching a conclusion. "Not enough evidence" is a valid scorecard outcome. The final decision remains with the human hiring team.
Who this guide is for
Hiring managers, data leads and engineering managers assessing Data Engineer candidates from junior to staff or principal level, especially in teams building or maturing analytics and ML platforms.
Role overview
A Data Engineer builds the infrastructure that moves, stores and transforms data. They are responsible for data pipelines, warehouse architecture, data quality, reliability and the platforms that analysts and data scientists depend on. The role requires strong software engineering skills, understanding of data modelling, and the ability to balance reliability with delivery speed. At senior levels, data engineers make architecture decisions about the entire data platform. The principles transfer between tools and platforms; specific technologies matter less than sound design judgement.
How the role varies
In small teams a data engineer often spans ingestion, modelling and operations; in larger organisations the role specialises into platform, pipeline or analytics engineering. Regulated industries add lineage, audit and governance demands. Senior engineers set platform strategy and make build-versus-buy calls; juniors focus on building and operating pipelines within an established architecture.
Written and maintained by Kippler. Published — not individually expert-reviewed.
What the interviewer should assess
A Data Engineer interview should test four areas: pipeline and architecture design, data modelling and quality, reliability and operational thinking, and collaboration with data consumers. Each matters — a brilliant pipeline builder who cannot understand what analysts need is as risky as a collaborative engineer who builds fragile systems. Resist turning the interview into vendor-specific platform trivia; a candidate who reasons well about design can learn your stack.
Role-specific competencies
Pipeline architecture and design
Can they design pipelines that are reliable, scalable and maintainable? Do they understand batch versus streaming and when each is appropriate?
Data modelling and warehouse design
Can they model data for analytical use? Do they understand how to handle data that changes over time and the trade-offs between normalisation and query performance?
Data quality and reliability
Do they think about data quality proactively, not reactively? Can they design pipelines that fail gracefully and alert on problems?
Operational maturity
Do they understand monitoring, alerting and incident response for data systems? Do they think about the operational consequences of their choices?
Collaboration with analysts and scientists
Can they understand what data consumers need? Do they design systems that serve the users, not just the engineering?
Engineering fundamentals
Do they write clean, tested code? Do they use version control, CI/CD and infrastructure-as-code appropriately?
Recommended interview structure
A 60-minute interview is a useful starting point for this role. If you can include a practical data-modelling exercise, extend to 75 minutes. Structure it in three parts: a brief career discussion (5 minutes), a pipeline architecture discussion (30 minutes), and a data modelling scenario (20 minutes). Reserve the final 5–10 minutes for the candidate’s questions. Use a realistic data problem rather than abstract questions.
Adapt this guide to your role
A junior data engineer should be tested on engineering fundamentals and willingness to learn; a senior or staff engineer on architecture decisions, platform strategy and build-versus-buy judgement. The setting matters too: a startup or SME engineer often owns ingestion through to modelling, a scale-up engineer may be scaling a fragile first system, and a large-enterprise engineer typically specialises within a broader platform team. Regulated sectors add lineage, audit and governance requirements that shape modelling and operational choices. B2B data teams often support enterprise reporting and compliance; B2C teams lean towards product analytics and ML features. IC engineers are assessed on craft and reliability; leaders on platform vision, mentoring and cross-team standards. Keep the focus on design principles — the specific tools are secondary.
Interview questions
Ask the same core questions to every candidate for this role. Use the follow-up probes to clarify vague answers and gather more evidence before scoring.
1. Walk me through how you would design a pipeline that ingests data from a transactional database, an API and a CSV upload into a single analytics warehouse.
What this is assessing: Architecture thinking. Whether they consider each source’s characteristics. Whether they think about schema, timing and failure modes.
Follow-up probes
- How would your design change if the API had strict rate limits?
- What would you monitor to know the pipeline is healthy?
- How would you handle a late-arriving record that affects historical aggregates?
Evidence that may indicate strength
- Considers the different characteristics of each source
- Thinks about schema evolution and compatibility
- Mentions idempotency and replayability
- Considers how analysts will query the result
Points that may require further probing
- Proposes a single approach for all three sources
- Does not mention failure handling
- Does not think about how the data will be consumed
- Focuses on tools rather than design
2. A pipeline you built starts producing different numbers from the source system. How do you investigate?
What this is assessing: Debugging methodology. Whether they approach the problem systematically. Whether they think about data quality, not just code.
Follow-up probes
- How would you communicate the discrepancy to downstream consumers?
- What would you do if the root cause turned out to be an upstream schema change?
- How would you decide between fixing forward and reprocessing history?
Evidence that may indicate strength
- Starts by isolating where the divergence occurs
- Checks for schema changes, data type issues, transformation logic
- Looks at the pipeline logs and error history
- Thinks about how to prevent it recurring: schema validation, alerts
Points that may require further probing
- Guesses at the cause without a systematic approach
- Does not mention checking the source system
- Focuses on the code without considering data quality
- Has no plan for preventing recurrence
3. How do you decide between batch and streaming for a new pipeline?
What this is assessing: Whether they understand the trade-offs. Whether they think about the business need, not the technology preference.
Follow-up probes
- What latency would the business actually tolerate, and how would you find out?
- How does your answer change if only one downstream consumer needs near-real-time?
- What operational complexity would streaming add for the on-call team?
Evidence that may indicate strength
- Starts with the latency requirement of the business
- Understands the operational complexity of streaming
- Considers cost and maintainability
- Does not default to streaming because it is modern
Points that may require further probing
- Defaults to batch because it is simpler
- Defaults to streaming because it is real-time
- Does not consider the business latency requirement
- Focuses on technology choice rather than the trade-off
4. Customer records in your warehouse include addresses and account statuses that change over time. How would you model this so analysts can report on both current and historical states?
What this is assessing: Data modelling judgement. Whether they think through the trade-offs of different approaches to changing data.
Follow-up probes
- How would analysts query history differently depending on your approach?
- What would change if regulatory reporting required a full audit trail of every change?
- How would you handle a correction to a historical record that was already wrong?
Evidence that may indicate strength
- Recognises that overwriting loses history and considers alternatives
- Considers the analytical use case before choosing
- Thinks about storage and query performance
- Mentions the importance of valid-from and valid-to dates
Points that may require further probing
- Defaults to overwriting without considering that history is lost
- Cannot explain the trade-offs of different approaches to changing data
- Does not consider how analysts will use the data
5. Tell me about a time you worked with an analyst or data scientist who was unhappy with the data you provided. What happened?
What this is assessing: Collaboration with data consumers. Whether they understand the user perspective. Whether they can resolve conflict constructively.
Follow-up probes
- What did you change about how you gather requirements afterwards?
- How do you balance the analyst’s request against pipeline maintainability?
- When have you had to push back on a consumer request, and how?
Evidence that may indicate strength
- Describes a specific situation and the underlying issue
- Listened to the consumer’s needs before defending the design
- Found a solution that addressed the real problem
- Improved the process or communication to prevent recurrence
Points that may require further probing
- Blames the analyst for not understanding the data
- Does not have an example of this happening
- Defended the design without understanding the complaint
- Did not change anything after the conflict
6. How do you ensure data quality in a pipeline without adding so many checks that it becomes unmaintainable?
What this is assessing: Practical judgement about quality versus complexity. Whether they can design proportionate checks.
Follow-up probes
- Which check would you put closest to the source, and why?
- How do you decide whether a check should block the pipeline or only alert?
- How would you reduce check noise over time?
Evidence that may indicate strength
- Prioritises checks based on the impact of bad data
- Distinguishes between schema, completeness and correctness checks
- Puts checks where they are most efficient, not everywhere
- Thinks about alerting versus blocking
Points that may require further probing
- Adds checks everywhere without prioritising
- Has no strategy for data quality
- Focuses on tests without considering monitoring
- Treats data quality as someone else’s problem
Practical scorecard
Score each competency separately and record concise evidence supporting your score. Do not allow one impressive answer to inflate unrelated competencies.
Scoring scale
| Competency | Score |
|---|---|
| Pipeline architecture and design Can they design reliable pipelines? Do they understand batch versus streaming? | |
| Data modelling and warehouse design Can they model data for analytics? Do they handle data that changes over time thoughtfully? | |
| Data quality and reliability Do they think about quality proactively? Can they design graceful failure? | |
| Operational maturity Do they understand monitoring and incidents? Do they think operationally? | |
| Collaboration with analysts and scientists Do they understand what consumers need? Do they design for users? | |
| Engineering fundamentals Do they write clean code? Do they use CI/CD and IaC appropriately? |
How to use this scorecard
- Score each competency separately.
- Record concise evidence supporting the score.
- Do not allow one impressive answer to inflate unrelated competencies.
- Do not average away a material role-critical concern.
- Discuss scores only after each interviewer has recorded their independent judgement.
- Use the scorecard to support — not replace — the final human decision.
How to run the debrief
Compare notes on design reasoning before tooling familiarity — a candidate who reasons well about pipelines can learn a stack, but the reverse is less reliable. Separate pipeline architecture from data modelling, since they draw on different judgement. Probe how candidates described collaboration with analysts and scientists, and whether their examples show empathy for data consumers. Insist on concrete failure-and-recovery examples before scoring reliability highly, and surface any concern about operational maturity rather than offsetting it with strong coding.
Fairness and reasonable adjustments
Technical assessments can disadvantage candidates from non-traditional backgrounds who may have less exposure to specific tooling terminology. Focus on design reasoning and trade-off thinking rather than recall of specific platform features or jargon. If including a practical exercise, ensure it does not require access to paid tools or environments not shared in advance. Be aware that candidates who are self-taught or come from adjacent fields may frame concepts differently — score the thinking, not the vocabulary.
Candidate experience: Explain the interview format at the beginning. Leave time for the candidate to ask questions. Avoid misleading candidates about the role or the team. Tell them what happens next and the expected timeline. Follow the agreed timing as closely as practical. Avoid repeatedly asking for information already covered in earlier stages.
Questions candidates may ask
Strong candidates will ask questions that reveal their priorities and how they think about the role. Be prepared to answer honestly — misleading a candidate about the role or the team risks a bad hire who leaves quickly.
- How mature is the data platform today, and what is the team prioritising next?
- Who are the main consumers of the data this role supports?
- How does the team handle on-call and incident response for data systems?
- What does reliability look like for your most critical pipelines?
- How much freedom is there to reshape the data model versus work within it?
Frequently asked questions
Should I include a coding test?
A discussion about pipeline design is more informative than a coding test. If you do include code, use a realistic scenario: designing a transformation or debugging a pipeline issue. Avoid algorithm puzzles — they test interview performance, not data engineering.
How do I assess data modelling if I am not a data engineer myself?
Ask them to explain their modelling approach for a simple scenario — customer orders, for example. A strong data engineer can explain their choices clearly. If they hide behind jargon, that is a signal regardless of your own expertise.
Should I test for specific tools or platforms?
Tools change. What matters is whether they understand the principles: pipeline design, data modelling, quality and reliability. A candidate who understands the principles can learn your stack. A candidate who knows the tools but not the principles tends to build the same problems in a new technology. Ask why they chose certain services, not just that they used them.
How do I judge reliability experience without running a live incident scenario?
Ask for a specific pipeline failure they owned and walk through detection, response and prevention. Concrete detail — what alerted them, how they communicated, what they changed afterwards — is a better signal than general statements about reliability. Vague or blame-shifting answers suggest limited real operational exposure.
Upload the candidate’s CV and, when available, the job description. Kippler creates a structured assessment and interview plan tailored to that person and role.
Try 1 Candidate Free