Data Engineer Interview Prep

From hundreds of mock interviews, the single biggest mistake data engineering candidates make is grinding algorithm problems when nearly 60% of real interview questions are about architecture: pipelines, system design, data modeling, and warehousing. The role's comp ceiling doesn't hurt either. A Staff DE pulls $390K median TC, and Principal can reach a max of roughly $1.01M at top-tier firms.

What Data Engineers Actually Do

Data engineers build Airflow DAGs, Spark jobs, and dbt models that publish curated tables to Snowflake, BigQuery, or Redshift. At big tech companies like Meta or Airbnb, that means owning petabyte-scale real-time Kafka pipelines and Hive-to-Spark migrations. A Series B fintech might need you to stand up the entire warehouse yourself and write every transformation.

Finance shops lean heavily on batch reconciliation and regulatory data lineage. Success after year one, regardless of setting, means your pipelines meet their SLAs (think 99.5%+ on-time for critical tables), your dbt tests and Great Expectations checks catch quality issues before analysts do, and you've earned the right to weigh in on schema decisions instead of just implementing them.

A Typical Week

Coding (Spark jobs, dbt models, Flink tuning) is the single largest slice, but it's not dominant. Airflow DAG triage, Kafka consumer lag investigations, and deprecated Hive table cleanup collectively rival it. The real surprise is how much writing the job demands: RFCs proposing streaming replacements for batch jobs, on-call handoff docs, runbook updates. If you picture the job as "I write Python all day," you'll be disappointed by Monday afternoon.

Skills & What's Expected

The highest-rated skill dimension for this role is data architecture and pipeline design, and interviews reflect that weight heavily. Software engineering and cloud/infra (AWS IAM policies, BigQuery partitioning strategies, Kubernetes pod configs) are high-priority but supporting. ML knowledge is rated medium, yet candidates over-index on it constantly. You'll collaborate with data scientists, but nobody expects you to tune an XGBoost model. Communication, also rated medium, is the sneakier gap: the engineer who can draft a clear RFC proposing a Flink-based streaming replacement, complete with cost estimates and SLA tradeoffs, will advance faster than the one who just ships code. Python and SQL are table stakes. Java and Scala matter if you're touching raw Spark or Kafka internals. dbt is quietly becoming a hard requirement at any company running the modern data stack.

Levels & Career Growth

Most external hires land at Mid level, where you own pipelines end-to-end and make real decisions about partitioning, orchestration, and data quality checks. The jump to Staff is where the game changes: you're defining platform roadmaps across teams, setting data contract standards, and leading migrations, not just building things. Getting there requires proof you've influenced architecture org-wide or driven measurable cost reductions at scale. The IC-vs-management fork usually appears around Senior. Principal roles exist but the comp range is enormous, reflecting massive variance between FAANG-tier and mid-market companies. At that altitude, your company selection and negotiation skills matter almost as much as your technical depth.

Data Engineer Compensation

The wide bands you see at every level aren't random noise. A Senior DE at Netflix or Meta can clear $400K+ in total comp, while a Series B startup might offer $200K with options that carry real liquidation risk. Finance shops like Two Sigma and Citadel often beat big tech on cash, though their upside comes through profit-sharing and deferred comp rather than RSUs. Watch for backloaded vesting schedules. Some large tech companies push the bulk of equity into years three and four, which means your actual Year 1 take-home can fall well below the annualized number on your offer letter. Refresh grants (from what candidates report, roughly 20-30% of the initial grant annually at top performers' reviews) help close that gap over time, but they're discretionary.

On-call burden is the most underused negotiation lever in data engineering. If the role includes pager duty for production pipelines, that's a concrete reason to push for a higher base or an explicit on-call stipend. Base salary tends to be banded tightly by level at large companies, so focus your push on signing bonuses (often $20K-$50K at Senior+) and equity acceleration or top-up grants. Competing offers from companies on different cloud stacks (say, an AWS-heavy shop vs. a BigQuery-native one) signal breadth that recruiters can't easily dismiss as an apples-to-oranges comparison.

