The Typical 5-Round Structure
Data engineering loops are longer than analyst loops because there is more surface area to test. A common shape at both product companies and services firms:
- Round 1 — Screening: your stack, the scale you have handled, why you left
- Round 2 — SQL deep dive: window functions, deduplication, incremental logic
- Round 3 — Python / PySpark: transformations, partitioning, performance
- Round 4 — Pipeline & system design: 'design ingestion for X events/day'
- Round 5 — Behavioural + on-call: an incident you owned, how you debugged it
SQL Beyond the Basics
Assume basic SQL is table stakes and will be tested through applied problems, not definitions. What actually separates candidates:
- Deduplication with ROW_NUMBER() OVER (PARTITION BY … ORDER BY …) — the single most asked pattern
- Incremental / delta loads: watermarks, high-water-mark columns, late-arriving data
- Slowly Changing Dimensions Type 1 vs Type 2 written as actual SQL
- Gaps-and-islands problems (sessionising events by inactivity window)
- Reading an EXPLAIN plan and explaining why a query is slow
- Idempotency — why re-running your query twice must not double the rows
PySpark and Distributed Processing
Most Indian data engineering roles in 2026 are Spark-centric. The interviewer is checking whether you understand the execution model or just the API surface.
- Narrow vs wide transformations, and why shuffles are expensive
- Data skew: how you detect it and how you fix it (salting, broadcast joins, repartition)
- Lazy evaluation — why nothing runs until an action, and how that bites you in debugging
- cache() vs persist(), and when caching actually hurts
- Partitioning strategy: file sizes, the small-files problem, partition pruning
- Delta Lake / Iceberg basics: ACID on object storage, time travel, MERGE
Pipeline & ETL Design
The design round is open-ended on purpose. There is no single right answer — they are grading how you narrow the problem before you start drawing boxes.
- Ask about volume, latency requirement, and failure tolerance before designing anything
- Batch vs streaming — and being able to say why batch is the right call when it is
- Exactly-once vs at-least-once delivery, and where dedupe belongs
- Backfill strategy: can you replay 6 months without corrupting current data?
- Schema evolution: what happens when a producer adds a column tomorrow
- Data quality gates — where you fail loudly vs where you quarantine and continue
Data Modelling & Warehousing
Modelling questions reveal whether you have built things that other people consume, or only things you consume yourself.
- Star schema vs snowflake, and the real trade-off (query simplicity vs storage/consistency)
- Fact table grain — defining it explicitly is the answer most candidates skip
- Normalisation for OLTP vs deliberate denormalisation for OLAP
- Medallion architecture (bronze / silver / gold) and what belongs at each layer
- Handling late-arriving facts and dimensions
Orchestration, Monitoring and On-Call
This is the round that separates a two-year engineer from a five-year one. Everyone can write a transformation; fewer people can keep it alive.
- Airflow concepts: DAGs, task dependencies, sensors, backfill, idempotent tasks
- Retries and alerting — what deserves a page vs what deserves a ticket
- SLAs on data freshness and how you measure them
- Lineage: when a number is wrong, how fast can you find the source?
- A real incident you handled: detection, root cause, fix, prevention
Common Interview Questions & Answers
Q1. Your nightly ETL job started taking 4 hours instead of 40 minutes. Nothing in your code changed. How do you investigate?
First I'd confirm it's not data volume — check the input row counts against the previous week. If volume is flat, I'd look at the Spark UI for the specific stage that regressed and check for skew: one task running far longer than the rest of its stage. Common causes are a shifted key distribution upstream, a broadcast join that silently fell back to a shuffle join because the dimension grew past the broadcast threshold, or a small-files explosion in the source. I'd also check whether the cluster itself is smaller or contended.
Naming the Spark UI and a specific stage-level symptom is what makes this answer credible.
Q2. How do you make a pipeline idempotent?
The goal is that running the same job twice produces the same result as running it once. Practically: partition output by the logical run date and overwrite that partition rather than appending; use MERGE keyed on a business key instead of INSERT; and derive any surrogate keys deterministically rather than from an auto-increment. Then a failed run can simply be re-run without a manual cleanup step.
Idempotency is the single most valued word in a data engineering interview — use it explicitly.
Q3. An upstream team adds a new column to a JSON source without telling you. What should happen?
Nothing should break — that's the point of schema evolution. If I'm reading into a schema-on-read format I'd use an explicit schema with the new field ignored, so the pipeline keeps running, and log a schema-drift warning rather than failing the job. Silent breakage is the failure mode I want to avoid, so I'd rather have a drift alert that a human triages than a job that either crashes at 2am or quietly drops data.
Distinguishing 'fail loudly' from 'fail silently' shows production maturity.
Q4. Batch or streaming for a daily sales dashboard?
Batch. The consumer refreshes once a day, so streaming buys latency nobody asked for while adding operational cost, on-call burden, and exactly-once complexity. I'd only move to streaming if there were a concrete business decision being made on sub-hour data.
Choosing the boring option and justifying it scores higher than reaching for Kafka.
Common Mistakes to Avoid
Listing tools you have 'worked with' but cannot explain the execution model of
Jumping into a design answer without asking about volume, latency, or failure tolerance
Describing a pipeline you built but not the incident where it broke
Saying 'we used Spark' without being able to explain what a shuffle costs
Ignoring backfill and replay — interviewers ask about it precisely because candidates forget
Expert Tips
Have one pipeline you can whiteboard end to end, including the part that went wrong
Quantify scale honestly — 'about 40 GB a day across 12 sources' beats 'big data'
Rehearse the deduplication window function until you can write it without thinking
Practise the design round out loud — it is a conversation, and silence reads as being stuck
Pre-Interview Checklist
6 itemsFrequently Asked Questions
Do I need to know both Spark and SQL deeply?
Yes. SQL is tested in almost every round and Spark in most Indian data engineering roles. If you have limited time, prioritise SQL — it appears in the screening round and a weak SQL round usually ends the loop.
How much system design is expected for a 2–4 year data engineer?
You are not expected to design a distributed database. You are expected to design an ingestion and transformation pipeline, defend your batch-vs-streaming choice, and describe how it recovers from failure.
Ready to ace your next interview?
Practice with SpeakWell AI. Upload your resume → get resume-based questions → practice with AI interviewers → improve communication → track progress → get instant AI feedback.