Airbnb Data Scientist Interview Questions & Guide 2026

Interviewing at Airbnb

• Practice bank: 24+ questions
• Rounds: 3
• Typical prep: 2–4 weeks
• Interview reports: 2

Interview rounds

Round	Questions
HR Screen	5
Technical Screen	17
Onsite	2

How hard is the Airbnb Data Scientist interview?

Difficulty	Share	Questions
Easy	0%	0
Medium	71%	17
Hard	29%	7

What Airbnb actually tests for

Topic	Share	Questions
Analytics & Experimentation	50%	12
Behavioral & Leadership	21%	5
Data Manipulation (SQL/Python)	21%	5
Machine Learning	4%	1
Statistics & Math	4%	1

The 60-second brief

This guide covers what a Data Scientist at Airbnb is expected to do and how to prepare for the interview.

Airbnb candidates report 4 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

What a Data Scientist does at Airbnb

What the role owns day to day:

• As a Data Scientist at Airbnb, your daily work revolves around partnering with product managers, software engineers, and operations leaders to shape the future of travel and hospitality. You will own analytical initiatives from inception to deployment, ensuring that data-driven insights are embedded into every core product decision. Your responsibilities include formulating product hypotheses, designing large-scale experiments, and building robust predictive models to protect community trust and optimize operational efficiency.
• You will spend a significant portion of your time extracting insights from massive, complex datasets using advanced SQL and Python, translating raw data into clear narratives for executive stakeholders. Whether you are collaborating with trust engineering teams to deploy sophisticated identity verification defenses or working with customer support to personalize user routing, you serve as the analytical backbone of your product group. You will also contribute to the broader data science community by mentoring peers, establishing best practices for experimentation, and continuously raising the technical bar across the organization.

What the role is screened against:

• Securing an offer as a Data Scientist at Airbnb requires a combination of strong technical execution, deep domain expertise in experimentation or machine learning, and exceptional communication skills. The hiring team looks for candidates who can navigate ambiguity and demonstrate rigorous scientific thinking.
• Must-have skills – Advanced proficiency in SQL and Python or R; deep theoretical and practical experience with A/B testing and experimental design; strong foundation in applied statistics and regression modeling; proven ability to translate complex data findings into actionable product recommendations.
• Nice-to-have skills – Experience with causal inference methods in two-sided marketplaces; familiarity with machine learning engineering and production code deployment; background in specialized problem spaces such as trust, fraud detection, or customer support optimization.
• Experience level – Typically 3 to 7+ years of industry experience in a quantitative data science role, with a track record of owning end-to-end analytical projects and influencing cross-functional product roadmaps.

The Airbnb interview process

Airbnb candidates report 4 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

Recruiter Screening Call

Most 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 it evaluates

• 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

Your 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 it evaluates

• 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

Before 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 it evaluates

• 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

A 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 it evaluates

• 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

Questions Airbnb candidates report

Product sense and metrics

When the prompt says a number moved, the first question is whether it moved. Instrumentation changes, a redefinition, a backfill, a release that drops events, bot traffic and a plain holiday all produce the same shape as a real behaviour change. Confirm the move survives those before you reason about users at all. After that, localise instead of speculating: cut by platform, geography, tenure and acquisition source, and ask whether the aggregate fell because a segment changed or because the mix of segments changed. Weak answers list ten plausible causes. Strong ones order the cuts so each result eliminates several at once.

• How would you design the primary success metrics for a new feature allowing instant booking for first-time guests?
• Design a metric to quantify the health of trust and safety interactions within messaging channels.
• Explain the underlying assumptions of difference-in-differences models and how you test for parallel trends.
• A key metric for host retention dropped by five percent week-over-week. Walk through your systematic approach to diagnosing this drop.

SQL and data manipulation

These questions are rarely hard to solve and easy to get subtly wrong in the minutes available, so how you spend the clock is part of the answer. Write the filter and the spine, run it, look at ten rows, then add one layer and run again. That costs seconds and catches the errors that otherwise arrive as a plausible number you cannot defend. Keep the last minute for checks that fit on one line: row count against distinct key count, funnel stages that should only shrink, and nulls where a left join found nothing. Say out loud what you checked.

• Write a query using SQL window functions to calculate running 30-day booking totals and identify user churn points.
• Transform a sparse table of user activity logs into a user-session matrix using advanced aggregation techniques.

A/B testing and experimentation

Start every answer by naming the unit you randomise and the unit you analyse, and make sure they are the same thing. A test assigned by user but analysed per page view has many correlated rows inside each arm, so treating those rows as independent makes the standard error too small and the result looks more certain than it is. Splitting the other way fails differently: randomise by page view and one person lands in both arms, which contaminates the comparison and pulls the measured effect toward zero rather than flattering it. If the metric is a ratio whose denominator varies by user, say so and reach for the delta method or a bootstrap at the user level. Weak answers jump straight to the statistical test. Strong ones fix the unit, and the test follows from it.

• How do you account for hidden confounders when evaluating the organic growth impact of a marketing campaign?
• How do you determine statistical significance and minimum sample size when dealing with highly skewed gross booking value distributions?

Statistics and probability

Nearly every question in this category is about a quantity you cannot observe, estimated from a sample that could have come out differently. So the first move is to name the estimand out loud: a mean, a proportion, a difference of two means, a ratio. Then say what its sampling distribution looks like and where that shape comes from. The split between strong and weak answers is almost always here. A weak answer describes how the data are spread. A strong one describes how the estimate would vary across repeated samples, and never lets those two standard deviations blur together.