Data Engineer Interview Process

Most loops wrap up in about five weeks, though your mileage shifts depending on recruiter responsiveness and how quickly you can schedule back-to-back technical rounds. The biggest scheduling bottleneck, from what candidates report, is the system design round: it requires a senior engineer interviewer, and their calendars fill fast. If you can be flexible on timing for that one round, you can sometimes shave a full week off the process.

System design is where most data engineer candidates get eliminated. The common failure mode is jumping straight to tool selection ("We'll use Kafka and Airflow") before clarifying requirements like throughput, data freshness SLAs, or idempotency guarantees. One pattern worth knowing: interviewers across rounds often compare notes before making a hire/no-hire call, so referencing the same architectural tradeoffs in your behavioral stories (using STAR with measurable outcomes like "reduced pipeline latency from 6 hours to 45 minutes") signals consistency that evaluators weight heavily.

Data Engineer Interview Questions

Data Pipelines & Engineering

Expect questions that force you to design reliable batch/streaming flows for training and online features (e.g., Kafka/Flink + Airflow/Dagster). You’ll be evaluated on backfills, late data, idempotency, SLAs, lineage, and operational failure modes.

What is the difference between a batch pipeline and a streaming pipeline, and when would you choose each?

EasyFundamentals

Sample Answer

Batch pipelines process data in scheduled chunks (e.g., hourly, daily ETL jobs). Streaming pipelines process data continuously as it arrives (e.g., Kafka + Flink). Choose batch when: latency tolerance is hours or days (daily reports, model retraining), data volumes are large but infrequent, and simplicity matters. Choose streaming when you need real-time or near-real-time results (fraud detection, live dashboards, recommendation updates). Most companies use both: streaming for time-sensitive operations and batch for heavy analytical workloads, model training, and historical backfills.

You ingest Kafka events for booking state changes (created, confirmed, canceled) into a Hive table, then daily compute confirmed_nights per listing for search ranking. How do you make the Spark job idempotent under retries and late-arriving cancels without double counting?

AirbnbMediumIdempotency and Late Data

Sample Answer

Most candidates default to append-only aggregations with a checkpoint, but that fails here because duplicates and late cancels mutate history and you will overcount. You need a stable event key (booking_id plus event_version or event_timestamp plus source offset) and a dedupe rule, then compute state using last-write-wins or a state machine per booking. Write results with upserts (partition overwrite, MERGE, or Hudi/Iceberg style) keyed by booking_id and listing_id, and drive the aggregation off the canonical booking state, not raw events. Add watermarking and a correction window so late cancels trigger targeted recompute instead of full backfills.

You need a pipeline that produces a near real-time host payout ledger: streaming updates every minute, but also a daily audited snapshot that exactly matches finance when late adjustments arrive up to 30 days. Design the batch plus streaming architecture, including how you handle schema evolution and backfills without breaking downstream tables.

AirbnbHardLambda Architecture and Backfills

Sample Answer

Unlock the full solution

View detailed answers and practice in our question bank

View Solution

Practice more Data Pipelines & Engineering questions

System Design

Most candidates underestimate how much your design must balance latency, consistency, and cost at top tech companies scale. You’ll be evaluated on clear component boundaries, failure modes, and how you’d monitor and evolve the system over time.

Design a dataset registry for LLM training and evaluation that lets you reproduce any run months later, including the exact prompt template, filtering rules, and source snapshots. What metadata and storage layout do you require, and which failure modes does it prevent?

AnthropicMediumDataset Versioning and Lineage

Sample Answer

Use an immutable, content-addressed dataset registry that writes every dataset as a manifest of exact source pointers, transforms, and hashes, plus a separate human-readable release record. Store raw sources append-only, store derived datasets as partitioned files keyed by dataset_id and version, and capture code commit SHA, config, and schema in the manifest so reruns cannot drift. This prevents silent data changes, schema drift, and accidental reuse of a similarly named dataset, which is where most people fail.

