Airbnb Data Scientist Interview Preparation Guide (Junior Level)

How they work together:

• CPython uses reference counting: each object tracks references; when count hits zero it's reclaimed immediately.
• The cyclic GC (generational, meaning it groups objects by how long they've survived so far and scans the youngest group most often, since most garbage dies young and rarely needs a second look) complements this by detecting reference cycles that reference counting alone can't free.

Example needing GC:
Two objects referencing each other (cycle) with del avoided or handled by GC. Example:

class Node:
    def __init__(self):
        self.ref = None

a = Node()
b = Node()
a.ref = b
b.ref = a
# If no external refs remain, ref counts are non-zero due to cycle -> GC must collect

Actually watching the reclamation happen, verified on CPython 3.12, extending the example above with a __del__ and an explicit gc.collect():

import gc

class Node:
    def __init__(self, name):
        self.name = name
        self.ref = None
    def __del__(self):
        print(f'__del__ called for {self.name}')

a = Node('a')
b = Node('b')
a.ref = b
b.ref = a
del a, b            # neither refcount reaches zero; both still reference each other

gc.collect()         # the cyclic GC finds the unreachable pair and reclaims it

Output:

__del__ called for a
__del__ called for b

Both finalizers ran as part of gc.collect() reclaiming the cycle, confirming the cycle really was found and cleaned up, not just theoretically collectible.

Reference counting handles most deallocations quickly; the cyclic GC periodically finds unreachable cycles and reclaims them. Cycles involving objects with __del__ used to require special handling: on Python versions before 3.4, the cyclic GC could not safely decide what order to finalize such objects in, so it left them permanently uncollected in gc.garbage instead of guessing. Since Python 3.4 (PEP 442), __del__ is called safely as part of collecting the cycle, exactly as demonstrated above, and the objects are then reclaimed normally; citing the old "cycles with __del__ can't be collected" claim as current fact is a dated answer today.

Direct answer

I'd separate the timeline question from the model-complexity question: propose a simple analytics baseline that can ship inside the deadline, while being explicit about what it will and won't deliver, and frame the more complex model as a follow-up investment once the baseline's results are in.

Structured elaboration

1. Quantify the time-versus-value trade-off concretely. How much longer would the complex model realistically take, and what specific additional value would it capture that the simpler approach can't? Vague statements like "the ML model would be better" aren't useful to a stakeholder making a timeline call.
2. Estimate resourcing for both paths honestly. The simpler analytics approach's true cost (including validation, not just a quick query) versus the ML path's true cost (data preparation, training, evaluation, and the ongoing maintenance it creates).
3. Propose a phased plan. Ship the simpler approach on the stakeholder's timeline, instrument it well enough to measure its actual impact, and use that measurement to make the case (or not) for investing in the complex model afterward.
4. Keep the stakeholder's actual goal in view. The tight timeline usually reflects a real business pressure (a launch date, a reporting deadline); the plan needs to respect that pressure rather than just arguing it away.

Worked example

For an analysis that needs to inform a go or no-go decision in two weeks, a simple cohort-based analysis with clearly-stated assumptions and confidence bounds, delivered on time, is worth more to the business than a more rigorous model that arrives after the decision has already been made without it. Framing this honestly to the stakeholder (here's what the fast approach gives you, here's what it doesn't, here's what a slower approach would add) turns a potential conflict into a shared decision.

Trade-offs and pitfalls

The risk of always deferring to the tight timeline is under-delivering on decisions that genuinely need more rigor; the risk of insisting on the complex approach regardless of the deadline is missing the actual business window entirely, which can make even a perfect analysis worthless. The honest phased-plan framing avoids both traps by making the trade-off explicit rather than making the call unilaterally.

Direct answer

Design this as a pre-registered, longitudinal comparison rather than a single before/after read: fix a small number of windows relative to each user's first exposure, not launch date, in advance, fit a simple decay model to the day-by-day treatment effect, and commit to a decision rule, stated before you see the data, for what pattern of the fitted decay and asymptote counts as real and durable versus novelty that will fade. The goal is to make the durable-vs-fading call a mechanical read of a pre-specified model output, not a judgment call made after watching the curve.

Structured elaboration

Time windows to pre-specify

• Baseline (pre-treatment, roughly two weeks before exposure): confirms no pre-existing difference between the groups on the metric of interest.
• Immediate (days 0 to 7 since first exposure): captures the bulk of any novelty spike.
• Short (days 8 to 30): where a genuine novelty component should be visibly decaying.
• Long (days 91 and beyond, or as far out as the experiment can afford to run): the window whose effect is treated as the primary estimate of the persistent effect, used for the launch decision.
  These are anchored to exposure age, days since each user's own first exposure, not calendar date, so users who join on different days are all compared on the same clock. A calendar-date plot mixes freshly exposed and long-exposed users in the same daily bucket and can mask a real decay curve as a false flat line.

Modeling the decay

Fit the daily or weekly treatment effect to a two-parameter decay-to-asymptote form:
$\Delta(t) = C + A e^{-\lambda t}$
where $t$ is exposure age, $C$ is the persistent (asymptotic) effect, $A$ is the size of the transient novelty component, and $\lambda$ is the decay rate. A purely persistent effect looks like $A \approx 0$, flat from day one; a pure novelty artifact looks like $C \approx 0$, decaying to nothing; most real cases land somewhere in between, with both $A$ and $C$ meaningfully nonzero, meaning some of the early lift really does fade but a smaller durable effect remains.

The decision rule, pre-specified

Commit, before the experiment starts, to a rule such as: the effect is durable if the long-window estimate's confidence interval excludes zero and the fitted persistent component $C$'s confidence interval excludes zero, evaluated no earlier than three estimated half-lives, $3 \times \ln 2/\lambda$, after first exposure. This does three things a post-hoc read cannot: it fixes how long to wait based on the shape of the decay itself rather than an arbitrary calendar deadline, it requires the long-window effect to independently clear significance rather than trusting the fitted curve alone, and it removes the temptation to declare victory the moment the curve looks favorable.

Worked example

Suppose a fitted decay model on the immediate and short windows gives stated, illustrative parameter estimates $A = 6\%$, $C = 2\%$, $\lambda = 0.15$ per week. The half-life of the transient component is:
$t_{1/2} = \frac{\ln 2}{\lambda} = \frac{0.693}{0.15} \approx 4.6 \text{ weeks}$
The pre-specified decision rule requires waiting roughly $3 \times 4.6 \approx 13.9$ weeks, call it 14 weeks, before the long-window read is treated as decisive. At that point, the transient component's contribution has decayed to:
$A \cdot e^{-\lambda \cdot 14} = 6\% \times e^{-0.15 \times 14} = 6\% \times e^{-2.1} \approx 6\% \times 0.122 \approx 0.73\%$
which is small enough that the observed effect at week 14 should be close to the true persistent effect $C$, letting the long-window confidence interval be read as a fair test of durability rather than a mix of fading novelty and true signal.

Trade-offs and pitfalls

• Waiting three half-lives before making the call costs real calendar time and delays every downstream decision riding on this experiment; for a low-stakes cosmetic change, teams often accept a shorter, less rigorous wait rather than the full 14 weeks in the worked example.
• The decay model assumes a single clean exponential; a novelty effect that itself varies by segment, a spike for new users layered with a slower-decaying resistance effect for long-tenured users, will not fit a single two-parameter curve well, and forcing the fit anyway can produce a confidently wrong half-life.
• Anchoring on exposure age rather than calendar date requires per-user first-exposure timestamps captured at assignment time; retrofitting this onto an experiment already running on calendar-date logging means exposure-age curves cannot be reconstructed after the fact.
• A pre-specified decision rule protects against motivated reasoning but is only as good as the pre-specified windows; if the true decay is much slower than assumed when the windows were chosen, day 91 may still be well inside the transient period, so a short pilot or a conservative overestimate of the likely half-life should inform window choice up front, not just the final analysis.

Direct answer

Model each uncertain input (impact, cost, time-to-build, probability of success) as a probability distribution rather than a point estimate, simulate thousands of draws to build a distribution of net present value (NPV) for each project, and compare projects on the full distribution (mean, downside risk, probability of a positive outcome) rather than a single expected-value number. This turns "which project is better" into a probability-weighted statement stakeholders can act on, and exposes cases where two projects have similar expected value but very different risk profiles.

Structured elaboration

Required inputs and typical distributions:

Simulation procedure. For $N$ iterations (tens of thousands for stable percentile estimates): draw impact, cost, time, and a success indicator from their distributions; if the draw is a "failure," realized impact is zero; discount the realized impact back using both the standard time-value discount rate and the project's own time-to-build; subtract cost to get one simulated NPV. Collecting $N$ such draws gives the full NPV distribution per project.

Metrics to report, beyond the mean: median NPV (less sensitive to a few extreme draws), $P(\mathrm{NPV}>0)$ (chance the project isn't a loss), 5th/95th percentiles (downside and upside scenarios), and expected value per month of effort ($\mathrm{mean(NPV)}/\mathrm{mean(months)}$) to account for opportunity cost when time is scarce.

Presenting to stakeholders. A side-by-side histogram or CDF of the two NPV distributions communicates risk far better than two point numbers; a tornado chart from a one-at-a-time sensitivity sweep shows which input uncertainty matters most; framing as "70% chance of a positive NPV" is more actionable to a non-technical audience than a bare expected value.

Worked example

Two projects, discount rate 10%, 2-year impact horizon (pinned seed 99, $N=100{,}000$):

import numpy as np
rng = np.random.default_rng(99)
N, r = 100000, 0.10

def simulate(rng, impact_log_mu, impact_log_sigma, cost_tri, months_tri, p_success):
    impact = rng.lognormal(impact_log_mu, impact_log_sigma, N)
    cost = rng.triangular(*cost_tri, N)
    months = rng.triangular(*months_tri, N)
    success = rng.uniform(0, 1, N) < p_success
    pv_impact = sum(impact/(1+r)**yr for yr in [1, 2])
    pv_impact = np.where(success, pv_impact, 0.0)
    return pv_impact / (1+r)**(months/12) - cost, months

npv_a, months_a = simulate(rng, np.log(2_000_000), 0.4, (800_000,1_200_000,2_000_000), (6,9,14), 0.65)
npv_b, months_b = simulate(rng, np.log(900_000), 0.35, (200_000,350_000,500_000), (2,3,5), 0.80)

Output:

Project A: mean NPV=$925,921  median=$1,049,602  P(NPV>0)=63.7%  [5th,95th]=[-$1,631,431, $4,356,917]
           mean time-to-build=9.7 months, EV/month=$95,789

Project B: mean NPV=$943,136  median=$1,009,700  P(NPV>0)=79.9%  [5th,95th]=[-$394,060, $2,256,010]
           mean time-to-build=3.3 months, EV/month=$283,002

P(A's simulated NPV draw > B's simulated NPV draw) = 49.1%

Both projects have almost the same mean NPV (~$930K), so expected value alone is a coin flip between them. But B has a much narrower downside (5th percentile of -$394K vs -$1.63M for A), a higher chance of any positive outcome (79.9% vs 63.7%), and nearly 3x the expected value per month of effort because it ships faster. A risk-aware recommendation favors B first, with A as a parallel or follow-on bet, which the raw expected-value comparison alone would never have surfaced.

Sensitivity analysis (one-at-a-time sweep on Project A). Re-running the same simulation with one input shifted at a time, same pinned seed so only the shifted input differs between runs, and comparing the resulting mean NPV to the $925,921 baseline shows which assumption the recommendation actually rests on:

baseline = dict(impact_log_mu=np.log(2_000_000), impact_log_sigma=0.4,
                cost_tri=(800_000,1_200_000,2_000_000), months_tri=(6,9,14), p_success=0.65)

def run(params, seed=99):
    rng = np.random.default_rng(seed)
    npv, _ = simulate(rng, **params)
    return npv.mean()

base_mean = run(baseline)
sweeps = {
    "success prob -10pp (0.65->0.55)": {**baseline, "p_success": 0.55},
    "success prob +10pp (0.65->0.75)": {**baseline, "p_success": 0.75},
    "time-to-build +2mo (6,9,14 -> 8,11,16)": {**baseline, "months_tri": (8,11,16)},
    "cost +20%": {**baseline, "cost_tri": (960_000,1_440_000,2_400_000)},
    "impact -20% (2.0M -> 1.6M)": {**baseline, "impact_log_mu": np.log(1_600_000)},
}
for label, params in sweeps.items():
    m = run(params)
    print(f"{label}: mean NPV=${m:,.0f}  delta=${m-base_mean:+,.0f}")

Output, ranked by size of the swing:

(all five reruns verified with python3, same pinned seed 99 per run so only the swept input differs)

The swing from the impact assumption (about $452K) is the largest, narrowly ahead of the success-probability swing (about $351K to $352K in either direction), both far larger than the cost swing (-$267K) and more than ten times the swing from time-to-build (-$36K). This is exactly what a tornado chart visualizes: stack these five bars by width, and impact and success probability are the two long bars at the top, cost is a middle bar, and time-to-build barely moves the needle. The practical takeaway for stakeholders: before committing to Project A, the two assumptions worth double-checking with engineering and marketing are the size of the impact if it works and the probability that it works at all, not the cost estimate or the build timeline, which barely change the recommendation even when pushed by a lot.

Trade-offs & pitfalls

Reporting only the mean NPV throws away exactly the information (downside risk, speed-adjusted value) that made B the better call here despite an essentially tied expected value - this is the single most common mistake in this kind of analysis. Treating inputs as independent when they are correlated in reality (e.g., larger impact projects often also take longer and cost more) understates the true spread of outcomes; where such correlation is known or suspected, it should be built into the simulation via correlated draws rather than assumed away for simplicity. Elicited distributions (especially the triangular min/max) are only as good as the estimators who provided them, and systematic optimism bias in engineering time estimates is common enough that a sensitivity check with a wider or right-shifted time-to-build distribution is worth running before committing to a recommendation.

Multiple comparisons: when testing five variants against control you perform multiple hypothesis tests; each test has Type I error α, so the chance of at least one false positive across tests grows (~1 − (1−α)^5). Without correction you risk acting on spurious wins.

Two strategies to control false positives:

1. Family-wise error control — Bonferroni correction

• Approach: divide your target family α (e.g., 0.05) by number of comparisons m (α' = α/m = 0.01 here). Declare a variant significant only if its p ≤ α'.
• Pros: Simple, conservative, controls probability of any false positive (strong control).
• Cons: Low power when m is moderate/large or effects are small — increases false negatives; ignores dependency structure (overly conservative if tests correlated).
• Decision rule: select variants with p ≤ α/m; safe for high-cost, low-tolerance decisions.

2. False discovery rate control — Benjamini–Hochberg (BH)

• Approach: rank p-values p(1) ≤ ... ≤ p(m); find largest k such that p(k) ≤ (k/m)·α. Reject H0 for p(1..k).
• Pros: Greater power than Bonferroni; controls expected proportion of false discoveries (FDR), suitable when you can tolerate some false positives to gain more true positives.
• Cons: Less strict than FWER; interpretation is probabilistic (expected proportion), and BH assumes independent or positively dependent tests (there are extensions for dependence).
• Decision rule: apply BH to pick a set of positive variants; consider validation holdout or replicated experiment for business-critical launches.

Practical notes: pre-specify primary comparisons, consider sequential/hierarchical testing (test best candidate first), or use Bayesian decision frameworks that directly trade off lift vs. cost. Always report corrected p-values, effect sizes, and confidence intervals.

Direct answer

An array gives $O(1)$ index-based random access and is cache-friendly, because its elements sit in one contiguous block of memory that the CPU can pull into cache together. A singly linked list gives $O(1)$ insertion or deletion once you already hold a reference to the splice point, at the cost of $O(n)$ traversal to reach any given position and extra per-node memory overhead. For a workload that is mostly random reads, pick an array (or dynamic array); for a workload that is mostly insertions and deletions in the middle where you already hold the relevant node reference, a linked list wins.

Structured elaboration

The contiguous-versus-non-contiguous memory allocation framing is exactly this same dimension stated differently: contiguous storage is what gives arrays both their cache locality and their index arithmetic; non-contiguous, per-node allocation is what gives linked lists their cheap local splicing at the cost of locality. In a garbage-collected (GC) language, this also affects collector pressure: many small linked-list node objects mean more individual objects for the garbage collector to track and scan, compared to one contiguous array allocation holding the same data.

Worked example

Consider inserting a new element in the middle of a ten-item collection, repeatedly, as items are typed into an editable list. With an array, each insertion must shift every element after the insertion point one slot over, an $O(n)$ cost per insertion regardless of whether you know exactly where to insert. With a singly linked list, if the editing position is tracked by an existing reference to the node just before it (as a cursor would be in a text-editing context), each insertion is a pure $O(1)$ relink; but if you only know the position as an index and must first walk from the head to reach it, the linked list gains nothing over the array for that access, since both now cost $O(n)$ overall. This is why the deciding factor is not "array versus linked list" in the abstract, but whether the workload naturally hands you a reference to the splice point or only an index.

Trade-offs & pitfalls

Assuming "$O(1)$ insertion" for a linked list means fast in absolute terms is a common mistake: reaching the splice point is usually the dominant cost unless a reference to it is already in hand from a prior traversal or an auxiliary index. Ignoring the per-element memory overhead ratio is another: a linked list of single integers can use several times the memory of the equivalent array, because the pointer overhead per node is fixed regardless of how small the stored value is. Modern hybrid structures such as a deque (double-ended queue) or a rope address parts of this trade-off by chunking data into contiguous blocks rather than choosing purely one extreme or the other.

Direct answer. Between a hash join and its two sequential scans, the operator responsible for the largest share of actual time, usually the sequential scan feeding the larger side of the hash table, is the single most expensive operator; the fix depends on whether that scan is unavoidable (the query genuinely needs most of the table) or a symptom of a missing index.

Structured elaboration. A hash join builds an in-memory hash table from one input (the "build" side, ideally the smaller one) and probes it with rows from the other (the "probe" side). If both inputs arrive via sequential scans, the optimizer likely concluded that no available index was selective enough to be worth using for either side, given the current statistics. To identify the true bottleneck, compare the actual time and actual row count of each of the two scans and of the hash join node itself: a scan whose actual rows are close to the full table size, on a table where the query's predicate should have been selective, points at a missing or unused index rather than at the join algorithm being wrong.

I ran an illustrative version of exactly this shape (100,000 orders rows hash-joined to 20,000 customers, grouped by region) and confirmed the plan chooses a HASH_JOIN over two SEQ_SCAN nodes when there's no index to make either side selective; that structural shape is the general one this kind of question is testing.

Worked example. If orders has 500,000 rows and the query filters orders.status = 'pending' (a selective predicate matching perhaps 2% of rows) but there's no index on status, the sequential scan reads and filters all 500,000 rows in memory rather than a cheap index lookup returning roughly 10,000. Adding a matching index and re-running the plan would typically change that leaf to an index scan and shrink the rows flowing into the hash join dramatically, which is the concrete next optimization to try rather than trying to force a different join algorithm.

Trade-offs and pitfalls. Forcing a different join algorithm (via a hint or session setting) without first fixing an obviously-missing index just relocates the cost; the hash join was likely the RIGHT choice given the (large) inputs it was handed. Fix the input sizes first, and only reconsider the join algorithm itself if the inputs are already as small as they can reasonably be.

Direct answer

The interviewer wants to see whether you treat pushback as a signal to investigate rather than an obstacle to argue past. A strong answer names the specific objection, what you did to address it (more evidence, a smaller reversible test, surfacing a hidden concern), and the actual outcome, including if the recommendation still wasn't adopted.

Structured elaboration

Use a simple frame to structure the story:

• Situation: what the recommendation was and who pushed back, and roughly what their stated objection was.
• Task: what needed to happen next given that pushback.
• Action: the concrete steps you took, for example diagnosing the real underlying concern, bringing a smaller or lower-risk test instead of re-presenting the same evidence louder, or looping in someone the stakeholder trusts.
• Result: what actually happened, plus what you'd do differently, even if the honest answer is that they still said no.

Worked example

Example (illustrative, adapt to your own experience): a category manager dismissed a recommendation to shift ad spend away from a channel, saying "that channel builds our brand, the model doesn't capture that." Instead of re-presenting the same chart, the analyst asked what evidence would actually change the manager's mind, proposed a two-week holdout in a single region as a low-risk test, and came back with a direct regional comparison. The manager agreed to a partial reallocation for one quarter rather than the full change.

If you haven't faced this in a professional analytics role, use a project or coursework example where someone disagreed with a data-based conclusion, and focus the story on how you diagnosed why they disagreed rather than on the size of the business outcome.

Trade-offs and pitfalls

Avoid a story where the stakeholder is a strawman who simply came around, interviewers discount that. Also avoid defaulting to "let's run a pilot" for every disagreement, sometimes speed matters more than certainty and the right move is a smaller concession, not a new experiment.

What the interviewer probes next

Expect a follow-up on what you'd do if the additional evidence still hadn't changed their mind, or a question turned around to ask about a time the stakeholder's pushback turned out to be right.

Direct answer
In a setting like this, where human-reviewed labels are scarce but unlabeled posts are abundant, semi-supervised learning trains a model using that large unlabeled pool alongside the small labeled set, aiming to get better performance than a purely supervised model trained on the labeled data alone. It's the practical middle ground for exactly this situation: labels are expensive or slow to collect, but raw, unlabeled data is comparatively free.

Structured elaboration
Two concrete techniques worth applying here:

• Self-training (pseudo-labeling): train an initial model on the small labeled set, use it to predict labels for the unlabeled data, keep the predictions the model is most confident about as if they were true labels, add them to the training set, and retrain. This is simple to implement but risks the model reinforcing its own mistakes if the initial model is weak.
• Label propagation: build a graph connecting similar examples (labeled and unlabeled) based on some similarity measure, and let known labels "spread" across the graph to nearby unlabeled points. This leans on the assumption that similar examples tend to share a label.
• Consistency-regularization: encourage the model to produce the same prediction for an unlabeled example even when it's slightly perturbed (through small input transformations or noise), which pushes the model toward smoother, more robust decision boundaries using the unlabeled data, without ever needing a label for it.

Worked example
Concretely, suppose the platform has ten thousand human-reviewed posts and several million unlabeled ones flowing in daily. Training purely supervised on just the ten thousand labeled posts likely leaves the model missing patterns that show up more often in the much larger unlabeled pool. A self-training approach would use the initial supervised model to label the unlabeled posts it's most confident about, fold those into the training set, and retrain, effectively letting the model pick up patterns from the larger pool that the small labeled set didn't happen to cover.

Trade-offs and pitfalls
The main risk with self-training in particular is confirmation bias: if the initial model has a systematic blind spot (say, it's especially unreliable on a particular kind of post), pseudo-labeling will confidently generate wrong labels in exactly that blind spot, and retraining on those wrong labels reinforces rather than corrects the mistake, sometimes making the model worse in that area over successive rounds. A few mitigations help: start from a reasonably strong initial model rather than a weak one, only keep pseudo-labels above a fairly high confidence threshold rather than all of them, monitor performance on a held-out labeled validation set across rounds and stop if it degrades, and periodically spot-check a sample of the pseudo-labels a human would actually agree with.

Ways to split the work

• Data parallelism. Each GPU holds a full copy of the model and processes different batches. It is simplest, but the model must fit on one GPU.
• Tensor parallelism. Each layer is split across GPUs. This helps when the layers themselves are too large, but it adds communication every layer.
• Pipeline parallelism. Different layers live on different GPUs. This reduces memory pressure, but can leave devices idle if the pipeline is not balanced.
• Sharded optimizers or fully sharded data parallelism. These split parameters, gradients, and optimizer state to reduce memory use while keeping the training code closer to data parallelism.

How I would choose
If the model is only slightly too big for one GPU, I would prefer sharded data parallelism because it is usually the easiest path. If individual matrix multiplies are the memory or compute problem, tensor parallelism may fit better. If the model is very deep and activations dominate, pipeline or hybrid parallelism can help.

Worked example
For an 8 GPU cluster and a model that almost fits on one device, I would first try sharding plus data parallelism before moving to a more complex hybrid design.

The tradeoff is always simplicity versus communication cost versus memory savings.