• How do you calculate confidence intervals for ratios or non-linear metrics derived from skewed datasets?

Machine learning and modelling

Leakage is easiest to catch by giving every column a timestamp and asking whether that value was knowable at prediction time. An aggregate computed over the whole table, a status field that gets updated after the outcome, an identifier that encodes which batch the outcome landed in: each one pipes the future into training and shows up as an offline score that is too good. The defence is a split by time rather than at random, plus a feature pipeline that recomputes history as of the prediction moment. Suspicion of a large gain, before celebrating it, is the tell.

• When is propensity score matching preferable to regression adjustment in estimating the causal impact of a customer support intervention?

Behavioural and stakeholder questions

Some of these are less about conflict than about what you do with a vague request. Someone asks for a dashboard, or for a number by Thursday. Underneath it sits a decision somebody is about to make, and the first useful move is to find that decision and ask what they would do differently depending on the answer. Answers get noticeably stronger when you describe the scope you refused alongside the scope you took. Saying that you dropped two of five requested breakdowns because they could not be measured cleanly, and saying it before anyone asks, reads as judgement rather than as a shortfall.

• How do you prioritize competing requests from product, engineering, and operations stakeholders when your team has limited bandwidth?

Practice exercises with worked solutions

The prompts above tell you what gets asked.

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.

How a strong candidate works it

• 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.

Expected result (20 min): One row per (market_id, local_date), covering at most 28 local dates per market, with integer numerator and denominator and a rate in [0,1]. A market-day with no surviving requests produces no row, so a missing date is a zero-volume day rather than a zero rate. Because the rate is SUM(numerator)/SUM(denominator), re-aggregating the output to a market total by re-summing the two count columns reproduces that market's 28-day rate exactly.

Check yourself

• SUM(denominator) over the whole output equals a plain count of surviving in-window requests computed with no joins, where both sides cut the window on requested_at_local.
• COUNT(DISTINCT local_date) per market is at most 28 and never 29. A 29th date, or a first and last date carrying a fraction of their neighbours' volume, means the window was cut on requested_at_utc while the bucket was taken from requested_at_local.
• No row has numerator greater than denominator, and no rate exceeds 1.
• Re-summing the day rows to a market total gives a different number from AVG of the daily rates; if the two agree to four decimals, your daily volumes are implausibly uniform and something is wrong.

Follow-ups

• 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?

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.

How a strong candidate works it

• 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.

Expected result (30 min): Matched share about 0.791 (closed form 0.7911, Monte Carlo SE about 0.0009); mean time-to-match over matched requests about 19.5 seconds; latent mean over all requests with K <= 6 about 21.2 seconds; the observed mean therefore understates the true wait by roughly 1.7 seconds, about 8%.

Check yourself

• Simulated share is within about three standard errors of the closed form 0.7911.
• Setting the abandonment rate to zero makes both means equal at about 21.21 seconds, confirming the gap is entirely censoring.
• The no_supply share (K > 6) matches 0.45^6 = 0.00830 within Monte Carlo error.
• Lowering the abandonment mean from 90 to 30 seconds pushes the observed mean down further while the latent mean is unchanged.

Follow-ups

• 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?

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.

How a strong candidate works it

• 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.

Expected result (20 min): Primary: completed orders per active consumer, trailing 28 days, per market, numerator from fct_order.order_status = 'completed', denominator from distinct consumer_id in fct_request over the same window and market, excluding requests abandoned within 10 seconds. Guardrail: contribution margin per completed order. Gross bookings rejected with the arithmetic 1.125 x 0.96 = 1.08; raw signups rejected because it is a top-of-funnel level with no completion in it.

Check yourself

• The 8% figure reproduces exactly from 1.125 x 0.96, confirming a level metric cannot separate price from volume.
• Every element of both definitions is computable from a named column; no term such as 'engaged user' is left undefined.
• The stated gaming route for the primary metric is blocked by the named guardrail, not by a second metric that moves the same way.

Follow-ups

• 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.

How a strong candidate works it

• 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-ups

• 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?

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.

How a strong candidate works it

• 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-ups

• 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.

How a strong candidate works it

• 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-ups

• 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?

Where candidates lose points

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.

Before the Airbnb loop

• Preparing effectively for the Data Scientist loop at Airbnb requires a balanced approach across technical mastery, product intuition, and communication clarity. Interviewers look for candidates who can bridge advanced statistical theory with practical, business-driven execution.
• Role-related knowledge – This criterion measures your command of core data science concepts, including causal inference, machine learning implementation, and advanced SQL. Interviewers evaluate how fluently you apply these tools to solve messy, real-world problems. Demonstrate your strength by explaining not just how a model works, but why you chose it over alternative approaches.
• Problem-solving ability – This covers how you structure open-ended challenges, form hypotheses, and navigate ambiguity. In interviews, you should establish a clear framework before diving into calculations or code. Show that you can adapt your approach dynamically when an interviewer introduces new constraints or data points.
• Leadership and collaboration – At Airbnb, data scientists act as strategic partners to product and engineering teams. Interviewers assess your ability to influence roadmaps, communicate complex findings to non-technical stakeholders, and manage cross-functional disagreements. Highlight past experiences where you successfully drove projects from conception to completion across multiple teams.

Weakness triage, driven by a day-one diagnostic

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.

Day 1 — Diagnostic, 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.

Day 2 — Largest 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.

Day 3 — Largest 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.

Day 4 — Second 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.

Day 5 — The 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.

Day 6 — Retest 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.

Day 7 — Full 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.