A company wants a unified fact table for Marketplace Orders (bookings, cancellations, refunds, chargebacks) that supports finance reporting and ML features, while source systems emit out-of-order updates and occasional duplicates. Design the data model and pipeline, including how you handle upserts, immutable history, backfills, and data quality gates at petabyte scale.

AirbnbHardWarehouse Modeling and Incremental Processing

Sample Answer

Unlock the full solution

View detailed answers and practice in our question bank

View Solution

Practice more System Design questions

SQL & Data Manipulation

Your SQL will get stress-tested on joins, window functions, deduping, and incremental logic that mirrors real ETL/ELT work. Common pitfalls include incorrect grain, accidental fan-outs, and filtering at the wrong stage.

Airflow runs a daily ETL that builds fact_host_daily(host_id, ds, active_listings, booked_nights). Source tables are listings(listing_id, host_id, created_at, deactivated_at) and bookings(booking_id, listing_id, check_in, check_out, status, created_at, updated_at). Write an incremental SQL for ds = :run_date that counts active_listings at end of day and booked_nights for stays overlapping ds, handling late-arriving booking updates by using updated_at.

AirbnbMediumIncremental ETL and Late Arriving Data

Sample Answer

Walk through the logic step by step as if thinking out loud. You start by defining the day window, ds start and ds end. Next, active_listings is a snapshot metric, so you count listings where created_at is before ds end, and deactivated_at is null or after ds end. Then booked_nights is an overlap metric, so you compute the intersection of [check_in, check_out) with [ds, ds+1), but only for non-canceled bookings. Finally, for incrementality you only scan bookings that could affect ds, either the stay overlaps ds or the record was updated recently, and you upsert the single ds partition for each host.

WITH params AS (
  SELECT
    CAST(:run_date AS DATE) AS ds,
    CAST(:run_date AS TIMESTAMP) AS ds_start_ts,
    CAST(:run_date AS TIMESTAMP) + INTERVAL '1' DAY AS ds_end_ts
),
active_listings_by_host AS (
  SELECT
    l.host_id,
    p.ds,
    COUNT(*) AS active_listings
  FROM listings l
  CROSS JOIN params p
  WHERE l.created_at < p.ds_end_ts
    AND (l.deactivated_at IS NULL OR l.deactivated_at >= p.ds_end_ts)
  GROUP BY l.host_id, p.ds
),
-- Limit booking scan for incremental run.
-- Assumption: you run daily and keep a small lookback for late updates.
-- This reduces IO while still catching updates that change ds attribution.
bookings_candidates AS (
  SELECT
    b.booking_id,
    b.listing_id,
    b.check_in,
    b.check_out,
    b.status,
    b.updated_at
  FROM bookings b
  CROSS JOIN params p
  WHERE b.updated_at >= p.ds_start_ts - INTERVAL '7' DAY
    AND b.updated_at < p.ds_end_ts + INTERVAL '1' DAY
),
booked_nights_by_host AS (
  SELECT
    l.host_id,
    p.ds,
    SUM(
      CASE
        WHEN bc.status = 'canceled' THEN 0
        -- Compute overlap nights between [check_in, check_out) and [ds, ds+1)
        ELSE GREATEST(
          0,
          DATE_DIFF(
            'day',
            GREATEST(CAST(bc.check_in AS DATE), p.ds),
            LEAST(CAST(bc.check_out AS DATE), p.ds + INTERVAL '1' DAY)
          )
        )
      END
    ) AS booked_nights
  FROM bookings_candidates bc
  JOIN listings l
    ON l.listing_id = bc.listing_id
  CROSS JOIN params p
  WHERE CAST(bc.check_in AS DATE) < p.ds + INTERVAL '1' DAY
    AND CAST(bc.check_out AS DATE) > p.ds
  GROUP BY l.host_id, p.ds
),
final AS (
  SELECT
    COALESCE(al.host_id, bn.host_id) AS host_id,
    (SELECT ds FROM params) AS ds,
    COALESCE(al.active_listings, 0) AS active_listings,
    COALESCE(bn.booked_nights, 0) AS booked_nights
  FROM active_listings_by_host al
  FULL OUTER JOIN booked_nights_by_host bn
    ON bn.host_id = al.host_id
   AND bn.ds = al.ds
)
-- In production this would be an upsert into the ds partition.
SELECT *
FROM final
ORDER BY host_id;

