Data engineer interview questions (and what good answers sound like)

• One scenario, many follow-ups beats twenty trivia questions. Depth shows in the third "why".
• Use your own context, anonymised. A candidate who asks good questions about your data is showing you the job.
• Score against the same rubric for every candidate (bottom of page).
• Keep any take-home short and paid if it's long. Strong engineers drop out of long unpaid tasks.

"A daily pipeline finished green but the revenue dashboard is 20% low this morning. Walk me through what you do."

• Strong: Checks freshness and row counts by source and partition, compares against the source system, looks for a silent schema change or late-arriving data, tells the dashboard owner early, fixes forward, then adds a test (volume or reconciliation) so it can't happen silently again.
• Weak: Re-runs the job and hopes. Doesn't mention telling anyone or preventing a repeat.

"How do you make a pipeline idempotent? Why does it matter?"

• Strong: Re-running for the same window gives the same result: overwrite or merge by partition/key rather than append, deterministic transforms, watermarks. Matters for backfills and retries.
• Weak: Defines the word, can't give an implementation.

"How would you backfill two years of data without breaking today's loads?"

• Strong: Partitioned backfill in batches, separate compute or off-peak, writes to a staging table then swaps, validates counts, communicates the window.

"Model orders, customers and refunds so finance and product get the same revenue number."

• Strong: Grain first ("one row per order line"), facts and dimensions, a single documented revenue definition, handles refunds and currency explicitly, tests on keys and totals.
• Weak: Starts drawing tables before asking what "revenue" means to each team.

"When would you use a slowly changing dimension type 2?"

• Strong: When history of an attribute matters for analysis (customer's plan at time of order); explains valid-from/valid-to and the cost of doing it everywhere.

"Find each customer's second order and the days between their first and second."

• Strong: Window functions (ROW_NUMBER / LAG), handles ties and customers with one order, explains performance on a large table.

"This query got slow after the table grew 10×. What do you check?"

• Strong: Query plan, partition and cluster pruning, join order and exploding joins, SELECT *, data skew, whether it should be incremental.

"How do you deploy a change to a model that twenty dashboards depend on?"

• Strong: Version control, CI with tests on a dev/staging environment, lineage to find downstream impact, communicate, deploy, monitor. Mentions contracts or deprecation windows for breaking changes.

"Airflow, Dagster, Prefect or ADF: how would you choose?"

• Strong: Depends on team skills, existing cloud, asset vs task model, observability needs. No religion.

"Our warehouse bill doubled in a quarter. Where do you look?"

• Strong: Usage by user/job/warehouse, full refreshes that should be incremental, oversized compute, unused tables and dashboards refreshing too often, then sets budgets and alerts.

"When is streaming worth it over micro-batch?"

• Strong: When the business acts on the data within minutes (fraud, operations, personalisation). Otherwise batch is cheaper and simpler. Mentions exactly-once vs at-least-once and late events.

"A stakeholder wants a new metric by Friday and the source data is wrong. What do you do?"

• Strong: Says so early, offers an option with a caveat or a later date, fixes the source issue with the owner. Doesn't ship a number they know is wrong.

• "Explain the medallion architecture and when you wouldn't use all three layers." Strong: bronze raw, silver cleaned/conformed, gold business-ready; skips layers for small or simple sources rather than adding ceremony.
• "What does Delta Lake give you over plain Parquet?" Strong: ACID transactions, time travel, schema enforcement and evolution, MERGE, OPTIMIZE / Z-ordering or liquid clustering.
• "How do you handle late or duplicated records in an incremental load?" Strong: MERGE on keys with a watermark, deduplication on a deterministic key, Auto Loader or structured streaming checkpoints.
• "A Spark job is slow and one task runs far longer than the rest. Why?" Strong: data skew; salting, broadcast joins, adaptive query execution, repartitioning.
• "How do you control access to tables across workspaces?" Strong: Unity Catalog, grants at catalog/schema/table level, row and column controls, lineage.
• "Jobs vs Delta Live Tables / declarative pipelines: when each?" Strong: declarative pipelines for managed quality expectations and dependency handling; jobs for custom workflows and non-pipeline tasks.

1. Read for owned outcomes in the CV, not tool lists.
2. Scenario interview using the questions above on your own anonymised data.
3. Short practical if you need one: a small dataset and a broken model to fix, under two hours, discussed live afterwards.
4. Check how they explain a trade-off to a non-technical person.
5. References on reliability and ownership, not just "were they nice".
6. On carbon.talent, vetted profiles show a vetting report from Carbon's real-world data experience test (scenario-based, not a coding test), a working-style profile and a short video intro, and you get an interview guide tailored to the role and the candidate. You can also test a candidate you found yourself. More in the data engineer skills test guide.