Airbnb Software Engineer Full Loop Interview Experience (2025) - Listings Search Design, Offer

Round 1: Coding, Listings Capacity Selection

Problem: Given a list of Airbnb listings in a neighborhood, each with an id and a capacity, select the minimum number of listings whose total capacity meets or exceeds a requested group size. If multiple subsets tie on count, prefer the one that minimizes total capacity. Return the list of ids, or empty if impossible.

This one looked like a knapsack but the tie-breaking rule is what makes it sharp. I sorted listings by capacity descending and tried a greedy first, which the interviewer let me pitch before pointing out a counterexample where greedy overshoots. I moved to a DP where the state was (index, capacity so far) and the value was the smallest count to reach that capacity, with a tiebreaker on total capacity. I reconstructed the path by walking the DP table backward. The interviewer then asked what happens when the capacities are real numbers or when N grows past a few thousand, and I talked through discretization and branch-and-bound as fallbacks. This is the kind of problem where talking about why greedy fails is worth more than the final code.

[[problem/394?company=9|Terrain Water Simulation]] has a similar feel of "looks simple, the constraints make it hard" and is a solid warmup for this round's tempo.

Round 2: Coding, Retryer with Backoff

Problem: Design a retry utility that takes a callable, a max attempt count, a backoff policy, and a set of retryable exception types. Return the result, or raise after the final attempt.

I treated this as equal parts coding and OOD. I wrote a Retryer class with a call method, a BackoffPolicy interface with a next delay(attempt) method, and two concrete policies for exponential and jittered exponential backoff. The interviewer pushed on what happens when the underlying callable is idempotent versus non-idempotent, and whether the retry should share state across calls (it should not, by default). We also discussed sleep injection so the class is testable without wall-clock waits. I ended with a short test suite in prose, describing how I would verify each path.

[[problem/395?company=9|Retryer Implementation]] is the exact problem and Airbnb reuses it enough that it is worth writing from memory once.

Round 3: System Design, Airbnb Listings Search

Problem: Design Airbnb's listing search. Millions of listings, filters on price, location, dates, capacity, amenities. Support low latency, high relevance, and ranking.

I started with the query shape and worked outward. Inputs were a bounding box or city, a date range, a price range, a guest count, and a bag of amenity flags. I sketched an ingestion pipeline that normalized listings into a flat document and pushed them into Elasticsearch with geo-shape and range fields. Availability was the tricky part because date-range filters do not compress well into inverted indexes at listing granularity. I argued for a separate availability service keyed on listing id that the search layer calls after the initial Elasticsearch candidate cut, rather than trying to bake availability into the search index itself. Ranking was a two-stage process: a cheap relevance score inside Elasticsearch for the top few thousand candidates, then a heavier ML reranker that pulled guest preference features and historical booking rates. The interviewer pushed on cache invalidation when a host updates pricing or blocks dates, and I talked through per-listing version stamps with a pub-sub bus that invalidates the relevant cache entries.

The follow-up I did not see coming was about localized ranking. How would you handle the case where a Paris guest searches Tokyo and a Tokyo guest searches Tokyo, and both should see reasonable but different results. I went with per-market popularity priors layered into the ranker as features, with the guest's home market as an input. The interviewer seemed happy. This was the round I had practiced most and it showed.

Round 4: Cross-Functional and Cultural Fit

This was the round that sets Airbnb apart. It was framed as "imagine you are working with a PM, a designer, and a host success manager on a feature that lets hosts offer last-minute discounts." The interviewer role-played the host success partner and wanted me to walk through how I would run the feature, what tradeoffs I would surface, and how I would think about the host perspective when engineering decisions pushed back on product intent.

I talked about a specific instance at my current job where a dashboard we shipped burned trust with a power user segment because we optimized for aggregate metrics and missed a power-user workflow. The interviewer wanted me to name what I would do differently. I said I would have insisted on shadowing three hosts for an afternoon before finalizing the spec, and would have pushed for a soft rollout that gave host success a veto on the general availability date. There was also a pointed question about what I would do if I disagreed with a PM's priority call and engineering leadership sided with the PM. I answered honestly, which is that I would disagree and commit, document the tradeoff, and ask for a revisit date.

The cultural fit portion blended in at the end with "tell me about a time you were the host" and "how do you think about belonging on a distributed team." Airbnb really does ask these and they are not throwaways. I had prepared three stories ahead of time and I used all three.

Result

Offer came eight days after the onsite. The comp was in line with expectations, slightly below Meta but with better equity terms than I thought Airbnb offered. I negotiated a modest sign-on bump on the basis of a competing offer and accepted.

Tips

1. Airbnb's behavioral bar is the real gate. More than half of my loop was either explicitly or implicitly about collaboration, empathy, and host-first thinking. Treat the behavioral rounds as equally load-bearing as the coding ones and prepare specific stories with numbers attached.
2. The listings search design problem is almost mandatory for SWE loops. Practice it until you can draw the ingestion, query, and ranking pipelines without thinking. Bonus points for having an opinion on how to handle date-range availability, which is where most candidates stumble.
3. Coding problems are marketplace-flavored. Tasks with deadlines, listing selection under constraints, retry and rate-limit utilities. Drill the Airbnb-specific problem set rather than a generic LeetCode grind.
4. Your code must compile and run. Airbnb expects candidates to actually execute the code against examples during the round. Practice typing fast enough that you have time to run tests and handle a follow-up.
5. Know the product. The cross-functional round assumes you have used Airbnb as a guest and thought about it as a host. Book a stay or at least read the host onboarding flow before the loop if you are rusty.
6. Have a distributed-team story ready. Airbnb's workforce is spread across time zones and the interviewers will ask how you work when your counterpart is asleep. A concrete example lands much better than a philosophy.