Event stream table listing_price_events(listing_id, event_time, ingest_time, price_usd) can contain duplicates and out-of-order arrivals. Write SQL to build a daily snapshot table listing_price_daily(listing_id, ds, price_usd, event_time) for ds = :run_date using the latest event_time within the day, breaking ties by latest ingest_time, and ensuring exactly one row per listing per ds.

AirbnbHardWindow Functions and Deduping

Sample Answer

Unlock the full solution

View detailed answers and practice in our question bank

View Solution

Practice more SQL & Data Manipulation questions

Data Warehouse

A the company client wants one the company account shared by 15 business units, each with its own analysts, plus a central the company X delivery team that runs dbt and Airflow. Design the warehouse layer and access model (schemas, roles, row level security, data products) so units cannot see each other’s data but can consume shared conformed dimensions.

Boston Consulting Group (BCG)MediumMulti-tenant warehouse architecture and access control

Sample Answer

Most candidates default to separate databases per business unit, but that fails here because conformed dimensions and shared transformation code become duplicated and drift fast. You want a shared curated layer for conformed entities (customer, product, calendar) owned by a platform team, plus per unit marts or data products with strict role based access control. Use the company roles with least privilege, database roles, and row access policies (and masking policies) keyed on tenant identifiers where physical separation is not feasible. Put ownership, SLAs, and contract tests on the shared layer so every unit trusts the same definitions.

A Redshift cluster powers an operations dashboard where 150 concurrent users run the same 3 queries, one query scans fact_clickstream (10 TB) joined to dim_sku and dim_marketplace and groups by day and marketplace, but it spikes to 40 minutes at peak. What concrete Redshift table design changes (DISTKEY, SORTKEY, compression, materialized views) and workload controls would you apply, and how do you validate each change with evidence?

AmazonHardRedshift Physical Design and Concurrency

Sample Answer

Unlock the full solution

View detailed answers and practice in our question bank

View Solution

Practice more Data Warehouse questions

Data Modeling

Rather than raw SQL skill, you’re judged on how you structure facts, dimensions, and metrics so downstream analytics stays stable. Watch for prompts around SCD types, grain definition, and metric consistency across Sales/Analytics consumers.

A company has a daily snapshot table listing_snapshot(listing_id, ds, price, is_available, host_id, city_id) and an events table booking_event(booking_id, listing_id, created_at, check_in, check_out). Write SQL to compute booked nights and average snapshot price at booking time by city and ds, where snapshot ds is the booking created_at date.

AirbnbMediumSnapshot vs Event Join

Sample Answer

Start with what the interviewer is really testing: "This question is checking whether you can align event time to snapshot time without creating fanout joins or time leakage." You join booking_event to listing_snapshot on listing_id plus the derived snapshot date, then aggregate nights as $\text{datediff}(\text{check\_out}, \text{check\_in})$. You also group by snapshot ds and city_id, and you keep the join predicates tight so each booking hits at most one snapshot row.

SELECT
  ls.ds,
  ls.city_id,
  SUM(DATE_DIFF('day', be.check_in, be.check_out)) AS booked_nights,
  AVG(ls.price) AS avg_snapshot_price_at_booking
FROM booking_event be
JOIN listing_snapshot ls
  ON ls.listing_id = be.listing_id
 AND ls.ds = DATE(be.created_at)
GROUP BY 1, 2;

