Airbnb Data Engineer Interview Guide

From hundreds of mock interviews, one pattern keeps tripping up Airbnb data engineer candidates: they prep like it's a data role and get blindsided by how much it feels like a software engineering interview. Airbnb's onsite includes a dedicated coding round plus a technical phone screen that also tests coding, and the bar is production-grade code with tests. If you walk in thinking "I'm good at SQL and Airflow," you're underprepared.

Airbnb Data Engineer Role

Airbnb's data engineers own the infrastructure that every other data consumer in the company depends on. You'll build and maintain Spark and Flink pipelines that feed Minerva (Airbnb's homegrown semantic layer for company-wide metric definitions), design warehouse schemas in Hive and Presto that downstream analytics, ML, and finance teams query daily, and keep real-time event streams flowing for Search Ranking and Pricing models. Success after year one looks like owning a critical pipeline end-to-end, from ingestion through transformation to serving, with clean SLAs and zero surprises for your stakeholders.

A Typical Week

The thing that jumps out from the time split isn't the coding percentage. It's how much of your week is reactive: patching a broken Airflow DAG because an upstream Presto schema changed, triaging a data quality alert on the listing availability table, writing up on-call handoff docs so the next rotation doesn't walk into surprises. On-call is real and consequential at Airbnb, and the seasonal spikiness of a global travel marketplace makes pipeline reliability non-trivial. Midweek deep-work blocks are fiercely protected, which is when the actual Spark development and Flink tuning happens.

Projects & Impact Areas

Payments data engineering has you building Spark pipelines for transaction reconciliation across dozens of currencies, while the Listings Structured Data team operates at a different altitude, maintaining canonical data models that Search Ranking and ML teams consume as features. Land on the Foundational Data team and you're working on the platform itself, where your modeling decisions have blast radius across every analytics dashboard and ML model in the company.

Skills & What's Expected

Business acumen is the most underrated skill for this role. Airbnb DEs regularly sit in rooms with product managers and data scientists, making modeling decisions that shape how the company measures bookings, host quality, and pricing. The skill data shows expert-level software engineering as table stakes, and Airbnb's engineering blog on maintaining an inclusive codebase makes clear why: every PR gets scrutinized for quality, naming conventions, and backward compatibility, and that standard applies to data pipelines just as much as product code.

Levels & Career Growth

The widget shows the level bands, but here's what it can't tell you: the L5-to-L6 promotion bar shifts from "owns pipelines well" to "sets data platform strategy across multiple teams." Airbnb's flatter org structure means fewer promotion slots at Staff and above, so you can't just be technically deep. L6+ requires visible cross-org influence, like leading an RFC that changes how three teams model their data or driving a migration that touches the entire warehouse.

Work Culture

Airbnb's "live and work anywhere" policy is one of the few in big tech that's genuinely flexible, including international stays up to 90 days. Many SF-based DEs still come in Tuesday through Thursday for collaboration. The pace is intense but deliberate: Airbnb values craftsmanship and thorough design docs over shipping fast, and their investment in developer experience tooling means you're less likely to fight your own infra than at scrappier companies.

Airbnb Data Engineer Compensation

The one-year cliff on RSUs means your actual cash flow in months 1 through 11 is just base plus bonus. Your offer letter quotes an annualized total comp figure that bakes in equity you won't see until the cliff hits, so plan your finances accordingly. The L6-to-L7 jump is the largest comp gap in the ladder, and it coincides with a scope shift from multi-team platform ownership to company-wide technical strategy.

Airbnb's offer negotiation notes emphasize negotiating the overall package rather than fixating on one component. Avoid disclosing competing numbers or current salary early in the process, since the company's own guidance suggests that preserving information asymmetry is your best lever for a stronger equity or bonus outcome.

Airbnb Data Engineer Interview Process

Two coding rounds in a single DE loop is unusual. Most companies give you one shot at algorithms and spend the rest on SQL or pipeline design. Airbnb's onsite coding round ramps up the complexity with data processing logic and scalability considerations, so treating it as a repeat of the phone screen is a mistake. Prep for both rounds independently, with the second skewing toward harder problems involving data manipulation at scale.

The system design round trips up a lot of candidates because it's scoped to data platforms, not generic backend architecture. Interviewers expect you to walk through ingestion, transformation, and serving layers while defending tradeoffs around batch vs. streaming, fault tolerance, and monitoring. Pair that with a behavioral round where Airbnb evaluates ownership and cross-functional collaboration with real scrutiny (not a rubber stamp), and you've got a loop where no single round is safe to underinvest in.

Airbnb Data Engineer Interview Questions

1WITH recent_bookings AS (
2  SELECT
3    b.booking_id,
4    b.check_in_date,
5    b.total_amount_usd
6  FROM bookings b
7  WHERE b.check_in_date >= CURRENT_DATE - INTERVAL '30' DAY
8    AND b.check_in_date < CURRENT_DATE
9    AND b.status <> 'canceled'
10),
11booking_rev AS (
12  SELECT
13    rb.check_in_date,
14    SUM(rb.total_amount_usd) AS gross_revenue_usd
15  FROM recent_bookings rb
16  GROUP BY rb.check_in_date
17),
18refunds_by_checkin AS (
19  SELECT
20    rb.check_in_date,
21    SUM(r.refund_amount_usd) AS refunds_usd
22  FROM recent_bookings rb
23  JOIN refunds r
24    ON r.booking_id = rb.booking_id
25  GROUP BY rb.check_in_date
26)
27SELECT
28  br.check_in_date,
29  br.gross_revenue_usd - COALESCE(rbc.refunds_usd, 0) AS net_revenue_usd,
30  br.gross_revenue_usd,
31  COALESCE(rbc.refunds_usd, 0) AS refunds_usd
32FROM booking_rev br
33LEFT JOIN refunds_by_checkin rbc
34  ON rbc.check_in_date = br.check_in_date
35ORDER BY br.check_in_date;

1WITH params AS (
2  SELECT
3    CAST(:run_date AS DATE) AS ds,
4    CAST(:run_date AS TIMESTAMP) AS ds_start_ts,
5    CAST(:run_date AS TIMESTAMP) + INTERVAL '1' DAY AS ds_end_ts
6),
7active_listings_by_host AS (
8  SELECT
9    l.host_id,
10    p.ds,
11    COUNT(*) AS active_listings
12  FROM listings l
13  CROSS JOIN params p
14  WHERE l.created_at < p.ds_end_ts
15    AND (l.deactivated_at IS NULL OR l.deactivated_at >= p.ds_end_ts)
16  GROUP BY l.host_id, p.ds
17),
18-- Limit booking scan for incremental run.
19-- Assumption: you run daily and keep a small lookback for late updates.
20-- This reduces IO while still catching updates that change ds attribution.
21bookings_candidates AS (
22  SELECT
23    b.booking_id,
24    b.listing_id,
25    b.check_in,
26    b.check_out,
27    b.status,
28    b.updated_at
29  FROM bookings b
30  CROSS JOIN params p
31  WHERE b.updated_at >= p.ds_start_ts - INTERVAL '7' DAY
32    AND b.updated_at < p.ds_end_ts + INTERVAL '1' DAY
33),
34booked_nights_by_host AS (
35  SELECT
36    l.host_id,
37    p.ds,
38    SUM(
39      CASE
40        WHEN bc.status = 'canceled' THEN 0
41        -- Compute overlap nights between [check_in, check_out) and [ds, ds+1)
42        ELSE GREATEST(
43          0,
44          DATE_DIFF(
45            'day',
46            GREATEST(CAST(bc.check_in AS DATE), p.ds),
47            LEAST(CAST(bc.check_out AS DATE), p.ds + INTERVAL '1' DAY)
48          )
49        )
50      END
51    ) AS booked_nights
52  FROM bookings_candidates bc
53  JOIN listings l
54    ON l.listing_id = bc.listing_id
55  CROSS JOIN params p
56  WHERE CAST(bc.check_in AS DATE) < p.ds + INTERVAL '1' DAY
57    AND CAST(bc.check_out AS DATE) > p.ds
58  GROUP BY l.host_id, p.ds
59),
60final AS (
61  SELECT
62    COALESCE(al.host_id, bn.host_id) AS host_id,
63    (SELECT ds FROM params) AS ds,
64    COALESCE(al.active_listings, 0) AS active_listings,
65    COALESCE(bn.booked_nights, 0) AS booked_nights
66  FROM active_listings_by_host al
67  FULL OUTER JOIN booked_nights_by_host bn
68    ON bn.host_id = al.host_id
69   AND bn.ds = al.ds
70)
71-- In production this would be an upsert into the ds partition.
72SELECT *
73FROM final
74ORDER BY host_id;

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

1from __future__ import annotations
2
3import json
4from dataclasses import dataclass
5from typing import Dict, Iterable, Optional, Set
6
7
8@dataclass
9class ThreadState:
10    """Per-thread state needed to compute first host reply latency."""
11
12    earliest_guest_ts: Optional[int] = None
13    first_host_latency: Optional[int] = None
14
15
16def first_host_reply_latency(json_lines: Iterable[str]) -> Dict[str, Optional[int]]:
17    """Compute first host reply latency per thread.
18
19    Args:
20        json_lines: Iterable of JSON strings, one event per line.
21
22    Returns:
23        Dict mapping thread_id to latency in seconds, or None if no host reply.
24
25    Notes:
26        - Duplicate message_id entries are ignored (retries).
27        - Latency is measured as first host message timestamp minus earliest guest timestamp.
28        - If host message arrives before any guest message for that thread, it is ignored.
29    """
30
31    seen_message_ids: Set[str] = set()
32    threads: Dict[str, ThreadState] = {}
33
34    for line in json_lines:
35        line = line.strip()
36        if not line:
37            continue
38
39        event = json.loads(line)
40        message_id = event["message_id"]
41        if message_id in seen_message_ids:
42            continue
43        seen_message_ids.add(message_id)
44
45        thread_id = event["thread_id"]
46        role = event["sender_role"]
47        ts = int(event["sent_at"])
48
49        state = threads.get(thread_id)
50        if state is None:
51            state = ThreadState()
52            threads[thread_id] = state
53
54        # If already computed, you still keep state stable and ignore later messages.
55        if state.first_host_latency is not None:
56            # Still update earliest guest timestamp for correctness if needed by spec changes.
57            if role == "guest":
58                if state.earliest_guest_ts is None or ts < state.earliest_guest_ts:
59                    state.earliest_guest_ts = ts
60            continue
61
62        if role == "guest":
63            if state.earliest_guest_ts is None or ts < state.earliest_guest_ts:
64                state.earliest_guest_ts = ts
65        elif role == "host":
66            if state.earliest_guest_ts is None:
67                # No guest message observed yet, cannot compute latency.
68                continue
69            # First host reply after the earliest guest message.
70            latency = ts - state.earliest_guest_ts
71            if latency >= 0:
72                state.first_host_latency = latency
73            # If negative, ignore as out-of-order or bad data.
74        else:
75            raise ValueError(f"Unknown sender_role: {role}")
76
77    return {thread_id: state.first_host_latency for thread_id, state in threads.items()}
78
79
80if __name__ == "__main__":
81    sample = [
82        '{"message_id":"m1","thread_id":"t1","sender_role":"guest","sent_at":100}',
83        '{"message_id":"m2","thread_id":"t1","sender_role":"host","sent_at":160}',
84        '{"message_id":"m2","thread_id":"t1","sender_role":"host","sent_at":160}',
85        '{"message_id":"m3","thread_id":"t2","sender_role":"guest","sent_at":200}',
86    ]
87    print(first_host_reply_latency(sample))
88

System design questions at Airbnb don't exist in a vacuum. They presuppose fluency with pipeline mechanics (idempotent writes, backfill logic, schema evolution) because you'll be asked to design something like a unified marketplace fact table and then defend how it actually gets built and maintained. The compounding effect between these two areas is where most underprepared candidates stall, since you can't sketch a conversion funnel architecture without knowing how late-arriving booking events or Airflow retry semantics will warp your output.

Practice Airbnb-caliber pipeline, modeling, and SQL questions at datainterview.com/questions.

How to Prepare for Airbnb Data Engineer Interviews

Airbnb's north star is a billion annual guests by 2028, up from a base of $12.2B in revenue growing 12% year-over-year. Two recent bets make this concrete for DEs: the reserve-now-pay-later feature going global splits payment events across new timelines and currencies, while the FIFA World Cup 2026 hosting initiative will concentrate demand into specific metro areas at unprecedented density. Read Airbnb's engineering blog on continuous delivery and maintaining quality at scale before your interviews, because these posts reveal the exact tradeoffs (deployment velocity vs. pipeline reliability) that show up in design and behavioral conversations.

For your "why Airbnb" answer, don't talk about the consumer product. Instead, reference something specific you read in those engineering posts, like how Airbnb's CD pipeline means a broken data job can block deploys company-wide, or how their biggest night ever created the kind of seasonal spike that stress-tests every assumption in a data model.

Try a Real Interview Question

1WITH dedup_events AS (
2  SELECT DISTINCT
3    booking_id,
4    event_time,
5    event_type
6  FROM booking_events
7), latest_status AS (
8  SELECT
9    booking_id,
10    event_time,
11    event_type,
12    ROW_NUMBER() OVER (
13      PARTITION BY booking_id
14      ORDER BY event_time DESC
15    ) AS rn
16  FROM dedup_events
17), confirmed_bookings AS (
18  SELECT
19    ls.booking_id,
20    DATE(ls.event_time) AS event_date
21  FROM latest_status ls
22  WHERE ls.rn = 1
23    AND ls.event_type = 'confirmed'
24)
25SELECT
26  cb.event_date,
27  COUNT(*) AS confirmed_booking_count,
28  SUM(b.nights) AS total_confirmed_nights
29FROM confirmed_bookings cb
30JOIN bookings b
31  ON b.booking_id = cb.booking_id
32GROUP BY cb.event_date
33ORDER BY cb.event_date;

Airbnb's coding rounds reward clean, reviewable Python over clever algorithmic tricks. Their engineering culture and inclusive codebase posts make it clear they optimize for code that teammates can maintain, so practice writing solutions you'd be proud to submit in a PR. Build that muscle at datainterview.com/coding.

Test Your Readiness

Find out which topic areas need the most work before your recruiter screen at datainterview.com/questions.