Airbnb Data Scientist Interview Guide

Most candidates who bomb Airbnb's DS loop fail on the product sense, not the stats. The interview weights Product Sense & Metrics and Experimentation at a combined 40%, and the questions are grounded in two-sided marketplace tradeoffs (guest conversion vs. host earnings, search ranking vs. listing diversity). Pure ML depth won't save you if you can't reason about why a pricing nudge on the checkout page might cannibalize bookings in a different market segment.

Airbnb Data Scientist Role

At Airbnb, data scientists sit embedded within product pods like Search & Matching, Guest Growth, Trust & Safety, and Payments rather than in a centralized analytics org. You own the full lifecycle: scoping an experiment on dynamic pricing nudges, building a doubly-robust estimator for heterogeneous treatment effects across guest segments, then presenting a recommendation to product leadership. Success after year one means you've influenced a major product decision with causal evidence that changed what shipped.

A Typical Week

The surprise in the breakdown isn't any single category. It's how much time goes to written artifacts: experiment design docs, readout decks, code documentation. If your mental model of a DS role is "query, model, repeat," the volume of cross-functional storytelling at Airbnb will catch you off guard. Expect upstream schema changes from Data Engineering to break your joins on random afternoons, and nobody else will patch your query for you.

Projects & Impact Areas

Search ranking and pricing algorithms are where DS work most directly shapes Airbnb's marketplace balance, influencing metrics like booking-through rate and listing diversity across 220+ countries. The forecasting team, meanwhile, builds models that finance leadership relies on for revenue planning, a very different flavor of DS work from the experimentation-heavy search pod. Trust & Safety data scientists use LLM-based topic modeling to cluster negative guest reviews and surface emerging pain points around check-in experiences, an area where Airbnb is actively expanding its DS headcount.

Skills & What's Expected

The most underrated skill for this role is software engineering. Airbnb rates it high, meaning you're expected to write production-quality Python with proper docstrings and push reproducible scripts to shared repos. Cloud deployment and infrastructure management are low priority, but data pipelines and data management tools sit at medium, so don't confuse "you won't deploy to prod" with "you can ignore how data flows." The overrated prep move? Over-indexing on MLOps tooling when the interview leans hard on causal inference and product thinking.

Levels & Career Growth