You are designing a star schema for host earnings and need to support two use cases: monthly payouts reporting and real-time fraud monitoring on payout anomalies. How do you model payout facts and host and listing dimensions, including slowly changing attributes like host country and payout method, so both use cases stay correct?

AirbnbHardSCD and Multi-Use Fact Modeling

Sample Answer

Unlock the full solution

View detailed answers and practice in our question bank

View Solution

Practice more Data Modeling questions

Coding & Algorithms

Your ability to reason about constraints and produce correct, readable Python under time pressure is a major differentiator. You’ll need solid data-structure choices, edge-case handling, and complexity awareness rather than exotic CS theory.

Given a stream of (asin, customer_id, ts) clicks for an detail page, compute the top K ASINs by unique customer count within the last 24 hours for a given query time ts_now. Input can be unsorted, and you must handle duplicates and out-of-window events correctly.

AmazonMediumSliding Window Top-K

Sample Answer

Get this wrong in production and your top ASIN dashboard flaps, because late events and duplicates inflate counts and reorder the top K every refresh. The right call is to filter by the $24$ hour window relative to ts_now, dedupe by (asin, customer_id), then use a heap or partial sort to extract K efficiently.

from __future__ import annotations

from datetime import datetime, timedelta
from typing import Iterable, List, Tuple, Dict, Set
import heapq


def _parse_time(ts: str) -> datetime:
    """Parse ISO-8601 timestamps, supporting a trailing 'Z'."""
    if ts.endswith("Z"):
        ts = ts[:-1] + "+00:00"
    return datetime.fromisoformat(ts)


def top_k_asins_unique_customers_last_24h(
    events: Iterable[Tuple[str, str, str]],
    ts_now: str,
    k: int,
) -> List[Tuple[str, int]]:
    """Return top K (asin, unique_customer_count) in the last 24h window.

    events: iterable of (asin, customer_id, ts) where ts is ISO-8601 string.
    ts_now: window reference time (ISO-8601).
    k: number of ASINs to return.

    Ties are broken by ASIN lexicographic order (stable, deterministic output).
    """
    now = _parse_time(ts_now)
    start = now - timedelta(hours=24)

    # Deduplicate by (asin, customer_id) within the window.
    # If events are huge, you would partition by asin or approximate, but here keep it exact.
    seen_pairs: Set[Tuple[str, str]] = set()
    customers_by_asin: Dict[str, Set[str]] = {}

    for asin, customer_id, ts in events:
        t = _parse_time(ts)
        if t < start or t > now:
            continue
        pair = (asin, customer_id)
        if pair in seen_pairs:
            continue
        seen_pairs.add(pair)
        customers_by_asin.setdefault(asin, set()).add(customer_id)

    # Build counts.
    counts: List[Tuple[int, str]] = []
    for asin, custs in customers_by_asin.items():
        counts.append((len(custs), asin))

    if k <= 0:
        return []

    # Get top K by count desc, then asin asc.
    # heapq.nlargest uses the tuple ordering, so use (count, -) carefully.
    top = heapq.nlargest(k, counts, key=lambda x: (x[0], -ord(x[1][0]) if x[1] else 0))

    # The key above is not a correct general lexicographic tiebreak, so do it explicitly.
    # Sort all candidates by (-count, asin) and slice K. This is acceptable for moderate cardinality.
    top_sorted = sorted(((asin, cnt) for cnt, asin in counts), key=lambda p: (-p[1], p[0]))
    return top_sorted[:k]


if __name__ == "__main__":
    data = [
        ("B001", "C1", "2024-01-02T00:00:00Z"),
        ("B001", "C1", "2024-01-02T00:01:00Z"),  # duplicate customer for same ASIN
        ("B001", "C2", "2024-01-02T01:00:00Z"),
        ("B002", "C3", "2024-01-01T02:00:00Z"),
        ("B003", "C4", "2023-12-31T00:00:00Z"),  # out of window
    ]
    print(top_k_asins_unique_customers_last_24h(data, "2024-01-02T02:00:00Z", 2))

