The most predictive data engineer interview questions focus on three areas: pipeline architecture judgment (how they design for failure and maintainability), data quality reasoning (how they detect and respond to silent data failures), and stakeholder communication (how they explain data incidents and trade-offs to non-technical audiences). Generic SQL and algorithm questions are poor predictors of production performance. Scenario-based questions tied to your actual stack and problems surface real competence.
Data engineering interviews are poorly designed more often than not. They rely on LeetCode algorithm questions that rarely show up in day-to-day work, or generic SQL trivia any candidate can memorize in an afternoon. Neither predicts how a candidate performs when an Airflow DAG silently skips a partition, or a stakeholder escalates a data issue before a board presentation.
These questions are organized by the competencies that actually predict production performance. Each includes what a strong answer sounds like, so you can calibrate what you hear against a senior engineer's response.
How to Structure the Interview
A 90-minute data engineering interview works best in four parts. Spend 30 minutes on pipeline architecture and modeling, 20 minutes on data quality and incident response, 20 minutes on orchestration and observability, and 20 minutes on stakeholder communication and working style. This structure tests the full profile of a production data engineer, not just the ability to write SQL under time pressure.
Before the interview, pick two or three questions from each section below and adapt them to your actual stack. "How would you design this pipeline in Airflow?" is a stronger question than the generic version because it anchors the candidate in your real environment and reveals whether their experience is transferable or superficial.
Pipeline Architecture Questions
These questions assess how candidates reason about pipeline design trade-offs, failure modes, and maintainability. Strong answers reveal engineers who have owned pipelines in production and understand the difference between code that works and code that is operable at 2am.
Q1: We have a daily Airflow DAG that ingests from 12 third-party API sources into Snowflake. One source fails intermittently. Walk me through how you would design the DAG to isolate that failure without blocking the other 11 sources.
The candidate describes using separate tasks per source rather than a single monolithic ingest task, using Airflow's task-level retry configuration with exponential backoff, sending failure notifications via callback, and using trigger rules to allow downstream tasks to proceed even when one source fails. They mention considering a sensor or external trigger for the unreliable source, and note the importance of idempotent writes so that retries do not duplicate data in Snowflake.
More Pipeline Design Scenarios
Q2: Our dbt project has 200+ models and our full run takes 3.5 hours on a small Snowflake warehouse. Where would you start to investigate performance issues?
Strong candidates start with dbt's built-in timing output to identify the slowest models. From there, they check for models running unnecessary full table scans because they lack incremental configuration, review join logic for fan-outs on non-unique keys, and check Snowflake's query history for expensive operations like disk spills or large remote reads. They also weigh whether the warehouse size fits the most compute-intensive models.
Q3: How would you design a data pipeline to handle schema drift from an upstream source that changes its API response structure without notice?
The candidate discusses storing raw API responses in a landing zone before any transformation (preserving the original payload for reprocessing), using schema-on-read patterns for the raw layer, adding dbt schema tests that alert but do not fail the pipeline on new unexpected columns, and building a notification mechanism that alerts the team when unexpected schema changes are detected. They distinguish between additive schema changes (new fields, safe to ignore) and breaking changes (renamed or removed required fields, requires intervention).
Data Modeling and SQL Questions
These questions test practical data modeling judgment, not SQL syntax recall. Strong candidates think in terms of grains, business rules, and downstream usability, not just technically correct SQL.
Q4: We have an orders table where an order can have multiple status updates. How would you model this to support both current order status and full status history for audit purposes?
The candidate creates two models: a fact table at the order-status-event grain preserving every status transition with timestamps, and a dimension or mart model filtered to the current status using a window function (ROW_NUMBER OVER PARTITION BY order_id ORDER BY updated_at DESC). They think through whether "current status" means the most recent update regardless of logic (last write wins) or whether business rules define what "current" means (e.g., a cancelled status supersedes an error status even if the error came later). Senior candidates ask about this ambiguity rather than assuming.
SQL Judgment and Incremental Modeling
Q5: Write a query that identifies customers who placed at least one order in each of the last 3 calendar months.
The candidate uses a COUNT(DISTINCT month) approach after truncating order dates to month, filtering for customers where the count equals 3 for the trailing 3 months. Strong candidates note edge cases: what counts as a month boundary, how to handle timezone differences between order timestamps and the analyst's local time, and whether the question means calendar months or rolling 30-day windows. The question itself is simple; how the candidate reasons about the edge cases is the signal.
Q6: How do you decide when to use an incremental dbt model versus a full-refresh model?
The candidate notes that incremental models are appropriate when the underlying table is too large for a full scan on every run and the data has a reliable updated_at or event timestamp that can partition processing. They mention risks: incremental models can silently miss records if late-arriving data falls outside the lookback window, and they require careful idempotency design. Full-refresh models are simpler to reason about and safer for smaller tables or tables where the transformation logic is complex. The candidate asks about data volumes and update patterns before recommending one over the other.
Data Quality and Incident Response
Data quality and incident response questions are the most predictive section of a data engineering interview. Engineers who have owned production pipelines with real accountability have specific, experience-based answers. Candidates who have only built pipelines in controlled environments give generic answers about adding more tests.
Q7: At 6am, a business stakeholder messages you saying the daily revenue report is 30% lower than yesterday. Your Airflow pipeline succeeded with no errors. Where do you start?
The candidate starts by distinguishing between a data problem and a reporting problem: is the underlying data in Snowflake wrong, or is the BI layer filtering or aggregating incorrectly? They check the row counts in the source tables vs. the previous day, verify that the Airflow DAG actually processed all expected partitions (not just that it returned success), check for any upstream API failures that logged warnings but did not raise exceptions, and review dbt test results for freshness failures. They communicate an initial timeline and investigation status to the stakeholder within 30 minutes, even before they have an answer.
Freshness SLAs and Regression Debugging
Q8: How would you implement a data freshness SLA for a pipeline that loads from a source that sometimes delivers data late?
The candidate uses dbt's built-in freshness configuration to define a warn threshold and an error threshold (e.g., warn if data is older than 2 hours, error if older than 4 hours). They also consider building a separate monitoring DAG that checks the max load timestamp in the destination table and sends alerts to a Slack channel or PagerDuty if the SLA is breached. They discuss the difference between the pipeline succeeding (DAG completed) and the data being fresh (new records actually arrived), which are two different guarantees.
Q9: A dbt test fails in production on a model that passed all its tests last week. The test is a uniqueness test on customer_id. Walk me through your investigation.
The candidate queries the model directly to identify which customer_ids are duplicated and how many duplicates exist. From there, they trace the duplicate back to the upstream source: is this a source data issue, like the CRM allowing duplicate customer records, or a pipeline logic issue where a join in the dbt model is fanning out? Git history is next, to check whether any model changes deployed recently. Finally, they look at whether the uniqueness test has been passing every day or flapping intermittently, which would point to data drift rather than a code regression.
Orchestration and Reliability Questions
Q10: How do you handle a situation where one task in a complex Airflow DAG has a long runtime that is blocking downstream tasks, but you cannot shorten the task itself?
The candidate considers whether the long-running task can be split into parallelizable sub-tasks using Airflow's dynamic task mapping or TaskGroup. They evaluate whether downstream tasks actually need the full output of the long task or just a subset that could be made available earlier. They also discuss whether the task's SLA impacts the business and whether the DAG schedule should be adjusted to accommodate realistic runtimes rather than optimistic ones.
Q11: What is your approach to managing secrets and credentials in production data pipelines?
The candidate never stores credentials in code, DAG files, or dbt profiles. They use Airflow Connections for pipeline credentials (never environment variables hardcoded in DAGs), AWS Secrets Manager or HashiCorp Vault for secrets that need rotation, and Snowflake key pair authentication or OAuth rather than password-based credentials. They mention auditing for credentials accidentally committed to version control and having a rotation process when credentials are exposed.
Q12: How would you detect when a data source has stopped sending new records without raising a pipeline error?
The candidate builds a monitoring check that queries the maximum event timestamp in the ingested table and compares it against the current time. If no records have arrived in the expected window (e.g., 4 hours for an hourly source), the check triggers an alert. They discuss using dbt's source freshness configuration for this at the transformation layer and a separate monitoring DAG or data observability tool at the ingestion layer. They note that pipeline success and data freshness are orthogonal guarantees.
Stakeholder and Communication Questions
Q13: A business analyst asks you to add a new column to a production dbt model urgently for a board presentation tomorrow. How do you handle it?
The candidate treats this as two separate questions: can they do it safely, and should they do it through the normal process or as an exception? They assess whether the change is purely additive (low risk) or whether it requires modifying existing logic (higher risk). If additive and safe, they can deploy with an expedited but not skipped review. If risky, they explain the risk clearly to the analyst and propose alternatives (a temporary view, a manual pull from the raw data, a quick analysis in a notebook) that satisfy the business need without modifying a production model under time pressure.
Explaining Failures and Learning From Them
Q14: How do you explain to a non-technical business stakeholder why a data quality issue happened and what you are doing about it?
Strong candidates avoid technical jargon and focuses on business impact and timeline. "The revenue numbers in your report were lower than expected because our system missed some order records from [source system] between 4am and 6am. We identified the gap at 7:30am, corrected the data by 8:15am, and the report now shows the correct figures. We are adding an alert that will notify us within 30 minutes if this type of gap happens again." They separate the immediate fix from the long-term prevention and commit to a specific timeline for each.
Q15: Tell me about a data pipeline you built or maintained that failed in a way you did not anticipate. What happened and what did you change?
Strong candidates have a specific story with real details: what the pipeline did, what assumption the failure invalidated, how they discovered it (ideally before a stakeholder did, but honestly even if not), and what specific change they made. The quality of the postmortem thinking matters more than the severity of the failure. A candidate who proactively built a monitoring check after the incident shows more reliability-oriented thinking than one who fixed the immediate bug and moved on.
Red Flags to Watch For
Vague answers about production experience. Candidates who say "I worked with Airflow" without being able to describe the DAG topology, retry logic, or a specific failure they diagnosed have likely only touched these tools in tutorials or side projects. Ask for specifics: how many DAGs, what was the average daily run count, what was the most complex failure they investigated.
No data quality awareness. Candidates who focus exclusively on pipeline construction without mentioning data quality checks, freshness monitoring, or test coverage are describing a greenfield mindset, not a production ownership mindset. Every question about pipeline design should eventually surface quality and observability considerations from senior candidates.
Avoiding the stakeholder communication questions. Candidates who pivot from stakeholder communication questions back to technical topics, or who describe handling data incidents entirely through tickets without direct communication, will struggle in roles where the data engineer is a visible partner to business teams. Data quality incidents require clear, non-technical communication under time pressure.
Over-engineering in architecture answers. Candidates who immediately propose Kafka streaming pipelines and complex multi-region architectures for a simple daily batch problem may be pattern-matching to buzzwords rather than reasoning about actual requirements. Good data engineers match the complexity of the solution to the actual scale and reliability needs of the problem.
Frequently Asked Questions
Should I include a coding challenge in the interview process?
Yes, but use a take-home pipeline review task rather than a live coding session. Send a dbt project or Airflow DAG with realistic issues and ask the candidate to identify problems and propose corrections asynchronously. This tests real-world diagnostic skills without the performance anxiety of live coding and gives you a writing sample that reveals how the candidate thinks and communicates about technical problems. Keep the task to 60-90 minutes of realistic work to respect senior candidates' time.
How do I interview for streaming versus batch data engineering experience?
Add two questions specifically about your streaming stack (Kafka consumer design, exactly-once semantics, windowing functions in Flink or Spark Streaming). A strong streaming candidate understands the fundamental differences: stateful processing, event-time versus processing-time semantics, consumer group management, and offset management for replay. A batch engineer who claims streaming experience but cannot explain exactly-once delivery guarantees or late event handling has not operated streaming pipelines in production.
Timing, Panel Size, and Kore BPO Screening
How long should a data engineering interview take?
75 to 90 minutes for the main technical interview, preceded by a 30-minute async coding task sent 24 hours in advance. One async screen plus one live interview is usually enough to assess a nearshore data engineer. Adding more rounds increases time-to-offer without improving hire quality for most roles. For a principal-level role with platform architecture ownership, though, a second interview with a senior technical stakeholder makes sense.
What is the right panel size for a data engineering interview?
Two interviewers is optimal for a 90-minute session: one focused on technical depth, one on stakeholder communication and working style. A panel of three or more creates coordination overhead and can make candidates uncomfortable. Want a second technical perspective instead? Schedule a separate 30-minute deep-dive rather than expanding the main panel.
Can Kore BPO pre-screen candidates with these questions before I interview them?
Yes. Share your priority questions from this guide with your Kore BPO account manager and we will build them into our technical screen. You receive a structured scoring summary for each candidate covering pipeline architecture, data quality awareness, and communication quality before you invest time in a live interview. That cuts your total interview load down to one final 60-minute conversation with your top 2-3 candidates.