The L5-to-L6 jump is where careers stall, because Staff isn't about shipping better analyses. It's about setting org-wide methodology, like defining experimentation standards or building the causal inference framework other teams adopt. The IC track reaches Principal (L7) without managing people, but the scope expectations at that level (per Airbnb's own descriptions) involve driving technical strategy across multiple product areas and partnering with Directors and VPs.

Work Culture

Airbnb's live-and-work-anywhere policy lets you work remotely within your country, with San Francisco teams clustering in-person on Tuesdays and Wednesdays for cross-functional syncs rather than following a fixed RTO schedule. The pace is deliberate but high-accountability: weeks revolve around experiment cycles and readout deadlines, not constant firefighting. Shared experiment registries, collaborative code reviews, and a culture of documenting decisions mean your written communication matters as much as your Python.

Airbnb Data Scientist Compensation

The one-year cliff is the detail that matters most here. Leave before month 12 and you walk away with zero equity, which makes that first year a real retention lock. After the cliff, quarterly vesting smooths things out, but you should evaluate any RSU grant conservatively since share prices can move a lot between offer day and vest day.

When negotiating, the source data confirms that base, RSUs, and sign-on bonus are all movable pieces. RSU count and sign-on bonus tend to have more room than base salary, so lead with those. A sign-on bonus specifically helps offset the cliff year where you're earning no equity, and the offer negotiation process explicitly supports asking for one. Bring a competing offer if you have one; it gives the recruiter concrete numbers to work with when going back to the comp team.

Airbnb Data Scientist Interview Process

The loop runs about five weeks end to end. Candidates who get rejected most often share a pattern: strong technical output with weak storytelling. The take-home is where this kills you. Airbnb's take-home asks you to explore a messy dataset and present findings, and reviewers weight narrative clarity and actionable recommendations as heavily as code quality. A notebook full of pandas transformations with no written "so what" about guest conversion or host retention won't advance.

The behavioral round carries real veto power in the final decision. Airbnb's interview materials explicitly ask you to connect your past work to their mission of creating belonging through travel, and interviewers probe for specific examples of building inclusive teams or designing for diverse user populations across their 220+ country footprint. Candidates from pure quant backgrounds sometimes treat this as a formality, then get a rejection despite strong technical scores.

Airbnb Data Scientist Interview Questions

-- Compute daily search-to-booking conversion with last-touch attribution within session and 7 days
-- Assumed tables:
--   analytics.search_events(search_id, user_id, session_id, searched_at, checkin_date, checkout_date, city_id)
--   analytics.booking_events(booking_id, user_id, session_id, booked_at, status)

WITH eligible_bookings AS (
  SELECT
    b.booking_id,
    b.user_id,
    b.session_id,
    b.booked_at
  FROM analytics.booking_events b
  WHERE b.status = 'confirmed'
),
search_booking_pairs AS (
  SELECT
    b.booking_id,
    b.booked_at,
    s.search_id,
    s.searched_at,
    -- rank searches per booking by recency
    ROW_NUMBER() OVER (
      PARTITION BY b.booking_id
      ORDER BY s.searched_at DESC
    ) AS rn
  FROM eligible_bookings b
  JOIN analytics.search_events s
    ON s.session_id = b.session_id
   AND s.user_id = b.user_id
   AND s.searched_at <= b.booked_at
   AND s.searched_at >= b.booked_at - INTERVAL '7 days'
),
last_touch_attribution AS (
  SELECT
    booking_id,
    search_id,
    searched_at,
    booked_at
  FROM search_booking_pairs
  WHERE rn = 1
),
searches_by_day AS (
  SELECT
    DATE_TRUNC('day', searched_at) AS search_day,
    COUNT(DISTINCT search_id) AS searches
  FROM analytics.search_events
  GROUP BY 1
),
bookings_attributed_by_search_day AS (
  SELECT
    DATE_TRUNC('day', searched_at) AS search_day,
    COUNT(DISTINCT booking_id) AS attributed_bookings
  FROM last_touch_attribution
  GROUP BY 1
)
SELECT
  s.search_day,
  s.searches,
  COALESCE(b.attributed_bookings, 0) AS attributed_bookings,
  CASE
    WHEN s.searches = 0 THEN 0
    ELSE COALESCE(b.attributed_bookings, 0)::DECIMAL / s.searches
  END AS search_to_booking_cvr
FROM searches_by_day s
LEFT JOIN bookings_attributed_by_search_day b
  ON b.search_day = s.search_day
ORDER BY 1;

-- Experiment conversion using first-exposure cohorting and a post-exposure window
-- Assumed tables:
--   exp.checkout_exposures(experiment_id, user_id, variant, exposed_at)
--   analytics.booking_events(booking_id, user_id, booked_at, status)

WITH first_exposure AS (
  SELECT
    e.experiment_id,
    e.user_id,
    e.variant,
    MIN(e.exposed_at) AS first_exposed_at
  FROM exp.checkout_exposures e
  WHERE e.experiment_id = 'checkout_page_v2'
  GROUP BY 1, 2, 3
),
confirmed_bookings AS (
  SELECT
    b.booking_id,
    b.user_id,
    b.booked_at
  FROM analytics.booking_events b
  WHERE b.status = 'confirmed'
),
user_level_conversion AS (
  -- Reduce to user-level to avoid counting multiple bookings per user unless explicitly desired
  SELECT
    fe.experiment_id,
    fe.variant,
    fe.user_id,
    fe.first_exposed_at,
    MIN(cb.booked_at) AS first_booking_after_exposure
  FROM first_exposure fe
  LEFT JOIN confirmed_bookings cb
    ON cb.user_id = fe.user_id
   AND cb.booked_at >= fe.first_exposed_at
   AND cb.booked_at < fe.first_exposed_at + INTERVAL '14 days'
  GROUP BY 1, 2, 3, 4
)
SELECT
  experiment_id,
  variant,
  COUNT(*) AS exposed_users,
  COUNT(*) FILTER (WHERE first_booking_after_exposure IS NOT NULL) AS converted_users,
  CASE
    WHEN COUNT(*) = 0 THEN 0
    ELSE COUNT(*) FILTER (WHERE first_booking_after_exposure IS NOT NULL)::DECIMAL / COUNT(*)
  END AS booking_cvr_14d
FROM user_level_conversion
GROUP BY 1, 2
ORDER BY 1, 2;

from __future__ import annotations

from collections import defaultdict
from typing import Iterable, List, Tuple, Dict


def top_k_listings_by_ctr(
    events: Iterable[Tuple[int, int, str, bool]],
    k: int,
    m: int,
) -> List[Tuple[int, float, int]]:
    """Compute top-k listings by CTR.

    Args:
        events: Iterable of (listing_id, ts, session_id, is_click).
                Each event is an impression; is_click indicates whether it was clicked.
        k: number of listings to return.
        m: minimum number of impressions required to be eligible.

    Returns:
        List of tuples (listing_id, ctr, impressions) sorted by:
          1) ctr descending
          2) impressions descending
          3) listing_id ascending
    """
    if k <= 0:
        return []

    impressions: Dict[int, int] = defaultdict(int)
    clicks: Dict[int, int] = defaultdict(int)

    for listing_id, _ts, _session_id, is_click in events:
        impressions[listing_id] += 1
        if is_click:
            clicks[listing_id] += 1

    eligible: List[Tuple[int, float, int]] = []
    for listing_id, imp in impressions.items():
        if imp >= m:
            clk = clicks.get(listing_id, 0)
            ctr = clk / imp
            eligible.append((listing_id, ctr, imp))

    eligible.sort(key=lambda x: (-x[1], -x[2], x[0]))
    return eligible[:k]


if __name__ == "__main__":
    sample_events = [
        (101, 1, "s1", False),
        (101, 2, "s1", True),
        (102, 3, "s2", True),
        (102, 4, "s2", False),
        (102, 5, "s3", False),
        (103, 6, "s4", True),
    ]
    # m=2 removes listing 103 (only 1 impression)
    print(top_k_listings_by_ctr(sample_events, k=2, m=2))

from __future__ import annotations

from collections import defaultdict
from typing import Iterable, Tuple, Dict, List


SECONDS_PER_DAY = 24 * 60 * 60


def count_repeat_bookers_same_host(
    events: Iterable[Tuple[int, int, int, bool]],
    d: int,
) -> int:
    """Count guests who are repeat bookers for the same host.

    A guest counts if there exists at least one host such that the guest has
    at least two non-cancelled bookings with that host separated by >= d days.

    Args:
        events: Iterable of (host_id, guest_id, ts, is_cancelled).
               ts is a Unix timestamp in seconds.
        d: minimum separation in days.

    Returns:
        Number of distinct (host_id, guest_id) pairs that satisfy the condition.
    """
    if d <= 0:
        # Any two non-cancelled bookings qualify when d <= 0.
        d_seconds = 0
    else:
        d_seconds = d * SECONDS_PER_DAY

    # Collect timestamps for each (host, guest) pair.
    pair_to_ts: Dict[Tuple[int, int], List[int]] = defaultdict(list)
    for host_id, guest_id, ts, is_cancelled in events:
        if not is_cancelled:
            pair_to_ts[(host_id, guest_id)].append(ts)

    repeat_pairs = 0
    for _pair, tss in pair_to_ts.items():
        if len(tss) < 2:
            continue
        tss.sort()

        # Existence check for any separation >= d_seconds.
        # Since sorted, the widest gap is between earliest and latest.
        if tss[-1] - tss[0] >= d_seconds:
            repeat_pairs += 1

    return repeat_pairs


if __name__ == "__main__":
    sample = [
        (1, 10, 1_700_000_000, False),
        (1, 10, 1_700_000_100, False),
        (1, 10, 1_700_200_000, False),
        (1, 11, 1_700_000_000, False),
        (1, 11, 1_700_000_050, True),
        (2, 10, 1_700_000_000, False),
        (2, 10, 1_700_000_100, False),
    ]
    print(count_repeat_bookers_same_host(sample, d=1))

The distribution above tells a clear story, but what it doesn't show is how the categories bleed into each other during actual interviews. A question that starts as "define a success metric for Instant Book" can pivot mid-conversation into designing an experiment with marketplace interference, then into "randomization isn't possible because the policy only launched in EU markets, so how do you estimate the causal effect?" That chain (product sense into experimentation into causal inference) is where Airbnb's loop gets uniquely punishing, because you can't compartmentalize your prep into neat buckets.

The most common misallocation of prep time, from what candidates report, is drilling Python algorithms and ML model tuning while treating experimentation and causal inference as "stats I already know." Airbnb's questions in those areas aren't textbook. They're grounded in specific marketplace headaches: interference between hosts and guests in the same experiment, risk-score thresholds that create selection bias in Trust & Safety rollouts, cancellation policy changes that vary by country and listing type.

Practice questions grounded in Airbnb's guest/host dynamics and marketplace experimentation challenges at datainterview.com/questions.

How to Prepare for Airbnb Data Scientist Interviews

Airbnb has publicly committed to reaching more than a billion annual guests by 2028, a goal the company describes as bringing "magical travel to everyone." That ambition, sitting on top of $12.2B in revenue (12% YoY growth), means DS teams are deeply embedded in the mechanics of scaling a two-sided marketplace. The engineering blog's "From Data to Action" series on Airbnb Plus gives you a window into how DSs here move from quality scoring to product decisions, and it's worth reading before your loop.

Don't answer "why Airbnb" with a story about loving travel. Instead, pick a specific DS challenge visible in Airbnb's own public materials. The company is hiring staff-level experimentation roles and forecasting roles embedded in finance, which tells you where the org is stretching. If your background involves causal inference for marketplace dynamics, or building forecasting systems where supply and demand pull in opposite directions, say that. Anchor your answer to a real team you'd want to join, not a vibe.

Try a Real Interview Question

| hosts | | | |
|------| | | |
| host_id | signup_date | country | acquisition_channel |
|---------|-------------|---------|---------------------|
| 101     | 2024-01-02  | US      | seo                 |
| 102     | 2024-01-05  | US      | paid_search         |
| 103     | 2024-01-08  | FR      | referral            |
| 104     | 2024-01-10  | US      | seo                 |

| listings | | |
|----------| | |
| listing_id | host_id | created_date |
|------------|---------|--------------|
| 201        | 101     | 2024-01-03   |
| 202        | 102     | 2024-01-06   |
| 203        | 103     | 2024-01-09   |
| 204        | 104     | 2024-01-20   |

| bookings | | | |
|----------| | | |
| booking_id | listing_id | start_date  | status     |
|------------|------------|-------------|------------|
| 301        | 201        | 2024-01-12  | confirmed  |
| 302        | 202201     | 2024-01-13  | confirmed  |
| 303        | 202        | 2024-01-25  | cancelled  |
| 304        | 203        | 2024-01-18  | confirmed  |

WITH host_first_confirmed_start AS (
  SELECT
    l.host_id,
    MIN(b.start_date) AS first_confirmed_start_date
  FROM listings l
  JOIN bookings b
    ON b.listing_id = l.listing_id
  WHERE b.status = 'confirmed'
  GROUP BY 1
), host_conversion AS (
  SELECT
    h.host_id,
    DATE_TRUNC('week', h.signup_date) AS signup_week,
    CASE
      WHEN f.first_confirmed_start_date IS NOT NULL
       AND f.first_confirmed_start_date >= h.signup_date
       AND f.first_confirmed_start_date <= h.signup_date + INTERVAL '14 day'
      THEN 1 ELSE 0
    END AS converted_14d
  FROM hosts h
  LEFT JOIN host_first_confirmed_start f
    ON f.host_id = h.host_id
)
SELECT
  signup_week,
  COUNT(*) AS hosts_signed_up,
  SUM(converted_14d) AS hosts_converted,
  1.0 * SUM(converted_14d) / NULLIF(COUNT(*), 0) AS conversion_rate
FROM host_conversion
GROUP BY 1
ORDER BY 1;

Airbnb's take-home and coding rounds reward candidates who combine clean, readable code with a clear narrative about what the numbers mean. Practicing with product-flavored data problems (not abstract algorithm puzzles) is the highest-ROI use of your prep time. Build that muscle at datainterview.com/coding.

Test Your Readiness

Ground every practice answer in Airbnb-specific context (guest vs. host incentives, seasonality, the Reserve Now Pay Later feature) rather than giving a generic textbook response. Drill more questions at datainterview.com/questions.