Given a list of nightly booking records {"listing_id": int, "guest_id": int, "checkin": int day, "checkout": int day} (checkout is exclusive), flag each listing_id that is overbooked, meaning at least one day has more than $k$ active stays, and return the earliest day where the maximum occupancy exceeds $k$.

AirbnbHardSweep Line Overlap Counting

Sample Answer

Unlock the full solution

View detailed answers and practice in our question bank

View Solution

Practice more Coding & Algorithms questions

Data Engineering

You need to join a 5 TB Delta table of per-frame telemetry with a 50 GB Delta table of trip metadata on trip_id to produce a canonical fact table in the company. Would you rely on broadcast join or shuffle join, and what explicit configs or hints would you set to make it stable and cost efficient?

CruiseMediumSpark Joins and Partitioning

Sample Answer

You could force a broadcast join of the 50 GB table or run a standard shuffle join on trip_id. Broadcast wins only if the metadata table can reliably fit in executor memory across the cluster, otherwise you get OOM or repeated GC and retries. In most real clusters 50 GB is too big to broadcast safely, so shuffle join wins, then you make it stable by pre-partitioning or bucketing by trip_id where feasible, tuning shuffle partitions, and enabling AQE to coalesce partitions.

from pyspark.sql import functions as F

# Inputs
telemetry = spark.read.format("delta").table("raw.telemetry_frames")  # very large
trips = spark.read.format("delta").table("dim.trip_metadata")          # large but smaller

# Prefer shuffle join with AQE for stability
spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")

# Right-size shuffle partitions, set via env or job config in practice
spark.conf.set("spark.sql.shuffle.partitions", "4000")

# Pre-filter early if possible to reduce shuffle
telemetry_f = telemetry.where(F.col("event_date") >= F.date_sub(F.current_date(), 7))
trips_f = trips.select("trip_id", "vehicle_id", "route_id", "start_ts", "end_ts")

joined = (
    telemetry_f
    .join(trips_f.hint("shuffle_hash"), on="trip_id", how="inner")
)

# Write out with sane partitioning and file sizing
(
    joined
    .repartition("event_date")
    .write
    .format("delta")
    .mode("overwrite")
    .option("overwriteSchema", "true")
    .saveAsTable("canon.fact_telemetry_enriched")
)

A company Support wants a governed semantic layer for "First Response Time" and "Resolution Time" across email and chat, and an LLM tool will answer questions using those metrics. How do you enforce metric definitions, data access, and quality guarantees so the LLM and Looker both return consistent numbers and do not leak restricted fields?

CoinbaseHardGovernance, Semantic Layer, and Access Controls

Sample Answer

Unlock the full solution

View detailed answers and practice in our question bank

View Solution

Practice more Data Engineering questions

Cloud Infrastructure

In practice, you’ll need to articulate why you’d pick Spark/Hive vs an MPP warehouse vs Cassandra for a specific workload. Interviewers look for pragmatic tradeoffs: throughput vs latency, partitioning/sharding choices, and operational constraints.

A the company warehouse for a client’s KPI dashboard has unpredictable concurrency, and monthly spend is spiking. What specific changes do you make to balance performance and cost, and what signals do you monitor to validate the change?

Boston Consulting Group (BCG)MediumCost and performance optimization

Sample Answer

The standard move is to right-size compute, enable auto-suspend and auto-resume, and separate workloads with different warehouses (ELT, BI, ad hoc). But here, concurrency matters because scaling up can be cheaper than scaling out if query runtime drops sharply, and scaling out can be required if queueing dominates. You should call out monitoring of queued time, warehouse load, query history, cache hit rates, and top cost drivers by user, role, and query pattern. You should also mention guardrails like resource monitors and workload isolation via roles and warehouse assignment.

You need near real-time order events (p95 under 5 seconds) for an Operations dashboard and also a durable replayable history for backfills, events are 20k per second at peak. How do you choose between Kinesis Data Streams plus Lambda versus Kinesis Firehose into S3 plus Glue, and what IAM, encryption, and monitoring controls do you put in place?

