How Airbnb interviews — Question to Offer

1. The shape of an Airbnb loop

Airbnb runs a system-design loop that looks short on paper and grades harder than it reads. A typical onsite is four to five rounds: one or two coding, one system design (sometimes two at L6+), one cross-functional collaboration round, and a "core values" round that's behavioral in shape but has real weight on the hire decision.

The system-design round is 45 minutes by the clock. Most candidates assume that's a short version of the Google or Meta hour. It isn't. The interviewer expects you to scope tighter and decide faster. If you're still negotiating requirements at minute 12, you've already lost a half a point.

Levels run L4 through L6. L5 is the modal hire. L6 means you're being graded as a staff engineer who can shape a system the company will live with for years.

2. What Airbnb grades you on

Airbnb is a two-sided marketplace. That sentence sounds like marketing until you sit in the room and realize the interviewer is grading whether you remember it.

Every design question has a host side and a guest side. They're both first-class. If you draw the guest path and not the host path, you'll get pushed. If you optimize for the guest and ignore that the host has a calendar, a pricing model, a payout, and a review they care about — you'll get a yellow at best.

The four signals Airbnb publishes:

Technical depth. The usual: distributed systems vocabulary, data model fluency, failure handling. Standard senior bar.
Communication. Airbnb interviewers care about how you talk through tradeoffs. Plain words win. Jargon for its own sake loses.
Cross-functional collaboration. Most design questions touch trust, payments, search, and host tools simultaneously. Naming the seams between teams is part of the grade.
Core values alignment. "Be a host" is a real internal phrase. It shows up as: did you think about the host's experience, not just the guest's?

3. What's different here

Two-sided thinking is the default. Every design has guests and hosts. If you forget one, you'll be reminded — and the reminder costs you.
Design sensibility shows up in the round. Airbnb is famously design-driven. The interviewer notices if you talk about the user experience as part of the system, not as someone else's problem. "The host sees this on their calendar" is a sentence the interviewer is happy to hear.
Trust and safety has real weight. Identity, reviews, fraud, incident response — these aren't extras. A booking system that doesn't address "what if the host or guest is a bad actor" reads as incomplete.
The marketplace shape changes the constraints. Inventory isn't yours; it belongs to hosts. Pricing isn't yours; it's recommended to hosts. The "platform versus participant" line runs through every design.
Hospitality is a real word inside the company. It shows up as the assumption that the system has to handle the messy human edges: a guest arrives late, a host's water heater breaks, a fire alarm goes off. The good designs don't pretend these are edge cases — they're the actual workload.

4. The level bar

L4 (entry senior) — design at the competent IC level. One seam done well. The interviewer will accept "I'd defer that to the trust team" as a scoping move.
L5 (senior) — design at the marketplace-aware level. Both sides of the market named. One deep dive that survives three pushes. Trust and safety mentioned, not necessarily owned.
L6 (staff) — design at the systems-thinker level. The full tradeoff sentence on every major choice. The host tools, the guest tools, and the trust layer all show up in the diagram. Migration story when relevant. "What does the host see when this breaks?" answered without prompt.

In this chapter, units target L5 by default. Where the bar shifts at L6, the units call it out.

5. The Airbnb-flavored mistakes

Watch for these. Each one is a yellow or worse on a real loop.

Designing only the guest path. The host has a calendar, a pricing engine, a payout system, and a review they care about. If your diagram doesn't show host-side reads and writes, you're designing half the product.
Treating trust and safety as a footnote. Reviews, identity checks, fraud signals — these aren't "we'll bolt them on later." On a booking design, you should bring up the review system and the identity check unprompted.
Forgetting geographic constraints. Search at Airbnb is geographic first, text second. Date availability is a hard filter. If you draw a generic inverted index without acknowledging that the location filter is doing most of the work, the interviewer pushes.
Optimistic concurrency on the booking row. Two guests trying to book the same listing for the same dates is the question. If you wave it off with "we'd lock it" and don't talk about hold semantics, TTLs, and idempotency, you fail the deep dive.
Ignoring the marketplace incentives. Pricing recommendations the host can override. Reviews from both sides released simultaneously to prevent retaliation. Cancellation policies the host picked. These aren't UI features — they're system constraints that change the design.
Talking about scale without talking about the city. Most Airbnb workloads are dominated by a few dozen cities. NYC, Paris, Tokyo. The hot keys are geographic. If you draw a globally uniform load, you're wrong.

6. The seven scenarios in this chapter

Each unit dissects one question end to end.

15.1 Airbnb search and ranking — free-text + filter + geo search, ranked listings, date-range availability as a hard filter. Compare to [[product-catalog-search-at-scale]].
15.2 Booking, availability, and the race condition — two guests, one listing, one night. Atomic inventory holds. Compare to [[order-fulfillment-inventory-holds]].
15.3 Pricing recommendations — Smart Pricing for hosts. Per-listing per-date predictions. Compare to [[surge-pricing]] for the dynamic-pricing primitive.
15.4 Host-guest messaging — constrained chat, only between matched pairs, with inline structured content. Compare to [[messenger-1on1-group-read-receipts]].
15.5 Trust and safety — reviews and identity — dual-review system, identity verification, background checks. Compare to [[reviews-and-qa-at-scale]].
15.6 Cancellation policy + refund cascading — the policy menu, days-out math, refund cascades. Compare to [[idempotency-keys]].
15.7 Take-home — calendar cross-channel sync — design doc for the iCal sync subsystem with VRBO and Booking.com.

7. The next page

The first scenario: search and ranking. Geographic dominant, date-availability as a hard filter, personalized ranking on top. Looks like Amazon. It isn't.