HackTheRounds Interview Experiences

Airbnb Software Engineer Interview Experience (2026) - Task Scheduling & Listing Search, Offer

Airbnb SWE full loop: HackerRank OA, CoderPad phone screen, two coding rounds covering zigzag matrix print and greedy task scheduling with deadlines, plus listi

By Anonymous ยท 2026-03-20

Background

Airbnb was my second FAANG-adjacent loop of the cycle and by far the most runnable code heavy. I am a final year MS student with a couple of medium-brand internships. The prep guide that circulates for Airbnb says "the code has to run," and that is not marketing; at Airbnb every coding round ends with you hitting the run button on real input and proving it works. If your approach only exists on the whiteboard in your head, you are going to get caught.

Timeline

OA (HackerRank, 75 min)

Two medium algorithm problems plus a short SQL snippet. A sliding window count, a grid pathing with directional moves, and a retention SQL with one LEFT JOIN and a date bucket. The OA is a filter, not the real test.

Phone Screen (45 min, CoderPad)

One medium problem, interviewer wanted me talking while coding. Word-break variant: return the count of valid segmentations, not just existence. Standard DP: dp[i] = ways to segment s[:i] , transition sums over valid splits. Follow-up on memory for huge dictionaries: trie the dictionary and walk characters from i backward only while the prefix matches.

Virtual Onsite, Round 1: Zigzag Matrix Print

Problem: Given integers m and n , print every element of an m x n matrix in a zigzag pattern: the first row left to right, the second row right to left, the third row left to right again, and so on. Return the order as a flat list.

This sounded like a softball. The trap is that the interviewer will immediately ask a follow-up that changes the traversal direction, so writing cute bidirectional loop code locks you in. I started ugly but flexible: iterate rows, emit as-is on even index and reversed on odd. Clear, modular, easy to hot-swap.

Then came the followup: same traversal but now zigzag along diagonals instead of rows, like the JPEG encoding order. That is a completely different problem. I rebuilt it by walking diagonals indexed by d = r + c , flipping the direction on even versus odd d , and yielding (r, c) for valid cells. Total time around 25 minutes across both versions. O(m n) both ways.

Virtual Onsite, Round 2a: Listing Subset Optimization

Problem: You are given a list of Airbnb listings, each with an id , a neighborhood , and a capacity . Given a neighborhood filter and a group size , pick a subset of listings in that neighborhood whose total capacity is at least group size , and return the IDs. Primary objective: minimize the number of listings. Secondary objective: minimize wasted capacity (total capacity minus group size).

This is a lexicographic multi-objective knapsack. Filter by neighborhood first. Within the filtered set, "minimum number of listings" is the outer optimization: iterate over subset size k from 1 upward, and for each k check if there is a choice of k listings summing to at least group size , then pick the one with smallest total capacity.

For small input (interviewer said up to 20 listings per neighborhood), 2^n subset enumeration is fine. I coded it that way, ran the examples, then discussed scaling. The DP version: dp[k] = smallest feasible total capacity using exactly k listings. The interviewer did not ask me to code it.

Practice it: [[problem/391?company=9|Menu Bundle Minimum Cost]]

Virtual Onsite, Round 2b: Tasks With Deadlines

Problem: Given a list of tasks, each with id , integer deadline (days from today), and integer reward points . Each task takes exactly one day. Schedule as many tasks as possible such that every scheduled task finishes on or before its deadline. Among schedules that scheduled the same number of tasks, maximize total reward. Output the order and the sum.

This is the scheduling classic. Greedy approach that actually works: sort tasks by deadline, then iterate, maintaining a min-heap (keyed by reward) of currently scheduled tasks. If the current task can still fit (heap size strictly less than its deadline), push it. Otherwise compare its reward with the heap's minimum; if it is larger, swap it in. At the end, the heap holds the optimal subset and the sum of rewards is the answer.

O(n log n). I had seen this problem twice before in different wrappers, so I ran the three provided test cases in the first 15 minutes and spent the rest on the proof of correctness, an exchange argument: any allegedly better schedule can be swapped toward the greedy schedule without reducing reward.

Practice it: [[problem/396?company=9|Task Scheduling with Deadlines]]

Virtual Onsite, Round 3: Listing Search System Design

Problem: Design Airbnb's listing search. Requirements: support filter by price, location radius, dates, and capacity. Tens of millions of listings worldwide. Query latency p99 under 300 ms. Relevance scoring incorporates review quality and booking success rate.

I structured it in layers with Airbnb-specific color.

  1. Write path. Listings in Postgres, CDC pipeline to Elasticsearch for the inverted index, plus a geospatial index on S2 cells for radius queries.
  2. Query path. API gateway fans out to Elasticsearch with a geo-filter and structured filters, returns a ranked id list.
  3. Ranking. Two-stage. Lightweight BM25 plus hand-weighted signals. Heavyweight rerank on the top 200 candidates using feature-store features (host rating, historical booking rate, price for the user's segment).
  4. Caching. Popular cities with common date ranges cached 60s. Never cache unique-user combinations.
  5. Availability. Before returning, intersect candidate IDs with the availability service for the requested dates. Separate microservice backed by per-listing bitmap.

The interviewer pushed on cold start: how do you rank a new listing with zero reviews? I talked about falling back to neighborhood-average signals and using a Bayesian prior that decays as the listing gets traffic. Then on flexible dates: precomputed buckets of date ranges or a per-listing calendar query service. I sketched both, said I would prototype them and benchmark.

Virtual Onsite, Round 4: Behavioral and Values

Airbnb interviews for values explicitly. The full list is on their careers page, and I had mapped one story to each value in prep. Questions I got:

  • Walk me through the project you are most proud of
  • Tell me about a technical challenge where you were stuck and how you got unstuck
  • Do you have remote collaboration experience and how do you communicate asynchronously
  • What about Airbnb's mission do you actually care about

I chose to be specific on the async communication answer. Airbnb is more remote-friendly than most companies I interviewed at, and they want to see that you have thought about time zones, not just "yeah I slack people."

Result

Offer at Airbnb's mid-IC level (L4). Comp was close to Meta E4 but weighted more to equity. Recruiter followup was fast once the debrief wrapped.

Tips

  1. Run your code. Every time. Without being asked. Airbnb is the most explicit "your code must execute" company I have interviewed at. I watched myself hit run in every coding round, paste in the sample, and visually verify the output. Candidates who only dry-run get cut.
  2. The second task scheduling problem is always the same problem. Airbnb has asked the deadline-scheduling problem across multiple cycles. If you have not done the greedy-with-heap solution, do it before your loop, not during.
  3. For Round 1 matrix printing, expect a direction change. The interviewer will flip the traversal on you. Write modular row-by-row code, not cute one-liners, so you can swap the iteration pattern without rewriting.
  4. System design ranking is Airbnb-specific. Know the two-stage ranking pattern with a feature store, and have a real answer for cold start. Generic "use Elasticsearch" will not pass. Read Airbnb's engineering blog posts on search before your loop.
  5. Values interview is not generic behavioral. The questions in Round 4 are derived from the published values. Map your stories to "Be a Host," "Champion the Mission," etc. explicitly in your head, even if the interviewer does not say the values out loud.
  6. Expect the onsite split across two days. Airbnb often breaks the loop across two mornings. Use the gap to recover, not to cram. I reviewed one extra system design for an hour the evening between days and it was worth nothing; I should have slept.

Airbnb is a loop that rewards clarity and execution over cleverness. Make your code run and make your stories land, and you will be in good shape.