AmazonHardStreaming Ingestion Tradeoffs and Security

Sample Answer

Unlock the full solution

View detailed answers and practice in our question bank

View Solution

Practice more Cloud Infrastructure questions

The distribution tells a clear story: interviewers care far more about how you connect Airflow orchestration to Snowflake schema choices to Kafka failure handling than whether you can invert a binary tree. Where system design overlaps with data modeling, the difficulty compounds. You might be asked to sketch a pipeline in one breath and then defend your SCD Type 2 strategy for a dimension table in the next, so practicing these areas in isolation leaves you exposed to the rounds that most often end in rejection. Rather than splitting prep time evenly across all eight areas, weight it toward the architecture-heavy topics and drill concrete patterns (star schema grain definitions, idempotent backfills in dbt, partition pruning in BigQuery) that show up repeatedly.

Explore questions across all eight areas, matched to real interview frequency, at datainterview.com/questions.

How to Prepare

Your first two weeks should lean heavily into pipeline architecture and system design practice. Sketch out real systems on Excalidraw: an event-driven ingestion layer with Kafka feeding Spark Structured Streaming, a batch orchestration pipeline in Airflow with retry policies and SLA alerting, an incremental dbt pipeline handling late-arriving facts via merge statements. For each design, spend 15 minutes narrating tradeoffs aloud (Parquet vs. Avro for nested data, star schema vs. one-big-table for dashboard workloads, partitioning by date vs. tenant ID for multi-tenant SaaS).

Starting week three, shift your weight toward SQL depth and cloud platform specifics while keeping one 30-minute design session daily. Solve two window-function problems each morning (sessionization over clickstreams, running totals with partition resets, funnel analysis using recursive CTEs), then spend one afternoon per week designing schemas from scratch and running EXPLAIN ANALYZE on deliberately slow queries in a local Postgres instance to build intuition around index selection and nested-loop vs. hash-join behavior.

For cloud prep, focus on the platform your target companies actually use: S3 event notifications wiring into Lambda for file-arrival triggers on AWS, BigQuery clustering vs. partitioning cost tradeoffs on GCP, or Snowflake warehouse sizing and auto-suspend tuning. Build a small end-to-end portfolio project during this phase (API ingestion through Airflow into Snowflake with dbt transformations) so you can reference specific Airflow operator configs and dbt test failures you debugged during behavioral and case study rounds.

Try a Real Interview Question

WITH latest_event AS (
  SELECT
    e.transaction_id,
    e.merchant_id,
    e.event_ts,
    DATE(e.event_ts) AS event_date,
    e.status,
    CAST(e.amount_usd AS NUMERIC) AS amount_usd,
    ROW_NUMBER() OVER (
      PARTITION BY e.transaction_id
      ORDER BY e.event_ts DESC
    ) AS rn
  FROM payment_events e
  WHERE DATE(e.event_ts) BETWEEN DATE '2026-01-10' AND DATE '2026-01-11'
)
SELECT
  le.event_date,
  le.merchant_id,
  SUM(
    CASE
      WHEN le.status = 'COMPLETED' THEN le.amount_usd
      WHEN le.status IN ('REFUNDED', 'CHARGEBACK') THEN -le.amount_usd
      ELSE CAST(0 AS NUMERIC)
    END
  ) AS net_amount_usd
FROM latest_event le
WHERE le.rn = 1
GROUP BY le.event_date, le.merchant_id
ORDER BY le.event_date, le.merchant_id;

DE interview problems tend to combine schema ambiguity with performance reasoning. You might face a slowly changing dimension that requires you to pick between SCD Type 2 and snapshot tables, then explain how partition pruning affects your query plan. Practice more problems like this at datainterview.com/coding.

Test Your Readiness

See how you score, then drill your weak spots using the full question bank at datainterview.com/questions.