This guide covers what a Data Scientist at Airbnb is expected to do and how to prepare for the interview.
Recruiter Screening Call
reportedMost candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.
What to demonstrate
- Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
- Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
- The substance of the questions you ask back, which an experienced screener reads as a level signal
How to prepare
- Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
- Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
- Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered
Take-Home Assignment
reportedYour submission is read asynchronously by someone who cannot ask you a clarifying question, and who will usually skim it before reading it properly. That changes what good looks like. The conclusion belongs near the top with the supporting analysis beneath it, and the code should run start to finish on a clean machine without a manual step you forgot to document. A reviewer forced to reconstruct your reasoning from the order of notebook cells is already discounting the work. The submissions that land are the ones where a busy reader gets the answer immediately and can verify it if they want to.
What to demonstrate
- Whether the answer arrives before the methodology, so a reader who stops after the first page still has the recommendation
- Whether the code runs end to end from the submitted files, with dependencies and data paths declared rather than assumed
- Whether each chart is legible on its own, carrying axis labels and units, and exists to support a claim made in the text
How to prepare
- Restructure a past analysis so the opening paragraph holds the recommendation and the number behind it, then check that nothing later in the document quietly contradicts it
- Copy your own submission into an empty directory, run it in a clean environment, and fix everything that breaks; hidden local state is caught here or by the reviewer
- For every chart, write the one sentence it is meant to prove, and delete the chart if you cannot write that sentence
Technical Coding Screen
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
Virtual or On-Site Loop
reportedA day of back-to-back interviews samples your floor, not your ceiling. Four hours in, the habits that carry a good answer are the first to go: restating the question before solving it, asking what the data would have to look like, checking a number before quoting it. What the day decides is whether the tired version of you is still someone to leave alone with an ambiguous problem. The round that sinks a candidate is usually not the hardest one. It is the one immediately after the round that went badly.
What to demonstrate
- Whether the late rounds get the same clarifying questions as the first one, or whether you start answering immediately to save effort
- Whether a weak answer stays in the room it happened in, instead of following you into the next conversation as apology or distraction
- Whether the quality of your questions holds up, since fatigue removes curiosity about the problem before it removes knowledge of the method
How to prepare
- Rehearse the length, not just the content: book four mock interviews of different types in one afternoon with short gaps, because the one you need to observe is the fourth
- Put the two or three questions you ask at the start of any problem on a card in front of you, so that under fatigue it is a habit you run rather than a decision you make
- Decide in advance what the gap between rooms is for: water, one line of notes on anything you promised to follow up, and an explicit close on the round that just ended so it does not travel
- Prepare a different closing question for each interviewer, so the end of a long day does not produce the same one four times
25 candidate reports. Individual accounts describe a particular role and hiring cycle.
Airbnb Senior+ Machine Learning Engineer Interview Experience — Search Ranking and Team Matching
A referred applicant to Airbnb’s personalization and relevance organization reports recruiter contact after two weeks. An initial coding screen asked for book titles to be formatted as a table. Four days later, the applicant advanced to a virtual onsite covering document redaction, project decisions, search ranking without text queries, and retrieval-assisted guidance for customer-support staff.…
Read full experienceAirbnb Data Engineer Interview Experience — Four-Round Onsite, Then a Recruiter Who Ghosted Me
Not many interview reports out there, so let me add mine — hope it helps. My recruiter was unreliable and ghosted me right after the interview. One round of OA. The VO (onsite) was four rounds of analytics interviews. OA: The SQL was pretty easy. The Python question gave a list/dict of city housing prices, and I had to find the median price for each city. VO: SQL: Find the top N, then figure out…
Read full experienceAirbnb Software Engineer Interview Experience — A Perfect Cloud-Storage OA Score Followed by Rejection
I received the OA immediately after applying, got a perfect score, then received a rejection email a week later. The problem was a cloud storage system. It had four levels. You only got the next level after finishing and submitting the current one. Level 1: Support adding new files, retrieving files, and copying files. Level 2: Support finding files by matching prefixes and suffixes. Level 3: Sup…
Read full experienceAirbnb Software Engineer interview experience
I applied for a Staff Software Engineer role and then heard nothing for more than a month. When I finally got an email, it invited me to a CodeSignal technical interview. The interface looked polished and had practice exercises, but the editor felt limited compared with a VS Code-style workspace and lacked conveniences such as autocompletion. The HackerRank-style assessment allowed 90 minutes and…
Read full experienceAirbnb Software Engineer Interview Experience — A Four-Level Banking System Online Assessment
I recently took Airbnb's software engineering online assessment. I hope this question format helps people who take it later. One of the online assessment questions was a banking system or filesystem with unit tests. It was similar to CodeSignal's progressive-level problems. It was not a set of independent LeetCode questions; instead, new requirements kept being added to the same codebase. The ove…
Read full experiencePracHub editorial advice for the preparation topics above.
Conditioning the analysis on completed orders
Wait-time distributions, price elasticities and rating models fit only on completed orders are conditioned on an outcome that the intervention itself changes. The requests that never matched, or that the consumer abandoned, are the population a liquidity fix targets, so excluding them biases every estimate toward the status quo and can flip the sign of a price elasticity. Any query starting FROM fct_order is already inside this trap; start from fct_request and left join.
Treating abandoned requests as missing rather than censored
Consumers who give up before matching are censored observations, so the mean time-to-match computed over matched requests understates true waiting and improves mechanically whenever abandonment rises. A change that makes people quit sooner will look like a latency win. Use survival methods with abandonment as the censoring event, or never report time-to-match without reporting abandonment next to it.
SQL that silently fans out on a one-to-many join
State the grain of each table and the grain you want in the result before writing the join. Pre-aggregate the many side to the join key, or use EXISTS or a window function, and verify with a row count against COUNT(DISTINCT id) rather than trusting that the numbers look plausible.
Reaching for a model before the target metric exists
Before naming an algorithm, write down the label, the prediction time, and the action that changes when the score crosses a threshold. If you cannot say what decision the output drives, any modelling choice is guesswork dressed up as method.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you calculate confidence intervals for ratios or non-linear met…
How do you calculate confidence intervals for ratios or non-linear metrics derived from skewed datasets?
Approach
- Say what the estimate is of, and over what population it generalises.
- Sanity-check the answer against a simple bound or a simulated case.
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
Follow-up
- How would you explain this result to someone who does not know statistics?
- What sample size would you need to detect an effect half this size?
When is propensity score matching preferable to regression adjustment …
When is propensity score matching preferable to regression adjustment in estimating the causal impact of a customer support intervention?
Approach
- Check what information would not exist at prediction time, and exclude it.
- Set a baseline first, so any model has something honest to beat.
- Pick an evaluation metric that matches the cost of each error type, not a default.
Follow-up
- What would you monitor after launch to know the model is still valid?
- Where could label leakage enter this setup?
Simulate dispatch cascades and the censoring of wait time
A request is offered to one provider at a time. Each offer resolves 12 seconds after it is sent, and each provider accepts independently with probability 0.55. After six declines the request is marked no_supply. Independently, the consumer abandons at time A drawn from an Exponential distribution with mean 90 seconds; abandonment before a pending offer resolves ends the request unmatched. Simulate 200,000 requests and report: the share matched, the mean time-to-match over matched requests, and the mean over requests that would have matched with abandonment switched off. Give a Monte Carlo standard error for the share.
Approach
- Vectorise the cascade: draw K with np.random.default_rng().geometric(0.55), mark K > 6 as no_supply, and draw A = rng.exponential(90) independently; the match condition is K <= 6 and A > 12*K. Looping request by request is the difference between two seconds and two minutes of runtime.
- Compute both means on the same draws so the comparison is paired and the difference is not itself a Monte Carlo artefact.
- Recognise the structure driving the answer: abandonment censors long cascades harder than short ones, so conditioning on matched requests is not a neutral filter, it is a filter correlated with the quantity being measured.
- Quote the share to three decimals only: the standard error of a proportion is sqrt(p(1-p)/n), roughly 0.0009 at n = 200,000, so further digits are noise.
- Check against the closed form P(match) = sum over k of 0.45^(k-1) * 0.55 * exp(-12k/90) for k = 1..6; a simulation with no analytical check is an untested function.
Worked solution 30 min
- k = rng.geometric(0.55, size=200_000); a = rng.exponential(90.0, size=200_000); t = 12.0 * k.
- supplied = k <= 6; matched = supplied & (a > t).
- share = matched.mean(); se = sqrt(share * (1 - share) / 200_000).
- observed_mean = t[matched].mean(); latent_mean = t[supplied].mean().
- Compare share against the closed form 0.7911 and print the gap in standard errors.
Follow-up
- A change ships that makes consumers abandon sooner. What happens to your reported mean time-to-match, and how would you report latency so that this cannot look like a win?
- How would you estimate the same quantity from production data, where you never observe the latent match time of an abandoned request?
Write a query using SQL window functions to calculate running 30-day b…
Write a query using SQL window functions to calculate running 30-day booking totals and identify user churn points.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- How would you verify this result without re-running the same query?
- How does the query change if the join becomes one-to-many?
Transform a sparse table of user activity logs into a user-session mat…
Transform a sparse table of user activity logs into a user-session matrix using advanced aggregation techniques.
Approach
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
Fill rate by market-day without averaging hourly rates
fct_request holds one row per demand request: request_id, market_id, requested_at_utc, requested_at_local, matched_at_utc (NULL when the request never matched), terminal_at_utc, request_status. dim_market holds market_id, vertical, timezone. Produce SLA fill rate per market per local calendar day for the last 28 days. A request enters the numerator when matched_at_utc is not null and matched_at_utc minus requested_at_utc is at or under 120 seconds for vertical 'ride' and 600 seconds for 'delivery'. Exclude requests with request_status = 'abandoned_pre_match' whose terminal_at_utc is within 10 seconds of requested_at_utc. Return market_id, local_date, numerator, denominator, rate.
Approach
- Build the eligible population as a CTE first: cut the 28-day window, then drop the sub-10-second abandons. Applying the exclusion before any aggregation guarantees the numerator and the denominator are computed over the identical row set.
- Cut the window and take the bucket off the same clock. local_date is date(requested_at_local), and the window is local_date BETWEEN end_date - 27 AND end_date, where end_date is the last local calendar date that has closed in every market. Cutting on requested_at_utc instead moves the day boundary by up to 14 hours: the same query then returns 29 local dates for any market at a non-zero UTC offset, the first and last of them partial. A partial edge day holds a few hours of one market's overnight or evening traffic, so its rate is computed over a slice whose fill rate is nothing like the day's, and it is then read beside 27 whole days.
- Express the SLA as a CASE on dim_market.vertical rather than a hardcoded constant, then compute the numerator as COUNT(*) FILTER (WHERE matched_at_utc IS NOT NULL AND matched_at_utc - requested_at_utc <= sla).
- Aggregate once at market by local_date and divide summed numerator by summed denominator. If an hourly view is also wanted, compute the hourly counts and re-sum them to the day; do not average the hourly rate.
- Divide through NULLIF(denominator, 0). Under the CTE-first shape a market-day whose rows were all excluded produces no row at all rather than a zero denominator, so a gap in the dates means zero surviving requests, not a zero rate. Keep the NULLIF anyway: it is what stops a divide-by-zero the day someone moves the exclusion inside the aggregate instead of ahead of it.
Worked solution 20 min
- Count rows inside the 28 local-date window before and after the sub-10-second exclusion; the exclusion should remove a low single-digit percentage, not a third of the table.
- Write the CASE-based SLA and hand-check five matched requests against their computed time-to-match.
- Aggregate to market by local_date with COUNT() for the denominator and COUNT() FILTER (...) for the numerator, in one pass.
- Divide the summed counts with NULLIF on the denominator, then count distinct local_date per market before ordering the output by market_id, local_date.
Follow-up
- Fill rate is flat at the market-day level but down four points in the 17:00 to 19:00 local hours. Which cut do you run next, and what would confirm a supply cause rather than a demand spike?
- The 10-second exclusion removes six percent of requests in one market and half a percent in another. What do you check before trusting either market's rate?
How would you design the primary success metrics for a new feature all…
How would you design the primary success metrics for a new feature allowing instant booking for first-time guests?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
Design a metric to quantify the health of trust and safety interaction…
Design a metric to quantify the health of trust and safety interactions within messaging channels.
Approach
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- Which segment would you cut first, and what would that rule out?
Explain the underlying assumptions of difference-in-differences models…
Explain the underlying assumptions of difference-in-differences models and how you test for parallel trends.
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- Which segment would you cut first, and what would that rule out?
A key metric for host retention dropped by five percent week-over-week…
A key metric for host retention dropped by five percent week-over-week. Walk through your systematic approach to diagnosing this drop.
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Restate the decision this analysis has to support, and who acts on the answer.
- Fix the population and the time window before naming any metric.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- Which segment would you cut first, and what would that rule out?
How do you account for hidden confounders when evaluating the organic …
How do you account for hidden confounders when evaluating the organic growth impact of a marketing campaign?
Approach
- Say whether units interfere with each other, and switch design if they do.
- Name the guardrails that would stop a launch even on a positive primary result.
- State the primary metric and the minimum effect worth shipping, then size the test.
Follow-up
- What would you do if you could not randomise at all?
- What would you conclude if the result is positive but the test is underpowered?
How do you determine statistical significance and minimum sample size …
How do you determine statistical significance and minimum sample size when dealing with highly skewed gross booking value distributions?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Say whether units interfere with each other, and switch design if they do.
- Decide the analysis before seeing data, including how long it runs and when you look.
Follow-up
- What would you do if you could not randomise at all?
- How would you handle interference between treated and control units?
Choose one health metric for a single market week
A market lead wants one number on the weekly review slide for one market. They propose gross bookings. Last week in that market a 12.5% surge-driven price rise coincided with completed orders falling 4%, so gross bookings rose 8%. Using fct_request, fct_order and dim_user, propose a replacement. Give numerator, denominator, window and exclusions explicitly, name one guardrail, and say in one sentence why you rejected gross bookings and why you rejected raw signups. Do not propose a dashboard; propose one primary number and one guardrail.
Approach
- Name the decision the number serves before defining it: this slide decides whether the market gets more incentive budget next week, so the number has to move only when the market actually clears more orders at a defensible cost.
- Show arithmetically why gross bookings fails: 1.125 x 0.96 = 1.08, so an 8% rise is consistent with 4% fewer completed orders. A level metric that is price times volume cannot separate the two, and price is a lever the team controls.
- Define the replacement fully: completed orders per active consumer over the trailing 28 days, numerator = count of fct_order rows with order_status = 'completed' and completed_at_utc in the window for that market_id, denominator = distinct consumer_id in fct_request with requested_at_utc in the same window and the same market_id. State the exclusion for the documented 10-second mis-tap requests so the denominator matches the fill-rate definition.
- Attach the guardrail that blocks the cheap route: contribution margin per completed order, because the fastest way to raise orders per active consumer is a credit that never pays back, and the margin metric prices exactly that.
- Flag the known weakness out loud: this rate falls when acquisition succeeds, because new cohorts transact less than tenured ones, so report the denominator next to the rate and read frequency by tenure bucket before calling a decline an engagement problem.
Worked solution 20 min
- Write the decision the slide supports in one line, then list three candidate numbers: gross bookings, completed orders, completed orders per active consumer.
- Test each candidate against the given week: multiply 1.125 by 0.96 and confirm gross bookings rose 8% while the market served fewer orders.
- Write the surviving candidate as numerator, denominator, window and exclusions, naming the exact tables and columns.
- Write the guardrail with the same rigour, sourcing refunds, chargebacks and processing fees from fct_money_movement attributed to the order's completion month.
- Write one sentence beginning 'this breaks if' for the primary metric and confirm the guardrail blocks that route.
Follow-up
- The market runs a two-week promotion. Which of your two numbers moves first, and what would you expect the second to do in week three?
- If you could add exactly one more number to the slide, is it a supply-side metric or a consumer-side one, and what does it buy you?
- How would you handle a week where one large zone was closed for an event?
Separate a client release regression from a broken event pipeline
Requests from one client platform fell 12% over four days while the other two platforms held flat. fct_request carries client_platform ('ios','android','web') and requested_at_utc, and you can join app version onto each request. A staged rollout of a new build for that platform started on day one and reached full traffic on day four. Decide whether requests genuinely fell or simply stopped being recorded. Deliverable: a verdict, the evidence that settles it, and the one query result that would change your mind.
Approach
- Plot the daily platform series against the rollout share. A regression inside the new client code tracks the rollout curve; a logging or ingestion break is a step at a deploy or partition boundary and hits every version of that platform at once.
- Split within the platform by app version. If users still on the old build dropped by the same amount, the new build cannot be the cause and the search moves to server-side or pipeline changes.
- Test whether rows are missing rather than events. Anti-join fct_order back to fct_request on request_id: an order whose parent request row does not exist is proof of row loss, because the order could not have been created without a request.
- Treat unchanged downstream rates as suggestive only. Uniform row loss leaves fill rate, completion rate and dispatch_attempts intact, but so can a proportional fall in genuine demand. What decides it is a count that does not travel the same logging path, such as the orphan count above or the platform's share of authenticated sessions.
- If the build is implicated, resist a naive before-and-after on the same version. Rollout cohorts self-select, since users who auto-update differ from users who do not, so rely on the ramp-shape argument or on a held-back slice if the release had one.
Follow-up
- The rollout shipped with no holdback. How would you bound the effect without one?
- Requests recovered on day five with no code change deployed. What is now the leading hypothesis?
- What instrumentation would make this ambiguity impossible to reach next time?
Instead of guessing where the week should go, day one measures it under a fixed rubric and allocates the remaining hours in proportion to the gaps. The method is deliberately rigid: the allocation is written down before any studying starts and is not renegotiated when a topic turns out to be unpleasant.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Diagnostic, scored before you study anything
- Sit a 100-minute timed diagnostic in four blocks: 30 minutes of SQL across three prompts, 25 minutes of short-answer statistics, 25 minutes on one modelling or case prompt, and 20 minutes delivering one behavioural story aloud.
- Score each block from 0 to 3 on a fixed rubric where 3 is correct and fluent, 2 is correct but slow or prompted, 1 is partially correct, and 0 is stuck, grading the output rather than how the attempt felt.
- Allocate the hours for days two to five roughly in proportion to 3 minus the score in each block, write the allocation down, and commit to not revising it midweek.
Deliverable: A scored rubric and a fixed hour allocation for the rest of the week.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Largest gap: find the boundary rather than the subject
- Break the weakest area into five named sub-skills (for query work: grain control, window frames, date arithmetic, set logic with NULLs, and reading a query plan) and rate each one, so the rest of the week targets a sub-skill instead of a subject.
- Solve three problems chosen to sit just above where the rating drops off, and for each write the first move you failed to make.
- Re-solve one of them from memory four hours later, on paper, with nothing open.
Deliverable: A five-item sub-skill map with the two blocking sub-skills circled.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Largest gap: drill the blocking sub-skill
- Do eight short repetitions of the same shape rather than eight different problems, so what you practise is the pattern and not the puzzle.
- Write the rule you now hold in one sentence, then test it against a case built to break it: a ranking function over a column with ties, or a two-sample test on observations that are obviously dependent.
- Have someone else read your one-sentence rule and find the precondition you left out.
Deliverable: One rule statement with its preconditions attached and one counterexample that would have caught the incomplete version.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Second gap, plus maintenance on your strongest area
- Run the same sub-skill map and boundary protocol on the second-largest gap, compressed into half the day.
- Spend 25 timed minutes on your strongest area to stop it decaying, choosing the hardest problem you can still finish rather than an easy warm-up.
- Compare how the two areas fail: whether you lose time on recall, on setup, or on arithmetic, because the fix differs for each.
Deliverable: A second sub-skill map plus a one-line diagnosis of how each area fails you.
Practice prompt ↗Practice prompt ↗Worked solution ↗05The gap that is not a skill
- Record yourself answering one technical and one behavioural prompt, then count two things in the playback: how many seconds before your first clarifying question, and how many sentences you started without knowing where they ended.
- Rewrite your three most-used stock phrases into shorter versions, and practise saying "I do not know, here is how I would find out" without softening it into a guess.
- Deliver one answer again with a hard 90-second limit to force structure before detail.
Deliverable: Two recordings with a counted improvement in time-to-first-question.
Practice prompt ↗Practice prompt ↗06Retest under day-one conditions
- Sit the same 100-minute diagnostic structure with new prompts of comparable difficulty and score it on the identical rubric.
- Compare block by block, and for any block that did not move, change the method rather than adding hours: a block stuck at 1 usually means the practice was too varied, not too short.
- Write which single block you would still lose the offer on.
Deliverable: A second scored rubric placed next to the first, with one named remaining risk.
Practice prompt ↗Practice prompt ↗07Full loop under interview conditions
- Run a 60-minute mock covering the two blocks that moved least, with an interviewer instructed to interrupt and change direction.
- Write your recovery script for the moment you go blank: restate the question, state your assumption, name the first thing you would check.
- Reduce the week to the rule statements you wrote, each with its preconditions attached, then say every one of them out loud without reading it and cut any you cannot state in a single sentence, since a rule you have to reconstruct mid-answer will not survive being interrupted.
Deliverable: A one-page card holding the recovery script and only the rules you could state from memory.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Interviewers here are not checking whether you can describe a project. They want the decision you made, why you made it under the information you had, and what changed afterwards that someone else could measure. A story that ends at 'I built a model' has no ending. Say what the model caused, or what you stopped doing because of it.
How do you prioritize competing requests from product, engineering, an…
How do you prioritize competing requests from product, engineering, and operations stakeholders when your team has limited bandwidth?
Approach
- Quantify the outcome, including what you would not claim credit for.
- Name the disagreement or constraint, and how you resolved it with evidence.
- Pick a story where you drove the decision, not one where you observed it.
Follow-up
- What would you do differently if you ran that project again?
- What did you decide not to do, and why?
Explain a switchback confidence interval to a non-technical executive
A switchback test of a dispatch-radius change ran 1,152 market-hour blocks across six markets. SLA fill rate moved +1.8 percentage points, 95% interval [-0.4, +4.0], variance clustered at the block. Those markets serve about 250,000 eligible requests a week at 88% fill and 93% completion. An executive with no statistics background wants a ship-or-wait answer inside a five-minute update. Deliverable: the two-minute spoken explanation, your recommendation, and the single condition that would change it. You may not use the words significant, p-value, or confidence interval.
Approach
- Open with the decision and the recommendation, then justify; an executive who hears the caveat first stops listening before the ask arrives.
- Translate both interval bounds into the unit the executive already manages: eligible requests times percentage points times completion rate gives weekly completed orders, so the range becomes 'between about 1,000 fewer and about 9,300 more completed orders a week, best single guess about 4,200 more'.
- Say plainly what the range does and does not rule out: it does not rule out a small loss, and it is wide because the test has 1,152 effective units, not 250,000 consumers. Block-level randomisation is the reason the sample is small, and it is the reason the number is trustworthy at market level.
- Price the two errors against each other: a reversible dispatch parameter with a bounded downside is cheap to ship and cheap to revert, so the decision rule is not 'is the effect proven' but 'is the worst case affordable and detectable'.
- End with the one condition that flips you: name the monitoring metric (provider utilisation and idle time, since a wider radius can raise fill by burning provider hours) and the threshold at which you revert.
Follow-up
- How many more weeks of blocks would it take to halve the width of that range, and is that worth the delay?
- The executive asks 'so is it real or not' - what do you say without reaching for statistical vocabulary?
- What would you monitor post-ship that the experiment itself could not measure?
Turn a one-line supply request into a scoped analysis
A cross-functional lead messages: 'can you look into whether we have enough drivers in the north zone?' No metric, no deadline, no stated decision. You have fct_supply_session (online_seconds, engaged_seconds, idle_seconds, market_id, offline_at_utc), fct_request (request_status, requested_at_local, market_id, dispatch_attempts) and dim_market (timezone). Deliverable: the three questions you ask before touching data, then a scoping note under 150 words naming the decision it serves, the one number that answers it with numerator, denominator and window, the first cut you run, and the date you return.
Approach
- Ask what lever is being considered, because 'enough supply' has no definition independent of the action: a provider incentive budget, a dispatch radius change and a recruiting target each need a different number and a different window.
- Ask what happens if the answer is 'yes, enough', since a question with the same action under both answers is not worth running, and ask when the decision is made, which sets the depth you can afford.
- Translate the vague word into a measurable pair with opposite signatures: share of requests with request_status = 'no_supply' plus provider utilisation (SUM(engaged_seconds) / SUM(online_seconds)) by market-hour. High utilisation with rising no_supply is supply-constrained; high idle_seconds with flat request counts is demand-constrained.
- State the data handling that changes the answer: clip open sessions (offline_at_utc IS NULL) at the window edge rather than dropping them, and cut by requested_at_local using dim_market.timezone, because supply shortage is an hour-of-day phenomenon that a UTC cut smears away.
- Commit to a first cut and a return date, and name explicitly what you are not doing, so the scope can be argued with before the work rather than after it.
Follow-up
- The lead says 'just give me the driver count' - how do you respond without refusing the request?
- What single additional table would let you distinguish a dispatch problem from a genuine supply shortage?
- How does your answer change if the zone is one part of a market rather than a market_id of its own?
- 01
How do you prioritize competing requests from product, engineering, and operations stakeholders when your team has limited bandwidth?
- 02
A switchback test of a dispatch-radius change ran 1,152 market-hour blocks across six markets. SLA fill rate moved +1.8 percentage points, 95% interval [-0.4, +4.0], variance clustered at the block. Those markets serve about 250,000 eligible requests a week at 88% fill and 93% completion. An executive with no statistics background wants a ship-or-wait answer inside a five-minute update. Deliverable: the two-minute spoken explanation, your recommendation, and the single condition that would change it. You may not use the words significant, p-value, or confidence interval.
- 03
A cross-functional lead messages: 'can you look into whether we have enough drivers in the north zone?' No metric, no deadline, no stated decision. You have fct_supply_session (online_seconds, engaged_seconds, idle_seconds, market_id, offline_at_utc), fct_request (request_status, requested_at_local, market_id, dispatch_attempts) and dim_market (timezone). Deliverable: the three questions you ask before touching data, then a scoping note under 150 words naming the decision it serves, the one number that answers it with numerator, denominator and window, the first cut you run, and the date you return.
Is this an official Airbnb interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Airbnb. Rounds and questions reflect what candidates have reported, not a process Airbnb has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the interview process, and how much preparation time should I plan for?
The interview loop is rigorous and thorough, reflecting the high standards of the organization. Most candidates dedicate between four to six weeks of focused preparation, particularly refreshing advanced SQL, experimental design nuances, and machine learning implementation.
PracHub interview research ↗What differentiates successful candidates from those who do not pass?
Successful candidates excel at bridging technical depth with product intuition. Rather than jumping straight into code or formulas, they take time to clarify ambiguity, state their assumptions, and tie their analytical approaches back to core business and user impact.
PracHub interview research ↗How are take-home assignments evaluated?
Take-home projects are evaluated on analytical rigor, code quality, and the clarity of your insights. Focus on producing clean, well-documented code and a concise summary that highlights your decision-making process rather than overwhelming the review team with excessive output.
PracHub interview research ↗What is the typical timeline from the initial recruiter screen to final offer?
The entire process generally spans three to four weeks from the initial recruiter conversation through the take-home challenge, technical screens, and virtual on-site rounds, though timelines can vary based on team scheduling and headcount needs.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Zillow Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Zillow, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Whatnot Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at Whatnot candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
Uber Drivers Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Uber Drivers, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Turo Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Turo: a messy dataset, a fixed time budget, and a written analysis, reviewed for whether it states its assumptions and whether a reader could reproduce your numbers.