I've sat on both sides of the system design table enough times to know what separates a hire from a no-hire at the senior level. It's not SQL syntax. It's not whether you know the Spark API. It's whether you can talk about pipeline architecture like someone who's been paged at 2am because a pipeline silently dropped 2M rows and nobody noticed for six days. These 12 data pipeline interview questions are the ones I've seen decide loops at companies everyone's heard of. They don't have one right answer; they have a constellation of tradeoffs, and your job is to show you've navigated those tradeoffs in production, not just read about them on a blog.
The signal between senior and mid-level candidates is whether you bring up the failure modes before the interviewer prompts you. Strong answers surface at least two failure modes unprompted: partial writes, schema drift, dedup edge cases, exactly-once semantics. If you're prepping for these, i used datadriven for data pipeline interview prep and it's the best resource I've found for this category. Want to practice these for real? Solve these problems live here with a real editor and graded solutions.
1. Design an idempotent ingestion pipeline for a high-volume event stream
The question: You're receiving 500K events per minute from a Kafka topic into a data warehouse. Events can be delivered more than once. Design an ingestion pipeline that guarantees no double-counting in downstream analytics, even after retries or partial failures.
The answer starts with the word idempotent before anything else. Your sink must produce the same result whether a record is written once or five times. The standard pattern is partition-level overwrites: each run targets a specific time partition, deletes existing data for that partition, and writes the full replacement set. Alternatively, upsert (INSERT ... ON CONFLICT) keyed on a natural business key or a deterministic hash of the event payload. Never key your dedup on processed_at timestamps; the same source record reprocessed at different times creates different target records, and you've silently violated idempotency while every validation check passes.
Why it matters: This is the most common opener in data engineering interviews because it immediately reveals depth. Mid-level candidates say "use Kafka's exactly-once." Senior candidates explain that Kafka producer idempotence only holds within a single connection/partition pair and breaks across restarts or partition reassignment. The real answer is: at-least-once delivery with idempotent sinks is operationally equivalent to exactly-once without the coordination overhead. Exactly-once semantics costs 2-5ms latency and a 10-20% throughput reduction. For analytics pipelines where dashboards recalculate on query, that's wasted money. Reserve exactly-once for financial transactions.
2. How would you handle a schema change from an upstream producer you don't control?
The question: An upstream team adds a new field, renames an existing column, and deprecates another. Your pipeline consumes this data. Walk through your approach.
You need to distinguish three types of changes. Additive changes (new fields) are backward-compatible; your pipeline should ignore unknown fields and not break. Renaming is a breaking change, full stop. Column removal is breaking. The answer is schema contracts enforced at write time, not read time. Register schemas in a schema registry (Avro with Confluent Schema Registry or Protobuf with field numbers). Enforce backward compatibility checks in CI before the producer can publish. On the consumer side, pin to a known schema version and fail loudly on incompatible changes rather than silently ingesting garbage.
Why it matters: Snowflake's own December 2025 outage was caused by a backward-incompatible schema change that took down 10 of 23 global regions for 13 hours. If Snowflake can't get this right internally, your upstream team definitely can't. The interviewer is checking whether you design for upstream chaos. The trap: candidates who say "just use mergeSchema=true" get dinged. Blindly enabling mergeSchema leads to 200-column tables nobody trusts and downstream chaos disguised as data quality. The difference between "hire" and "strong hire" is knowing when NOT to use it.
3. Batch or streaming: how do you decide?
The question: Your stakeholder says they want "real-time" data. Walk through how you'd determine whether to build a batch or streaming pipeline.
First question back to the interviewer: what's the actual latency requirement? If the answer is "we want dashboards updated every morning," that's batch. A daily batch job running 20 minutes for $5 beats a streaming pipeline costing $500/day with a dedicated on-call engineer. Default to batch unless there's a clear latency requirement under 5 minutes. Batch is simpler to build, cheaper to run, easier to debug, and produces deterministic outputs.
Most companies don't have real-time data needs. They have real-time data wants and hourly-batch data needs. Your job is to figure out which one you're actually solving.
Why it matters: Premature streaming is the new premature optimization. Interviewers increasingly ask "why streaming?" first, not "how would you build it?" 54% of enterprises now run both batch and streaming simultaneously, but the senior move is knowing which workload belongs where. The follow-up question is always about reprocessing: "If you find a bug in your streaming pipeline, how do you reprocess the last 3 months?" If you built Kappa, that replay might be 10-100x slower than a batch Spark job over Parquet files. Mentioning that tradeoff unprompted is the signal.
4. Design a backfill strategy that won't corrupt live data
The question: You discover a bug that corrupted 3 days of data in a production table. Design a reprocessing strategy that fixes the historical data without impacting current pipeline runs or downstream consumers.
Partition isolation. Backfill writes to a staging partition or shadow table, validated independently, then atomically swaps into production. Each backfill run must be idempotent; same inputs, same outputs, same partition target. The critical detail: your backfill code path must be the same code path as live ingestion. If reprocessing uses a different path, you risk double-counting or schema mismatches between the two.
Why it matters: Backfill is the maturity test, not an afterthought. Bad backfills have corrupted months of analytics and destroyed user trust. Airflow has a documented race condition in HA mode where max_active_runs=1 can still allow concurrent DAG runs when run count exceeds 500. The interviewer is also checking resource awareness: a backfill DAG that consumes all pool slots starves your critical production DAGs. That's not misconfiguration; that's Airflow's FIFO scheduling by design.
5. Where do you place data quality checks in a pipeline?
The question: You have a four-stage pipeline: ingest, transform, aggregate, publish. Where do you put quality assertions, and what happens when they fail?
Blocking checks on critical columns (primary keys, join keys, non-null constraints) at the ingest layer. Stop bad data at the door. Non-blocking warnings on distribution anomalies (row counts, value ranges, cardinality shifts) at the transform and aggregate layers. Never block a pipeline on a soft anomaly; log it, alert on it, investigate later. Hard failures stop publish; soft warnings don't.
Why it matters: Organizations average 67 data incidents per month, with 68% requiring 4+ hours to detect. The conventional answer is "check at every layer," but interviews now penalize over-instrumentation. 66% of teams can't keep pace with alert volume, and engagement drops 15% once a channel receives more than 50 alerts per week. The senior answer is fewer, higher-confidence alerts. Target less than 10% false positive rate. Rules above 50% false positive rate are candidates for deletion, even if it means temporary blind spots.
6. How do you handle late-arriving data?
The question: Events arrive 2-48 hours after their event timestamp. Your aggregation pipeline runs daily. How do you ensure late arrivals are reflected accurately?
Separate ingestion windows from processing windows. Write late-arriving records into the partition matching their event time, not their arrival time. Use a watermark (a threshold for how late you'll accept data) and reprocess affected partitions when late data lands. The reprocessing must be idempotent: overwrite the partition, don't append.
Why it matters: This exposes whether you understand the difference between event time and processing time at an architectural level. The follow-up is always: "What if your watermark is 48 hours but a record arrives 72 hours late?" The answer isn't "drop it"; it's "route it to a late-arrival queue, reprocess the affected partition on the next run, and alert if the volume is anomalous."
7. Design a pipeline with fan-out/fan-in dependencies
The question: You have one source that feeds 8 independent transformations, and all 8 must complete before a final aggregation step runs. One of the 8 is consistently 5x slower than the others. How do you design this?
The slow branch determines your pipeline's clock. Options: optimize the slow task, break it into parallelizable sub-tasks, or (if the slow branch's output is independent enough) decouple it into a separate pipeline with its own SLA. The aggregation step either waits for all 8 or publishes a partial result with a flag indicating incomplete data.
Why it matters: Many candidates optimize individual task latency and miss the parallel fan-out bottleneck entirely. One slow downstream branch blocks the fan-in. This is where architecture discipline beats framework knowledge. The follow-up: "What if the slow branch fails? Do you retry, skip, or block?" Each answer reveals different assumptions about data completeness guarantees.
8. Explain the tradeoffs between Lambda and Kappa architecture
The question: When would you choose Lambda over Kappa, and vice versa?
Kappa (single streaming codebase, replay from the log) is simpler to maintain but brutal for large-scale reprocessing. Lambda (separate batch and speed layers) duplicates code but gives you a batch safety net. Kappa is the mainstream default now; Uber, LinkedIn, Shopify, and Disney run Kappa-style architectures. But Lambda's safety guarantees outweigh Kappa's elegance when reprocessing 2+ years of events is a regular need, because replaying through a streaming engine is often slower and more expensive than running a batch Spark job over Parquet files.
Why it matters: Interviewers now assume you know Kappa and ask when Lambda is justified, not the reverse. Candidates who cite Kappa as the "modern" choice without discussing reprocessing costs haven't run a terabyte-scale backfill. LinkedIn abandoned Lambda explicitly to reduce codebase duplication, but that tradeoff only makes sense if your replay path is fast enough.
9. How do you prevent alert fatigue in pipeline monitoring?
The question: Your team monitors 200 pipelines. Engineers are ignoring alerts. How do you fix this?
Classify alerts into hard failures (stop publish, page someone) and soft warnings (investigate during business hours). Set a false positive target below 10% and an alert-to-incident conversion rate above 20%. Dynamic thresholds tuned on historical data reduce alert noise by 40-60% in the first month compared to static thresholds. Ruthlessly delete rules with a false positive rate above 50%.
Why it matters: Alert fatigue kills more pipelines than lack of monitoring. The production reality is inverted from what textbooks teach: the problem isn't too few alerts, it's too many. Gartner benchmarks show $12.9M per year in organizational losses from poor data quality, and a huge chunk of that is real issues buried under noise that nobody looked at.
10. How do you enforce schema contracts across teams?
The question: Three producer teams send data to your pipeline. How do you prevent breaking changes from reaching production?
Schema registry with compatibility mode (backward, forward, or full) enforced in CI. Producers can't merge a PR that breaks compatibility. Pair this with a deprecation window: fields marked deprecated get a 90-day sunset, consumers are notified, and removal only happens after the window closes. The contract isn't just schema; it's schema plus field semantics plus nullability plus ownership.
Why it matters: Most data contract tools don't actually enforce contracts; they validate them after the fact, with a 35-40% false-negative rate. The senior answer distinguishes detection from enforcement. Detection alerts you after bad data lands. Enforcement blocks the write before it happens. The Open Data Contract Standard (ODCS v3.1, shipped December 2025) is the reference spec.
11. Design for exactly-once semantics in a payment processing pipeline
The question: Payment events flow through Kafka into a ledger system. Duplicate charges are unacceptable. How do you guarantee exactly-once processing?
This is the one case where at-least-once with idempotent sinks isn't enough. Use Kafka transactions (atomic read-process-write) combined with a database UNIQUE constraint on the idempotency key. The idempotency key must be derived from the business event (transaction ID), never from processing metadata. The critical edge case: two concurrent identical requests can both pass the dedup check if you're using a boolean flag. You need an atomic lock; database UNIQUE constraint or Redis SET NX with expiry.
Why it matters: The interviewer is testing whether you know when exactly-once is worth the overhead. The answer: money, inventory, anything with legal or financial consequences. The follow-up is always the concurrent request race condition. Stripe uses atomic INSERT ... ON CONFLICT as the canonical pattern, and there's a reason: it's the only approach that handles concurrent duplicates correctly at the database level.
12. Your pipeline silently dropped 40% of records for six months. How do you find out, and how do you prevent it?
The question: No alerts fired. Dashboards still loaded. Stakeholders noticed the numbers "looked low" but didn't escalate. Walk through detection and prevention.
Detection: row-count reconciliation between source and target at every stage, run on a schedule independent of the pipeline itself. Statistical anomaly detection on output volumes (not just "is it zero," but "is it within 2 standard deviations of the trailing 30-day average"). Prevention: publish data quality metrics as a first-class output of the pipeline, visible to stakeholders, not buried in engineering dashboards.
Why it matters: Non-idempotent pipelines fail loudly. Almost-idempotent pipelines fail silently. The dashboards still load, the counts look "reasonable," but the numbers are wrong. 73% of teams can detect pipeline failures but have zero visibility into root cause. This question tests whether you've been burned by the silent failure and built the guardrails afterward, or whether you're still designing for the happy path.
, -
These 12 data pipeline interview questions cover the territory where senior DE loops are won and lost. The pattern across all of them: the interviewer isn't looking for the "correct" architecture. They're looking for evidence that you've shipped something, watched it break, and fixed it under pressure. The tools change every 18 months. Schema drift, late-arriving data, upstream teams breaking contracts without telling you: those are eternal.
What's the pipeline architecture question you've been asked that isn't on this list? Drop it in the comments.
Top comments (0)