Interview experience
Airbnb Interview Questions and Answers (2026)
Overview
Section titled “Overview”Airbnb’s engineering loop runs a recruiter screen, a technical screen, and a 4-5 round virtual onsite - coding, system design, code review, and one or two Core Values interviews - filled mostly through a narrow US new-grad program, not a campus drive.
Airbnb interview process at a glance
Section titled “Airbnb interview process at a glance”| Round | Duration | What it tests |
|---|---|---|
| Recruiter screen | ~30 min | Background, motivation, logistics, comp expectations |
| Technical screen | 45-60 min | Live coding (CoderPad) or online assessment (HackerRank/CodeSignal) |
| Onsite - Coding (1-2 rounds) | 45-60 min each | DSA (medium-hard), dynamic programming, product-flavoured problems |
| Onsite - System design | 45-60 min | Scalable, consumer-product system design |
| Onsite - Code review | 45-60 min | Triaging real/pseudo-code for correctness, security, readability |
| Core Values interview (1-2) | 45 min each | Belonging, ownership, ambiguity - via Airbnb’s stated values |
Recruiter screen
Section titled “Recruiter screen”A roughly 30-minute call to confirm background, work authorisation, logistics, and why Airbnb. Recruiters report listening for genuine interest in the mission even at this early stage, not just a rehearsed answer.
Common questions
- Walk me through your resume/current role
- Why Airbnb, specifically, right now?
- What are your compensation expectations?
- Location, notice period, work authorisation
Full behavioural frameworks are on the Airbnb HR interview questions page.
Technical screen
Section titled “Technical screen”Either a 45-60 minute live coding session on CoderPad with an engineer, or a timed online assessment on HackerRank/CodeSignal. Some assessments use a multi-part, progressive format where an efficient early solution is required to build on for later parts.
Common questions
- Longest substring without repeating characters (sliding window + hashmap)
- Detect a cycle in a directed graph (DFS colouring / topological sort)
- A progressive, multi-level coding assessment building on your own earlier solution
- Explain the time/space trade-offs of your approach
See how real candidates handled this stage on the Airbnb interview experience page.
Onsite: coding rounds
Section titled “Onsite: coding rounds”One or two 45-60 minute rounds. Airbnb’s problem bank skews toward dynamic programming and “product feature” style problems - a pricing/filtering pipeline, a text formatter, a booking-flow simulation - more than pure textbook DSA, and community-tracked banks show a noticeably higher share of hard-rated problems than typical big-tech loops.
Common questions
- Cheapest flights within K stops (and variants asking you to reconstruct the path)
- Design/implement a filtering or ranking pipeline for search results
- Dynamic-programming problems framed as a product feature rather than a textbook prompt
- Top-K frequent elements (heap-based)
Round-by-round breakdowns are on the Airbnb interview experience page.
Onsite: system design
Section titled “Onsite: system design”A 45-60 minute round on designing a scalable, consumer-facing system - not necessarily “Airbnb clone” trivia, but the kind of latency, data-modelling, and compliance trade-offs a booking/search product actually faces.
Common questions
- Design a search/ranking service for listings
- Design an availability calendar / booking system that avoids double-booking
- Design a user-activity or events platform, with attention to PII and compliance
- How would you handle a sudden spike in read traffic during a peak booking window?
Onsite: code review round
Section titled “Onsite: code review round”A distinctive Airbnb round: instead of writing new code, you’re handed real or simplified production-style code (or pseudo-code) and asked to review it as if it were a teammate’s pull request. Interviewers weigh whether you catch correctness and security issues first, and whether you calibrate severity instead of drowning the review in style nitpicks.
Common questions
- Review a snippet and flag correctness bugs before anything else
- Identify a security or data-handling issue in the given code
- Explain how you’d phrase a piece of critical feedback to a teammate
- Decide which issues are blocking vs. a “nit” comment
Core Values interview
Section titled “Core Values interview”Airbnb’s most distinctive round. It’s a dedicated behavioural interview - often conducted by someone outside engineering entirely - built around Airbnb’s stated values (Be a Host, Champion the Mission, Embrace the Adventure, Be a Cereal Entrepreneur). Multiple candidate reports describe it carrying equal weight to the technical rounds, capable of sinking an otherwise strong loop. Expect at least one question specifically about belonging.
Common questions
- Tell me about a time you made someone feel like they belonged, or hosted someone (literally or figuratively) really well
- Describe a time you had to navigate real ambiguity without a clear playbook
- Tell me about a decision that reflected champion-the-mission thinking over a shorter-term win
- How would you balance a host’s and a guest’s conflicting interests in a trust-and-safety situation?
Sample answer frameworks for each of these are on the Airbnb HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How do you solve Cheapest Flights Within K Stops?
This is a shortest-path problem with an extra constraint on edge count, so plain Dijkstra is wrong because the cheapest path to a node may use too many hops while a pricier one stays within budget. The clean solution is a Bellman-Ford relaxation run exactly K+1 times: keep a cost array initialised to infinity except the source at 0, and on each of the K+1 rounds compute a fresh copy from the previous round’s costs, relaxing every edge as newCost[v] = min(newCost[v], prev[u] + weight). Copying the previous round is essential, since relaxing in place would let a single round use more than one new edge. That gives O(K times E) time and O(V) space. The alternative is a BFS or Dijkstra variant where the state is the pair of node and stops used, and you prune a state only when you have already reached that node with both fewer stops and lower cost. Airbnb follow-ups usually ask you to reconstruct the actual itinerary, which needs a parent pointer stored per round.
Q: How do you find the longest substring without repeating characters?
Use a sliding window with a hash map from character to its most recent index. Move the right pointer across the string one character at a time; if the character is already in the map at an index at or after the current left pointer, jump left to that index plus one, which discards the duplicate in a single step rather than shrinking one character at a time. Update the map with the current index and track the maximum of right - left + 1. Each character is visited once, so it is O(n) time, and space is O(min(n, alphabet size)). The common bug is failing to guard the left jump with the check that the stored index is still inside the current window, which lets left move backwards on inputs like abba and gives a wrong answer. Airbnb interviewers frequently extend this to at most K distinct characters, which swaps the map for a count map and shrinks the window while the distinct count exceeds K.
Q: How do you detect a cycle in a directed graph?
Use DFS with three colours. White means unvisited, grey means on the current recursion stack, and black means fully explored. Run DFS from every white vertex; when you reach a neighbour that is grey, you have found a back edge, which is exactly a cycle. A black neighbour is not a cycle, only a previously finished subtree, which is why a simple visited boolean is wrong for directed graphs even though it works for undirected ones. Complexity is O(V + E) time and O(V) space for colours plus recursion depth. The iterative alternative is Kahn’s algorithm: repeatedly remove zero in-degree vertices, and if fewer than V vertices come out, the remainder forms a cycle. For very deep graphs prefer the iterative version, since recursive DFS can overflow the stack.
Q: What is the most efficient way to find the top K frequent elements?
First count occurrences in a hash map, which is O(n). Then, for the general case, push counts into a min-heap of size K, popping whenever the heap exceeds K, so the heap always holds the K largest counts; that is O(n log K) time and O(n + K) space, and it is the right answer when K is much smaller than n. If you want strictly linear time, use bucket sort: create an array of n+1 buckets indexed by frequency, place each key in the bucket matching its count, and walk the buckets from the highest index downwards collecting keys until you have K. That is O(n) time and O(n) space, since no frequency can exceed n. A third option is Quickselect on the count array for O(n) average time but O(n squared) worst case. In a real ranking service you would instead approximate with Count-Min Sketch or Space-Saving when the key space will not fit in memory.
Q: How do you approach a dynamic-programming problem framed as a product feature?
Work in a fixed order rather than pattern-matching. First name the state precisely, in the vocabulary of the product: for a pricing or booking DP that is usually something like the best value achievable considering the first i nights with j promotions used. Second write the recurrence as a decision at the current index, typically take versus skip, and confirm the problem has optimal substructure and overlapping subproblems, or DP is the wrong tool. Third state the base cases and the answer cell explicitly. Fourth compute time and space from the state space times the transition cost, then look for a rolling-array reduction when each row depends only on the previous one, which turns O(n times W) space into O(W). Finally, if asked which specific items or nights were chosen, keep a parent or choice table and backtrack, because the value table alone does not reconstruct the decision. Saying this sequence out loud is what Airbnb interviewers are scoring, since their DP problems are usually a familiar recurrence wearing an unfamiliar story.
Q: How would you design an availability and booking system that never double-books?
Model availability as date ranges per listing and treat the booking write as the single point where correctness matters. The most robust approach is to let the database enforce it: store bookings with a range type and an exclusion constraint, or in a simpler schema hold a unique constraint on the pair of listing ID and date so overlapping nights physically cannot both be inserted. Wrap the write in a transaction at Serializable or Repeatable Read with a SELECT ... FOR UPDATE on the listing row, so two concurrent requests serialise rather than both reading available and both writing. To avoid holding a lock through a slow payment call, split the flow: create a short-lived hold row with a TTL of a few minutes, take payment, then convert the hold into a confirmed booking, and let a sweeper expire abandoned holds. Reads scale separately, since search and calendar views can be served from a cache or read replica with seconds of staleness, and only the final write path needs strong consistency. The trade-off to state explicitly is that optimistic concurrency with a version column gives better throughput but forces the client to handle a retry, while pessimistic locking is simpler but limits write parallelism per listing.
Q: How would you handle a sudden spike in read traffic during a peak booking window?
Layer defences from the edge inwards. Put a CDN in front of anything cacheable, so listing photos and largely static listing pages never reach your origin. Behind it, cache hot search results and listing detail responses in a distributed cache such as Redis with short TTLs, and guard against a stampede where thousands of requests all miss the same expired key at once by using request coalescing or randomised TTL jitter. Add read replicas for the database and route all search and browse queries there, keeping the primary for writes; accept the resulting replication lag for browse but read the primary after a user’s own booking so they see their action. Protect the origin with per-user and per-IP rate limits and a circuit breaker that sheds non-essential calls, and degrade gracefully by serving slightly stale results rather than errors. Autoscaling helps but is too slow for a sharp spike on its own, so pre-warm capacity ahead of a known event and keep enough headroom that scaling has time to catch up.
Q: What do you look for first when reviewing someone else’s pull request?
Correctness and security before anything else, then design, then readability, and style last. On correctness, check the boundary conditions the tests do not cover: empty and single-element inputs, off-by-one loop bounds, null or undefined handling, integer overflow, and concurrency, especially a read-then-write sequence that is not atomic. On security, look for user input reaching a query without parameterisation, missing authorisation checks where the code verifies the user is logged in but never that they own the object, secrets or tokens in logs, and PII written somewhere it should not be. On design, ask whether the change fits the existing abstractions or bolts a special case onto a shared path. Then calibrate severity out loud, marking blocking issues distinctly from suggestions and prefixing genuine style preferences as nits, because an Airbnb code review round scores your judgment about what matters as much as the defects you spot. Phrase feedback as a question about intent rather than an accusation, and say what is good in the change too.
Frequently asked questions about Airbnb interviews
Section titled “Frequently asked questions about Airbnb interviews”What is the Airbnb interview process for software engineers?
Airbnb’s loop usually runs: 1. Recruiter screen (~30 min) - background, motivation, logistics. 2. Technical screen (45-60 min) - live coding on CoderPad, or a timed online assessment via HackerRank/CodeSignal. 3. Virtual onsite (4-5 rounds, often one day or split across two) - one or two coding rounds, a system design round, a code review round, and one or two Core Values interviews. End-to-end timeline is roughly 3-5 weeks.
What questions are asked in Airbnb interviews?
Coding rounds lean medium-to-hard and skew toward dynamic programming and product-flavoured problems - simulate a booking/pricing flow, build a filtering pipeline, or a modified graph problem like cheapest flights within K stops. System design covers scalable, consumer-product systems (search, booking, availability). The code review round hands you real or pseudo-code and asks you to triage correctness, security, and readability. Core Values interviews ask about belonging, hosting, and navigating ambiguity.
How many rounds are there in the Airbnb interview?
Typically 5-6 touchpoints: recruiter screen, technical screen, and a 4-5 round virtual onsite (1-2 coding rounds, 1 system design round, 1 code review round, and 1-2 Core Values interviews). Exact composition varies by team and level, so treat this as a template, not a fixed script.
What is Airbnb’s Core Values interview?
A dedicated behavioural round, often run by a cross-functional or non-engineering interviewer, that carries equal weight to the technical rounds - candidates report it can override an otherwise strong technical performance. It centers on Airbnb’s stated values (Be a Host, Champion the Mission, Embrace the Adventure, Be a Cereal Entrepreneur), with heavy emphasis on “belonging” - expect at least one question about making someone feel included or supported.
How should I prepare for Airbnb interviews?
Drill medium-to-hard DSA with real dynamic-programming reps (Airbnb’s hard problems skew toward involved implementation, not just clever tricks), practise reviewing someone else’s code out loud for correctness/security/readability, be ready to design a consumer-scale system in plain language, and prepare 2-3 STAR stories per Core Value - especially one about helping someone feel like they belonged.
Does Airbnb ask hard dynamic-programming questions?
Community-tracked problem banks show Airbnb sitting above the typical big-tech split, with a noticeably higher share of hard-rated problems and a heavier DP presence than most peers. Problems are also often framed as product features (a text formatter, a pricing/filtering pipeline) rather than pure textbook DP, so practising the pattern isn’t enough - you also need to map it onto a realistic scenario.
How selective is Airbnb hiring?
Very. Airbnb’s US university/new-grad program is reported to accept roughly 1-3% of applicants, and campus recruiting is limited to a short list of schools rather than a broad drive. Community-reported final-onsite offer rates vary widely by team and level, so treat any single number as a rough signal, not a guarantee - the harder filter is getting to the onsite at all.
Is Airbnb’s process different for freshers vs experienced hires?
Yes. Airbnb’s real entry point is a narrow, US-centric new-grad program (applications open roughly September-November) plus referrals, not a college placement drive. Its India offices (Bangalore, Gurgaon) hire actively, but openings there skew toward experienced platform, backend, and compliance-tech roles rather than fresh graduates - verify any India campus-drive claim directly with Airbnb before repeating it.