As featured in
Built by a hiring manager who's conducted 1,000+ interviews at Google, Amazon, Nvidia, and Adobe.
Built by a hiring manager who's conducted 1,000+ interviews at Google, Amazon, Nvidia, and Adobe.
Last updated: May 9, 2026
Use Revarta — the AI interview coach built by a former Google, Amazon, and Adobe hiring manager — to practice Data Engineer interviews with feedback that mirrors what real interviewers actually assess. Data engineering interviews assess your ability to design, build, and maintain scalable data pipelines and infrastructure that enable analytics and machine learning. Expect questions covering ETL/ELT processes, data warehousing, big data technologies, data modeling, and data quality. Success requires demonstrating both technical proficiency with data tools and frameworks alongside understanding of distributed systems, performance optimization, and business requirements.
Knowing the question isn't enough. Most candidates fail because they never practiced out loud.
ETL extracts data, transforms it outside target system, then loads. ELT loads raw data first, then transforms within target. Use ETL when transformations complex/resource-intensive, target system has limited compute, or need data cleansing before loading. Use ELT when target system powerful (modern data warehouses like Snowflake, BigQuery), want faster initial load, leverage warehouse optimization, or need flexibility in transformations. ELT increasingly common with cloud warehouses. Discuss modern data stacks favoring ELT with tools like dbt.
Practice these commonly asked behavioral and situational questions with AI-powered feedback
Common topics and questions you might encounter in your Data Engineer interview
Learn proven strategies and techniques to ace your interview
Complete framework for structuring your behavioral interview answers.
Structure your biggest wins for maximum impact in interviews.
Stay composed when asked about handling pressure and high-stakes situations.
Design with stages - ingestion (batch or streaming based on latency requirements), storage in data lake (S3, ADLS), processing with Spark or similar for transformations, load to warehouse (partitioned tables), orchestration with Airflow. Consider idempotency for retry safety, incremental processing vs full refresh, data validation and quality checks, schema evolution handling, monitoring and alerting, backfill strategy. Partition data by date for performance. Use columnar formats (Parquet, ORC). Implement data lineage tracking. Discuss scaling horizontally and cost optimization.
SCD handles changes to dimension attributes over time. Types - SCD Type 1 (overwrite, no history), Type 2 (add new row with effective dates, maintains history, most common), Type 3 (add columns for previous values, limited history). For Type 2, include surrogate key, effective start/end dates, current flag. Use case determines type - customer address might be Type 1, pricing history Type 2. Implementation - compare source with target, insert new rows for changes, update end dates. Discuss impact on storage and query complexity.
Systematic approach - analyze execution plan (EXPLAIN/EXPLAIN ANALYZE), identify bottlenecks (table scans, sorts, joins), check statistics are current, add appropriate indexes (covering indexes for frequently queried columns), rewrite query (eliminate subqueries, use CTEs, avoid SELECT *), partition large tables, denormalize if appropriate, use materialized views for complex aggregations, ensure join columns indexed and same type, limit result set early in query. Profile query with actual data volumes. Discuss trade-offs between read and write performance.
Batch processes large volumes of data at scheduled intervals (hourly, daily), higher latency but higher throughput, good for historical analysis, simpler to implement and debug. Stream processes data in real-time as it arrives, low latency, handles continuous data, more complex. Use batch for: reporting, data warehousing, ETL jobs, ML training. Use stream for: fraud detection, real-time dashboards, event-driven applications, time-sensitive analytics. Often use both: streaming for real-time, batch for corrections and historical backfill. Discuss Lambda and Kappa architectures.
Partitioning divides large tables into smaller, manageable pieces based on column values (typically date/time), improving query performance and management. Benefits include partition pruning (scanning only relevant partitions), parallel processing, easier maintenance (archive old partitions), faster deletes. Strategies - range (dates), hash (distribute evenly), list (specific values). Choose partition key based on query patterns. Over-partitioning creates overhead. Discuss partition size (aim for 100MB-1GB), compaction strategies, and metastore performance.
Implement validation at multiple stages: schema validation (data types, required fields), completeness checks (null values, missing records), accuracy checks (range validation, referential integrity), uniqueness constraints, timeliness monitoring, consistency across sources. Use data quality framework (Great Expectations, deequ), define SLAs for data freshness, implement automated alerts on quality violations, create data quality dashboards, track metrics over time. Reconcile record counts between stages. Quarantine bad data for investigation. Discuss data quality as ongoing process requiring monitoring and iteration.
CAP theorem states distributed systems can provide only two of - Consistency (all nodes see same data), Availability (system remains operational), Partition tolerance (works despite network failures). Since partitions inevitable in distributed systems, choose CP (consistent but may be unavailable during partition) vs AP (available but may be inconsistent). Examples - traditional RDBMS prioritize consistency, Cassandra/DynamoDB favor availability. Choose based on application needs - financial transactions need consistency, social media can tolerate eventual consistency. Discuss eventual consistency and conflict resolution strategies.
Spark is distributed computing framework for big data processing. Unlike MapReduce which writes intermediates to disk, Spark uses in-memory computation with RDDs/DataFrames for iterative algorithms. Benefits: 10-100x faster for iterative workloads, unified API for batch/streaming/ML, richer transformations. Spark suited for: iterative ML algorithms, interactive analytics, complex DAGs. MapReduce better for: one-pass processing, when memory limited. Spark architecture includes driver, executors, cluster manager. Discuss lazy evaluation, transformations vs actions, and optimization with Catalyst and Tungsten.
Use STAR method describing specific failure (data loss, pipeline stall, data quality issue, performance degradation). Explain debugging approach: reviewing logs, checking monitoring dashboards, analyzing data samples, verifying dependencies, testing components in isolation. Describe root cause (schema change, resource exhaustion, incorrect transformation logic), solution implemented, validation approach, and preventive measures (better testing, monitoring alerts, documentation). Quantify impact and recovery time. Emphasize systematic troubleshooting, communication with stakeholders, and learning from incident.
Strategies include: schema registry (Confluent Schema Registry) for centralized management, versioning schemas, backward/forward compatibility rules, using formats supporting schema evolution (Avro, Parquet), implementing schema validation in pipeline, graceful degradation for unknown fields. Approaches: adding optional fields (backward compatible), evolving types carefully (e.g., int to long okay, long to int breaks), removing fields (forward compatible). Test schema changes in non-prod first. Use tools like dbt for migration management. Discuss communication with data producers and consumers about changes.
Data lake stores raw data in native format (structured, semi-structured, unstructured), schema-on-read, flexible but requires more processing. Data warehouse stores structured data with schema-on-write, optimized for analytics, higher performance but less flexible. Use lake for: raw data storage, diverse data types, exploratory analysis, ML training data, cost-effective storage. Use warehouse for: BI and reporting, well-defined schemas, production analytics, guaranteed performance. Modern approach: lakehouse combining benefits using Delta Lake, Iceberg, or Hudi. Medallion architecture uses both: lake for bronze/silver, warehouse for gold.
Architecture includes event streaming (Kafka), stream processing (Flink, Spark Streaming, or Kafka Streams), real-time storage (Redis, Druid), analytics layer (materialized views, aggregations), API layer for queries. Key considerations - exactly-once semantics, state management and checkpointing, late data handling (watermarks), windowing strategies (tumbling, sliding, session), scalability and backpressure handling, monitoring lag and throughput. Trade-offs between latency, throughput, and accuracy. Discuss complementing with batch processing for corrections and Lambda/Kappa architecture choices.
Consider query patterns (columnar formats like Parquet, ORC for analytics with selective column reads; row-based like Avro for write-heavy or full-row access), compression efficiency (columnar compresses better), schema evolution support (Avro strong), ecosystem compatibility (Parquet widely supported in Spark, Athena; ORC optimized for Hive), read vs write performance trade-offs, and splittability for parallel processing. Parquet generally good default for analytics. Avro for streaming. ORC if heavily in Hive ecosystem. Discuss encoding techniques (dictionary, run-length) and file size considerations for cloud storage costs.
Implement using tools like Apache Atlas, Amundsen, or DataHub. Capture metadata at pipeline execution time including source tables, transformations applied, output tables, timestamps, and quality checks. Track column-level lineage for regulatory compliance. Store in centralized metadata repository. Create data catalog for discovery with business descriptions, owners, and SLAs. Implement impact analysis to understand downstream effects of changes. Use tags for PII classification. Expose via UI for data discovery and trust. Discuss importance for troubleshooting, compliance, and collaboration between teams.
Star schema has denormalized dimension tables directly connected to the fact table for simpler queries and better performance. Snowflake schema normalizes dimensions into sub-dimensions, reducing storage but requiring more joins. Choose star for analytics performance and simplicity. Choose snowflake when storage costs matter or data integrity is paramount. Discuss impact on query complexity and BI tool compatibility.
Start with business requirements and key metrics (revenue, conversion, customer lifetime value). Design fact tables for orders, page views, and inventory. Create dimension tables for products, customers, time, and geography. Discuss slowly changing dimensions, grain decisions, conformed dimensions across subject areas, and the medallion architecture approach with bronze, silver, and gold layers.
Data vault uses hubs (business keys), links (relationships), and satellites (descriptive attributes with history). Benefits include audit trail, flexibility for schema changes, and parallel loading. Use when source systems change frequently, need full history, or have complex many-to-many relationships. Traditional dimensional modeling is better for simpler BI reporting with predictable schemas.
Discuss strategies like reprocessing affected partitions, using merge/upsert operations, maintaining a correction pipeline, and designing fact tables to handle updates. Address how late data affects downstream aggregations and reports. Mention event-time vs processing-time semantics and how tools like Apache Beam handle this with watermarks and windowing.
Discuss key differentiators. Snowflake offers separation of storage and compute, multi-cloud support, and time travel. BigQuery provides serverless architecture, built-in ML, and strong GCP integration. Redshift offers tight AWS integration, Spectrum for data lake queries, and familiar PostgreSQL interface. Consider factors like existing cloud provider, workload patterns, concurrency needs, cost model preferences, and team expertise.
dbt (data build tool) transforms data inside the warehouse using SQL with software engineering best practices like version control, testing, documentation, and modularity. It fits between ingestion tools (Fivetran, Airbyte) and BI tools (Looker, Tableau). Discuss how dbt enables analytics engineering, the ELT paradigm, and features like incremental models, snapshots, and data contracts.
Plan in phases. Assessment phase covers schema analysis, query patterns, data volumes, and dependency mapping. Strategy phase covers choosing target platform, deciding lift-and-shift vs re-architect, and parallel running approach. Execution phase covers schema migration, data transfer (full vs incremental), ETL pipeline conversion, and validation. Discuss minimizing downtime, data consistency verification, performance benchmarking, and rollback planning.
Discuss Kafka components including brokers, topics, partitions, producers, consumers, and consumer groups. Explain how partitions enable parallelism and ordering guarantees. Cover use cases like event sourcing, log aggregation, and change data capture. Discuss retention policies, compaction, exactly-once semantics, and how Kafka Connect simplifies integration with external systems.
CDC captures row-level changes from source databases in real-time. Approaches include log-based (Debezium reading database WAL/binlog), trigger-based (database triggers writing to audit tables), and timestamp-based (polling for changes). Log-based is preferred for minimal source impact. Discuss how CDC enables real-time data integration, reduces ETL latency, and supports event-driven architectures. Address schema evolution and ordering challenges.
Discuss the challenge of achieving exactly-once in distributed systems. Cover approaches like idempotent producers, transactional consumers, checkpointing with Flink or Spark Structured Streaming, and deduplication strategies. Explain the difference between at-most-once, at-least-once, and exactly-once guarantees. Address trade-offs between latency, throughput, and correctness. Mention Kafka's transactional API and how end-to-end exactly-once requires coordination across all pipeline stages.
Discuss chunked reading with pandas (chunksize parameter), generators for lazy evaluation, memory-mapped files, or processing line-by-line. For structured data, mention using Dask or PySpark for distributed processing. Address trade-offs between simplicity and performance. Show awareness of memory profiling tools and how to estimate memory requirements before choosing an approach.
Threading is limited by the GIL for CPU-bound work but useful for I/O-bound tasks like API calls and file reading. Multiprocessing bypasses the GIL for true CPU parallelism but has higher memory overhead due to process isolation. For data processing, use multiprocessing for CPU-heavy transformations, threading for concurrent API calls or file downloads. Mention asyncio for high-concurrency I/O patterns and when to just use Spark instead.
Cover unit tests for individual transformations, integration tests for end-to-end pipeline runs with sample data, data quality tests (Great Expectations, dbt tests) for schema and value validation, performance tests for scalability, and contract tests for upstream schema changes. Discuss test data management strategies, using fixtures vs production-like data, and CI/CD integration for automated pipeline testing.
Use the STAR method. Describe your incident response process including immediate triage, root cause analysis, fix implementation, and post-mortem. Discuss how you would identify the blast radius, communicate with downstream consumers, implement a fix with backfill if needed, and add monitoring and tests to prevent recurrence. Emphasize clear communication and documentation throughout.
Monitor at multiple levels. Pipeline level covers job success/failure, duration, resource usage, and data freshness SLAs. Data quality level covers row counts, null rates, value distributions, and schema drift detection. Infrastructure level covers cluster health, storage utilization, and network throughput. Set up alerts with appropriate severity levels and escalation policies. Discuss tools like Datadog, Monte Carlo, or custom dashboards with anomaly detection.
Most data engineering interviews follow a structured multi-stage process:
Total timeline is typically 2-4 weeks. At top companies, expect 4-5 rounds in a single onsite day.
Watch out for these frequent pitfalls in data engineering interviews:
Know these frameworks and when to apply them in data engineering interviews:
Revarta is purpose-built for the rounds that actually decide Data Engineer hiring. Five things candidates we work with say make the difference:
Related: [Interview Coach vs. Interview Copilot](/blog/coach-vs-copilot-interview-prep-2026) · [Free Interview Prep Tools — No Signup](/tools) · [Try Revarta free](/try).
These topics are commonly discussed in Data Engineer interviews. Practice your responses to stand out.