Distilled Prep

Airbnb

Airbnb's marketplace has properties the ride/delivery platforms don't: inventory is unique (no two listings are interchangeable), transactions are high-stakes and infrequent, and trust between strangers is the product. That combination shapes everything they publish — search ranking where hosts can decline, experimentation with delayed outcomes, and fraud/trust systems.

For data scientists, their interviews draw on search and booking funnel diagnosis, two-sided experimentation with long feedback delays, and policy evaluation (their golden-age posts on experimentation and metrics remain canonical). For software engineers and MLEs, expect search/ranking system design and reservation-consistency problems (double-booking is their canonical correctness case).

Names worth recognizing: Airflow (born at Airbnb, now the industry's default workflow orchestrator), Chronon (their feature platform, successor to Zipline), and Bighead (their earlier ML platform).

Their vocabulary

Airflow

The workflow orchestrator born at Airbnb and now the industry default for data pipelines. Its DAG-of-tasks model is assumed vocabulary in their data engineering discussions.

Chronon

Airbnb's open-source feature platform (successor to Zipline): declares features once, computes them consistently for both training and online serving — their answer to train/serve skew in ML systems.

The canon

Curated questions on this company's enduring themes.

difficulty 4/5 Product caseData sciencecausal-inferenceexperimentationmarketplace-dynamicsJul 2026

Design a policy and measurement plan for encouraging hosts to adopt Instant Book (guests book without host approval) without harming trust or marketplace quality.

Practice against the follow-up probes
  • Adoption is voluntary. Why does that break the obvious adopters-vs-non-adopters comparison, and what do you do instead?
  • What could go wrong for trust and quality, and which metrics catch it early?
  • Would you treat new hosts, professional hosts, and occasional hosts the same way?
  • What encouragement levers exist, and how do they differ analytically?
  • What would make you roll the program back?
Show answer guide

What the interviewer is probing

Selection-bias instincts: hosts who opt into Instant Book differ systematically from those who don't (professionalism, availability discipline), so naive comparisons flatter the feature. Strong candidates reach for encouragement designs — randomize the nudge, not the adoption — and instrument the trust side (cancellations, incidents, reviews) as first-class outcomes, with policies differentiated by host segment.

Strong answer outline

  • Name the selection problem: adoption correlates with host quality; outcome gaps between adopters and non-adopters are not causal effects of the feature.
  • Encouragement design: randomize incentives/nudges (search boost, fee discount, education) at the host level; measure intent-to-treat effects, and use the randomized encouragement as an instrument for adoption if effect-on-adopters is needed. Cluster by market if ranking-boost nudges create within-market interference.
  • Outcome set: guest conversion and booking latency (the upside); host-cancellation rate, guest-reported incidents, review scores, support contacts, host churn (the trust guardrails). A host who accepts Instant Book but cancels often is worse than one who declines upfront.
  • Segment policies: professional hosts likely adopt with light nudges; occasional hosts may need protections (trip-type controls, guest-requirement filters) before adoption is healthy; brand-new hosts are the riskiest to auto-enroll — stage them.
  • Long-horizon monitoring: adoption changes the composition of bookings; track quality metrics per cohort over quarters, not weeks.
  • Rollback rule: pre-register thresholds on host-cancellation and incident rates by segment; the program pauses per-segment, not globally.

The underlying concept

When treatment is chosen rather than assigned, comparing the treated to the untreated measures who chooses, not what the treatment does. Encouragement designs recover causality by randomizing an upstream influence and analyzing intent-to-treat; instrumental-variable logic then scales that to the compliers. The marketplace twist is that adoption changes system composition — evaluation must include the counterparty's outcomes (guests, here) and run long enough for composition effects to surface.

Source

Distilled Prep canon — curated from Airbnb's public work on experimentation and policy evaluation.

Source: Distilled Prep canon (curated)

difficulty 4/5 Systems designSoftware engdistributed-systemsdatabasesreliabilityJul 2026

Design a globally consistent availability and reservation system that makes double-booking a listing for overlapping dates impossible, while keeping search fast.

Practice against the follow-up probes
  • Two guests hit "book" for overlapping dates within 50 ms of each other. Walk me through exactly what happens.
  • How do you model availability for date ranges rather than single slots?
  • Payment authorization takes seconds and can fail. How does that interact with holding the dates?
  • Search reads availability millions of times per booking write. Do reads see the same truth as writes?
  • A region goes down mid-booking. What is the failure behavior?
Show answer guide

What the interviewer is probing

Whether the candidate separates the one operation that needs strict serialization (committing a reservation) from the vast read traffic that doesn't, and can implement range-overlap exclusion correctly — naive check-then-insert is the classic race. Also probing the booking-payment interaction (holds with TTL, sagas) and honest consistency reasoning across regions.

Strong answer outline

  • Correctness core: per-listing serialization of reservation commits. Implementations: transactional insert with an exclusion constraint on (listing, date-range overlap) — e.g., per-day rows with unique (listing, date) keys inserted atomically, or a range-exclusion constraint; alternatively optimistic concurrency on a per-listing calendar version. The invariant lives in the database, not application logic.
  • The 50 ms race: both requests attempt the atomic commit; exactly one succeeds, the other receives a clean conflict and re-searches. Correctness does not depend on timing.
  • Payment interaction: two-phase flow — place a short-TTL hold on the dates (same exclusion mechanics), authorize payment, then confirm; expiry or payment failure releases the hold automatically. Idempotency keys on the whole flow make client retries safe.
  • Read path: search reads eventually consistent replicas/caches of availability (staleness measured in seconds is acceptable — the commit step re-verifies), so search scale never touches the serialized path. Final availability check happens inside the booking transaction.
  • Multi-region: home each listing's calendar to one region (ownership by geography) so commits are single-region strongly consistent; replicate asynchronously for reads. Cross-region failover promotes ownership with fencing to prevent split-brain double-commits.
  • Degraded modes: if the owning region is down, fail bookings for its listings (correctness over availability for money+inventory) while search continues on stale reads.

The underlying concept

Inventory systems are exclusion problems: the invariant "no two confirmed reservations overlap" must be enforced where atomicity actually exists — a transactional store with constraints — because any check-then-act sequence outside it races. The scalable pattern is asymmetric consistency: strong consistency on the narrow write path, eventual consistency on the wide read path, with the write path re-validating what stale reads promised. Holds-with-TTL are the standard bridge between instantaneous inventory locks and slow external side effects like payment.

Source

Distilled Prep canon — curated from Airbnb's public work on reservation and payments infrastructure.

Source: Distilled Prep canon (curated)

difficulty 3/5 Product caseData sciencesearch-rankingmarketplace-dynamicsdata-qualityJul 2026

Search-to-book conversion fell 15% in one destination market, but traffic and listing supply are stable. Lead the diagnosis.

Practice against the follow-up probes
  • Walk me through the funnel you'd construct before touching any data.
  • Which segment cuts do you make first, and what would each reveal?
  • How do you distinguish a demand mix-shift from a product or supply problem?
  • What supply-side changes could cause this with listing count unchanged?
  • When do you stop diagnosing and escalate or act?
Show answer guide

What the interviewer is probing

Structured funnel decomposition under a one-market anomaly: does the candidate localize the drop to a funnel stage before hypothesizing, do they generate supply-side explanations that hide behind stable listing counts (availability, minimum stays, pricing, host responsiveness), and do they check for measurement artifacts before believing the behavior change? Airbnb's version of this question rewards knowing that "supply is stable" by count can conceal massive effective-supply changes.

Strong answer outline

  • First: verify the metric — instrumentation changes, bot traffic, definition changes, and comparison-window artifacts (holiday shift, event last year) explain a large share of single-market anomalies.
  • Localize in the funnel: query → results viewed → listing detail → booking request/instant book → acceptance → payment. A drop at detail-view→request implicates pricing/content; at request→acceptance implicates hosts; at results→detail implicates ranking or inventory match.
  • Demand mix: lead time, trip length, party size, domestic vs. international, device — a shift toward lower-converting segments (e.g., longer lead times after an event announcement) can move the aggregate with no product problem.
  • Effective supply despite stable counts: calendar availability for searched dates, minimum-stay rules, price increases, cleaning fees, host response time — all shrink bookable supply invisibly.
  • Cross-checks: did competitors or events change locally (regulation, festivals moving)? Compare similar markets as a synthetic control to see if the drop is market-specific.
  • Prioritize by expected information gain; timebox the diagnosis, and present findings as: funnel stage, segment, magnitude, candidate cause, recommended action or experiment.

The underlying concept

Funnel decomposition is diagnosis by conditional probabilities: overall conversion is a product of stage-wise rates, so a drop must live in identifiable factors — and localizing it first prevents hypothesis-shopping. The Airbnb-specific lesson is effective supply: in calendar-based marketplaces, supply is inventory × availability × constraints × price acceptability, and only the first term shows up in a listing count. Measurement artifacts outrank behavioral explanations in prior probability; check them first.

Source

Distilled Prep canon — curated from Airbnb's public work on search and booking funnel analytics.

Source: Distilled Prep canon (curated)

difficulty 4/5 ML system designML engData sciencesearch-rankinggeospatialrecommendationJul 2026

Design the retrieval and ranking system for ambiguous location searches like "near the beach in Barcelona."

Practice against the follow-up probes
  • What does the query even resolve to — a point, a polygon, a set of neighborhoods? How is that learned?
  • Where do training labels come from when no one labels "correct areas for this query"?
  • How do retrieval, ranking, and re-ranking split responsibilities, and what are the latency budgets?
  • How do you evaluate offline when relevance is subjective, and online when bookings are sparse and delayed?
  • Multilingual queries and markets with thin data: what changes?
Show answer guide

What the interviewer is probing

Whether the candidate can structure an IR problem where the hard part is query understanding — mapping fuzzy intent to geography — and where labels must be mined from behavior (which areas do bookers of this query actually book?) rather than annotated. Also probing evaluation maturity: offline recall against behavioral labels, online booking-quality metrics, and honest handling of position bias and delayed outcomes.

Strong answer outline

  • Query understanding: parse into (anchor geography, modifier concepts); resolve "beach" to geospatial layers (POI data, distance fields) intersected with "Barcelona"; output a weighted candidate region set, not a single polygon.
  • Weak labels from behavior: for historical queries, the listings users detailed/booked define soft relevance over areas — aggregate to build query→area distributions; handle popularity bias by normalizing for exposure.
  • Stage split: retrieval pulls candidates from the region set with availability/capacity filters (broad, cheap, high recall); ranking scores guest-listing fit (quality, price fit, predicted acceptance); re-ranking applies diversity across neighborhoods and business constraints. Latency budget concentrated in ranking; retrieval must be index-served.
  • Cold start and thin markets: back off from learned query→area maps to generic geospatial heuristics (distance-to-beach); share parameters across languages via multilingual encoders; log exploration traffic to grow labels where data is thin.
  • Evaluation: offline — recall of eventually-booked listings within retrieved sets, area-level agreement with behavioral maps; online — detail-view rate, booking conversion, and completed-stay quality, with interleaving experiments to cut variance given sparse bookings.
  • Failure modes to name: modifier misresolution (beach bars vs. beaches), popularity feedback loops, and seasonality in what "near the beach" means.

The underlying concept

Ambiguous local search is two learned mappings composed: intent → geography, then geography+guest → listings. The label scarcity is solved behaviorally — users' downstream choices are a noisy but abundant supervision signal, the same trick behind most modern search relevance. The architecture lesson is the standard retrieval/ranking split under a latency budget; the evaluation lesson is that when outcomes are sparse and delayed, offline behavioral-label metrics and variance-reduction techniques (interleaving) carry more weight than raw A/B power.

Source

Distilled Prep canon — curated from Airbnb's public work on search relevance and location retrieval.

Source: Distilled Prep canon (curated)

difficulty 4/5 Product caseData sciencesearch-rankingexperimentationmarketplace-dynamicsJul 2026

Search ranking is changed to favor listings with a higher predicted probability of host acceptance. How would you evaluate whether this change should launch?

Practice against the follow-up probes
  • What defines success here — for guests, hosts, and the marketplace — beyond bookings?
  • How do you separate ranking relevance from host availability and acceptance behavior?
  • Position bias, delayed outcomes, cancellations: how does each contaminate your readout?
  • Boosting likely-accepting hosts changes which hosts get demand. What long-term effects does that create, and how would you detect them?
  • Would you randomize by guest, by search, or something else? Why?
Show answer guide

What the interviewer is probing

Whether the candidate sees that this ranking change optimizes a transaction probability, not relevance — and that doing so redistributes demand among hosts, which can reshape the supply side over time. Strong candidates define a guest metric (successful, completed stays — not clicks), a host-side metric (demand concentration, new-host exposure), and a marketplace metric, and they handle the long feedback delays that make booking experiments slow.

Strong answer outline

  • Success definition: guest side — booking conversion and completed, well-reviewed stays (an accepted booking that cancels later is not success); host side — acceptance rate, distribution of bookings across hosts, new-listing exposure; marketplace — total completed nights and rebooking rates.
  • Decompose the mechanism: the change can win by (a) genuinely reducing guest effort wasted on requests that get declined, or (b) merely shifting exposure to instant-book/professional hosts. Same topline, very different long-term marketplace.
  • Experiment design: randomize by guest (searcher), stratify by market; measure through the full funnel — search → request → acceptance → booking → completed stay — with a window long enough for stays to complete; expect weeks, and pre-register leading indicators.
  • Confounds to name: position bias (boosted listings get clicks by position alone — consider counterfactual logging or position-adjusted metrics); seasonality by market; cancellation lag.
  • Long-term supply effects: run a host-side holdout or monitor demand concentration (e.g., share of bookings to top-decile hosts) and new-host cold-start success; a rich-get-richer loop is the main strategic risk.
  • Decision rule: launch if guest success improves without measurable harm to new-host exposure; if concentration worsens, pair the ranking change with an exploration floor for new listings.

The underlying concept

Ranking by predicted transaction success is optimizing a composite outcome: relevance times counterparty behavior. The moment counterparty behavior enters the objective, ranking becomes a market intervention — it allocates demand, and suppliers respond to the allocation. This is the two-sided version of Goodhart's law: boosting what converts today reshapes tomorrow's supply, so evaluations must include distributional metrics and exploration guarantees, not just average conversion.

Source

Distilled Prep canon — curated from Airbnb's public work on search ranking and marketplace experimentation.

Source: Distilled Prep canon (curated)