Interview guides · Bumble

Bumble Data Scientist Interview Questions & Guide 2026

Bumble data scientist prep: probability, sampling distributions, and stating the assumption behind every test you run.

The 60-second brief

As a Data Scientist at Bumble, you will play a pivotal role in shaping the future of our dating and social networking platforms. Your work will directly impact user experiences, data-driven product development, and strategic business decisions. The insights you derive from complex data sets will guide product teams in enhancing user engagement, improving safety features, and optimizing algorithms that connect users in meaningful ways.

Learn the economics of the product category before the loop. Marketplaces, subscription products and ad-supported products turn on different core quantities (match rate and liquidity, retention and churn, fill rate and yield) and fail in different characteristic ways.

Focus areas

Judge ranking metrics under position bias and feedback loops
Aggregate impression logs without double-counting repeated deliveries
Trade engagement gains against negative feedback and prevalence

Overview

The role encompasses a diverse range of projects, from developing predictive models that enhance user interactions to analyzing data that informs marketing strategies. You will collaborate closely with cross-functional teams, including engineering and product management, to translate data findings into actionable insights. This position is not only critical for the success of Bumble but also offers the unique opportunity to influence how millions of users connect and communicate.

You can expect a dynamic environment where your analytical skills will be challenged and your contributions will be valued. The scale at which you will operate and the complexity of the problems you will solve make this role both challenging and exciting.

The Bumble interview process

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

Recruiter Screening

A screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.

What to demonstrate

Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
Whether timeline, location and compensation expectations make the rest of the loop worth scheduling

How to prepare

Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice

Technical Interviews

A handful of shapes account for most of what gets asked in this format: a ranking or deduplication inside groups, a running or rolling total, a period-over-period comparison, and a cohort tracked forward over time. Recognising the shape quickly is most of the speed here; deriving it from scratch while a clock runs is where the time goes. Know that a window function keeps every row while a GROUP BY collapses them, and know which one the question needs. If the exercise is in Python instead of SQL, the same shapes arrive as groupby with transform, shift and merge, and the same grain mistakes are available.

What to demonstrate

Whether you reach the right construct without a detour, such as ROW_NUMBER over a partition to deduplicate instead of a self-join against a MAX subquery
Whether you know what your window frame actually is, since adding ORDER BY inside OVER changes the default frame and silently changes a running total
Whether the thing runs. A near-miss that throws an error scores below a plainer query that returns the right rows.

How to prepare

Write each of the four shapes once from memory against a small schema and keep the working version somewhere you will reread it: dedupe with ROW_NUMBER, a running total, a month-over-month change with LAG, and a retention table
Compute one running total twice on data with tied timestamps, once on the default frame and once with ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and look at where the two disagree
If Python is on the table, rebuild the dedupe and the running total with groupby and cumsum, then assert the two implementations return identical rows

Final Evaluations

A loop is not scored one interview at a time. The people you meet compare notes afterwards, usually in a meeting you are not in, and the outcome turns on what each of them can say about you when asked. That rewards something other than survival: every room needs one specific thing worth repeating, and none of them can contradict another. The common way to lose is to tell the same project four times with different numbers in it, or to be uniformly fine in a way that leaves nobody with anything to argue for.

What to demonstrate

Whether your account of a project survives being told twice, with the same scale, the same metric definition and the same numbers each time
Whether each interviewer leaves with one concrete claim they could make on your behalf later, rather than an absence of complaints
Whether a question you already answered in an earlier room gets the same answer at the same depth, without visible impatience

How to prepare

Write a one-page fact sheet for your two or three main projects that fixes the numbers you will quote: rows of data, the metric as a single sentence, the effect you measured and how long the work took. Say them aloud from the sheet until they come out identical every time
For each kind of room you expect, decide the one sentence you want that interviewer repeating in a debrief, then check during the mock that you said it outright instead of implying it
Rehearse answering the same project question twice in one sitting, the second time as though you had not just answered it, because the thing that needs fixing is the flatness that creeps into a repeated story

Where candidates lose points

Randomising individual members when the treatment travels along the social graph

If treated members post, comment or share more, their followers see the extra content whether or not those followers are treated, so the control group is partly treated and the measured difference understates the true effect. For features that redistribute a fixed amount of attention, the leakage runs the other way and the effect is overstated. The size of the bias scales with how dense the neighbourhood is, so it is largest exactly among the connected members whose behaviour the feature was built for. The fix is randomising clusters of the graph (ego networks or communities found by balanced partitioning), clustering the variance at that unit, and accepting that effective sample size falls by roughly the average cluster size.

Treating the first week of a ranking experiment as the steady state

Ranking changes have a novelty response in which members engage with an unfamiliar feed simply because it is unfamiliar, and it typically decays over one to three weeks. The opposite error is also live: if the ranking model retrains on data generated under the experiment, the treatment arm's model improves during the test and the effect grows, which makes a short read pessimistic. Shared models also break arm independence, since one model trained on both arms' data carries treatment information into control. A credible read needs a burn-in period excluded from analysis, a look at the effect by week rather than pooled, and an explicit statement of whether the model was frozen for the duration.

Naming a model class before naming the deployment constraints

Set out the latency budget, the label delay, the retraining cadence, the interpretability requirement and the number of labelled examples, then pick the model that fits them. A boosted-tree answer to a problem where each decision must be explained to the affected user is a well-executed answer to the wrong question.

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.

Questions & practice

Can you explain the bias-variance tradeoff?

Medium · statistics and probability

Approach

Say what the estimate is of, and over what population it generalises.
Quantify uncertainty explicitly rather than reporting a point estimate alone.
Sanity-check the answer against a simple bound or a simulated case.

Follow-up

How would you explain this result to someone who does not know statistics?
Which assumption here is most likely to be violated in practice?

How would you implement a basic recommendation algorithm using collaborative filtering?

Medium · machine learning and modelling

Approach

Set a baseline first, so any model has something honest to beat.
Check what information would not exist at prediction time, and exclude it.
Frame the prediction: the label, the moment of prediction, and the action it triggers.

Follow-up

How would you choose the decision threshold, and who owns that choice?
Where could label leakage enter this setup?

Cluster bootstrap a ratio metric under graph randomisation

Hard · cluster bootstrap · delta method · interference

units has cluster_id, arm ('control' or 'treatment'), neg_feedback_events (int) and impressions (int), one row per member; members are nested in about 900 ego-network clusters, which were the randomisation unit. The metric is negative feedback per 1,000 impressions, a ratio of sums. Write a cluster bootstrap from scratch: resample clusters with replacement within arm, keeping the number of clusters per arm fixed, recompute each arm's ratio and the relative difference, 2,000 replicates, percentile interval. Also compute a cluster-level delta-method interval and a naive member-level bootstrap. Report all three widths.

Approach

Collapse to the randomisation unit before resampling anything. Sum neg_feedback_events and impressions to one row per (cluster_id, arm). Resampling has to happen over the units that were independently assigned, and members inside a cluster were not.
Resample cluster rows with replacement within arm, holding the per-arm cluster count fixed, then recompute R = 1000 * sum(numerator) / sum(denominator) per arm from the resampled clusters. Recomputing the ratio of sums inside each replicate is what propagates the correlation between numerator and denominator; averaging per-cluster ratios instead answers a different question and will not match the point estimate.
Take the relative lift R_t / R_c minus 1 per replicate and read the 2.5th and 97.5th percentiles off the 2,000 values. Percentile is adequate here; mention BCa as the refinement if the bootstrap distribution is visibly skewed.
Derive the delta-method interval at the cluster level as the analytic check. With n clusters contributing numerator y_i and denominator x_i, R = ybar / xbar and Var(R) is approximately (1 / (n * xbar^2)) * (var(y) - 2Rcov(y,x) + R^2*var(x)). Arms are independent, so variances add for the difference.
Run the naive member-level bootstrap only to show what it costs. Resampling members destroys the within-cluster correlation, so its interval is narrower by roughly the square root of the design effect 1 + (m - 1) * ICC, where m is the average cluster size. Quote that number as the price of the design.
Close with the decision: report the cluster interval, state the number of clusters rather than the number of members as the effective sample size, and say what minimum detectable effect that leaves.

Worked solution (40 min)

cl = units.groupby(['cluster_id','arm'], as_index=False)[['neg_feedback_events','impressions']].sum(); split into cl_t and cl_c
ratio = lambda d: 1000 * d.neg_feedback_events.sum() / d.impressions.sum(); point = ratio(cl_t) / ratio(cl_c) - 1
For b in range(2000): draw idx_t = rng.integers(0, len(cl_t), len(cl_t)) and idx_c likewise, recompute ratio on cl_t.iloc[idx_t] and cl_c.iloc[idx_c], store the relative lift
ci = np.percentile(reps, [2.5, 97.5])
Delta method per arm: n, xbar, ybar, then var_R = (var(y) - 2Rcov(y,x) + R2*var(x)) / (n * xbar2); combine arms for the difference and convert to relative scale
Repeat the bootstrap resampling member rows instead of cluster rows and compare the three interval widths

Expected result: A point estimate of the relative lift with three intervals: cluster bootstrap percentile, cluster delta method, and member-level bootstrap. The first two agree closely; the member-level interval is materially narrower, and the width ratio approximates the square root of the design effect.

Verify it yourself

The median of the 2,000 bootstrap replicates sits close to the point estimate; a large offset means the ratio is being recomputed wrongly inside the loop.
Randomly reassign cluster_id to break the clustering, rerun, and confirm the cluster and member intervals then converge, which proves the gap came from within-cluster correlation and not from a coding difference.
The delta-method and cluster bootstrap half-widths agree within roughly 10 percent at 900 clusters; a large disagreement points at a skewed replicate distribution or a bug in one of the two.
Every replicate uses exactly the original number of clusters per arm, verified by asserting the resampled index length each time.

Follow-up

The cluster sizes are extremely uneven, with the largest cluster holding 4 percent of impressions. What does that do to the bootstrap and what would you change?
Derive the delta-method variance for the relative lift rather than the difference, and say when the two disagree.
You have 900 clusters and need to detect a 3 percent relative change. Is this test powered, and what would you trade to get there?

Can you explain the time complexity of your solution?

Medium · sql and data manipulation

Approach

Compute rates by summing numerator and denominator separately, never by averaging rates.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Check whether any join is one-to-many before aggregating, or the sums inflate.

Follow-up

What breaks if events arrive late or out of order?
How would you verify this result without re-running the same query?

Write a function to calculate the mean and median of a list of numbers.

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from it.
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?
What breaks if events arrive late or out of order?

Rebuild sessions from impression timestamps with a thirty-minute gap

Medium · gaps and islands · window functions · sessionisation · timezone

fct_feed_impression(impression_id, viewer_member_id, served_at_utc, dwell_ms, session_id) logs one row per rendered item. Ignore the logged session_id and rebuild sessions yourself: a new session begins when a viewer's gap since their previous impression exceeds 30 minutes. For each rebuilt session return viewer, start timestamp, end timestamp, impression count and total dwell seconds. Then count, per viewer-local calendar day derived from dim_member.tz_offset_minutes, how many rebuilt sessions carried at least 30 foreground seconds.

Approach

Order each viewer's impressions by served_at_utc and take LAG(served_at_utc). The gap to the previous row is the only input the boundary rule needs.
Turn the gap into a 0/1 boundary flag (1 when the previous row is NULL or the gap exceeds 30 minutes), then convert the flag into a session key with a running SUM over the same ordered window. The cumulative sum is constant inside an island and increments exactly at each boundary, which is what makes the islands groupable.
Group on (viewer, session key) for MIN and MAX served_at_utc, COUNT(*) and SUM(dwell_ms)/1000.0. Say explicitly that summed dwell is not wall-clock session length: items accrue dwell while being scrolled past, and the two numbers answer different questions.
Assign a session to a day by shifting the session start by tz_offset_minutes and taking the date of the result. A UTC boundary cuts an evening in half for large offsets, which depresses any per-day count by geography rather than by behaviour.
Apply the 30-second threshold after the session table is built, and keep that table materialised. The threshold is a convention someone will want moved, and rebuilding islands to change a constant is wasted work.

Worked solution (35 min)

WITH g AS (SELECT viewer_member_id, served_at_utc, dwell_ms, CASE WHEN LAG(served_at_utc) OVER w IS NULL OR served_at_utc - LAG(served_at_utc) OVER w > INTERVAL '30 minutes' THEN 1 ELSE 0 END AS is_start FROM fct_feed_impression WINDOW w AS (PARTITION BY viewer_member_id ORDER BY served_at_utc)).
WITH s AS (SELECT g.*, SUM(is_start) OVER (PARTITION BY viewer_member_id ORDER BY served_at_utc ROWS UNBOUNDED PRECEDING) AS session_key FROM g).
Aggregate per (viewer_member_id, session_key): MIN(served_at_utc) AS session_start, MAX(served_at_utc) AS session_end, COUNT(*) AS impressions, SUM(dwell_ms)/1000.0 AS dwell_seconds.
Join dim_member for tz_offset_minutes and compute local_day = CAST(session_start + tz_offset_minutes * INTERVAL '1 minute' AS DATE).
Filter dwell_seconds >= 30 and count sessions per local_day.

Expected result: A session table keyed by (viewer_member_id, session_key) whose row count is the number of rebuilt sessions, and a per-local-day count of sessions carrying at least 30 foreground seconds. Impressions summed across rebuilt sessions equals the input row count exactly.

Verify it yourself

SUM(impression_count) over the rebuilt sessions equals COUNT(*) of the source impressions, so no row was lost or duplicated.
Inside any rebuilt session, the largest gap between consecutive served_at_utc values is at most 30 minutes.
Between two consecutive sessions for the same viewer, the gap strictly exceeds 30 minutes.
Switching from UTC dates to local dates moves some sessions across the day boundary for members with non-zero offsets while leaving the total session count unchanged.

Follow-up

Your rebuild disagrees with the logged session_id on 3 percent of rows. How do you decide which one is right?
A member leaves the app in the background for two hours and returns. Does your rule split that correctly, and what extra signal would you need if not?
How does the 30-minute constant change impressions per engaged session, and how would you choose it rather than inherit it?

Given a dataset with user interactions, how would you determine which features are most important for predicting user engagement?

Medium · product sense and metrics

Approach

Restate the decision this analysis has to support, and who acts on the answer.
State what result would change your recommendation, so the answer is falsifiable.
Name one primary metric, then the guardrail that stops it being gamed.

Follow-up

How would you detect that the metric is being gamed rather than genuinely improving?
What would you do if the primary metric and the guardrail moved in opposite directions?

If you had to improve a recommendation system, what steps would you take?

Medium · product sense and metrics

Approach

Decompose the metric into the rates that drive it, and say which one you would check first.
Name one primary metric, then the guardrail that stops it being gamed.
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?
How would you detect that the metric is being gamed rather than genuinely improving?

How do you prioritize your tasks when working on multiple projects?

Medium · product sense and metrics

Approach

State what result would change your recommendation, so the answer is falsifiable.
Decompose the metric into the rates that drive it, and say which one you would check first.
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?
How would you detect that the metric is being gamed rather than genuinely improving?

How would you design an A/B test for a new feature on the app?

Medium · a/b testing and experimentation

Approach

Name the guardrails that would stop a launch even on a positive primary result.
Decide the analysis before seeing data, including how long it runs and when you look.
Say whether units interfere with each other, and switch design if they do.

Follow-up

What would you conclude if the result is positive but the test is underpowered?
What would you do if you could not randomise at all?

Explain the difference between supervised and unsupervised learning.

Medium

Approach

State your assumptions explicitly before working the problem.
Clarify what is being asked and what a complete answer would contain.
Say what you would check first and why it is the highest-information step.

Follow-up

How would you know your answer was wrong?
What assumption would you test first?

Define a qualified session you can defend twice

Easy · metric definition · sessionisation · north star

The north-star counts weekly members with at least one qualified session. You own the definition. Today it reads: a session with 30 or more foreground seconds and at least one non-negative engagement or authored item, derived from fct_feed_impression.session_id, fct_feed_impression.dwell_ms, fct_engagement_event.action_type with is_negative_feedback = FALSE, and fct_content_item.created_at_utc. Write the definition precisely, including how a session closes and how undone actions count. Then defend it against two objections: that the 30-second floor excludes a real use, and that the engagement requirement is satisfiable by a mis-tap. Deliverable: the definition plus both rebuttals.

Approach

Write the session boundary rule explicitly (inactivity gap, foreground only, how a background-to-foreground return is treated), because every rate in the tree is denominated in sessions and an unstated boundary makes the count a function of an SDK timeout nobody reviewed.
Enumerate the qualifying acts from fct_engagement_event and the authored path from fct_content_item, and rule that an action with undone_at_utc within 60 seconds of occurred_at_utc does not qualify. That closes the mis-tap objection with data already logged rather than a new instrument.
Answer the exclusion objection with evidence, not judgement: measure what fraction of sessions fall between 10 and 30 foreground seconds and what those members do the following week. Either accept the exclusion citing that number, or add a second qualifying path such as a completed deep-linked read, rather than lowering the floor globally.
State what the definition deliberately is not: not time spent and not any impression, so a stickier or longer feed cannot move it without a member acting.
Version the definition and pin it to a UI period, since moving the hide or like control changes the numerator with no change in member behaviour.

Worked solution (20 min)

Write the close rule: 30 minutes of foreground inactivity closes a session, a new foreground entry opens one, and a session is attributed to the viewer-local date of its first event using dim_member.tz_offset_minutes.
Write the qualifying-act set: any fct_engagement_event row in the session with is_negative_feedback = FALSE and (undone_at_utc IS NULL OR undone_at_utc > occurred_at_utc + 60 seconds), or any fct_content_item authored by that member inside the session window.
Run the sensitivity: recompute the weekly qualified-member count at foreground floors of 10, 30 and 60 seconds and record both the level and the week-over-week change under each.
Write the two rebuttals, one paragraph each, each citing the specific number from step 3 that supports it.

Expected result: A definition of at most six lines that a query can be written from with no follow-up question, plus a three-point sensitivity table showing the weekly member count moving with the floor while the week-over-week change stays materially stable across all three floors.

Verify it yourself

Every term in the definition maps to a named column; no word like meaningful or engaged survives unmapped.
The level moves with the floor but the week-over-week delta does not, which is the property that actually matters for a tracking metric.
A hand-built example of like-then-unlike within 60 seconds fails to qualify its session under your rule.

Follow-up

A platform team ships background prefetch that keeps the app foregrounded longer. Which part of your definition moves, and should it?
You are asked to make this comparable across iOS, Android and web. What breaks first, and do you fix the definition or report the platforms separately?

Weekly active members fell 1.8 percent: find the flow

Easy · dau decomposition · segment cuts · data completeness

Weekly members with at least one qualified session fell from 12.40M to 12.18M week over week, a 1.8 percent drop. You have dim_member, fct_feed_impression, fct_engagement_event and fct_content_item. The release log shows nothing shipped that week. Produce an ordered diagnostic checklist and run it far enough to name which flow moved: new, retained, reactivated or resurrected. Deliverable is a one-page readout stating the flow, the segment carrying most of the absolute member delta, and the residual you could not explain.

Approach

Confirm the number before explaining it. Check partition completeness for the last two event_date partitions in fct_feed_impression and fct_engagement_event against the trailing four-week median rows per hour, and check whether a metric-definition commit landed. A 1.8 percent move is well inside what one late or partial partition produces, and explaining an artefact is the most expensive failure mode here.
Rule out the calendar before the product. Confirm both weeks have identical weekday composition, no holiday in either, and compare the same week in prior years rather than only against last week, since this metric has a weekly and an annual shape.
Decompose into the four DAU flow classes (new, retained, reactivated, resurrected) for every day in both weeks and verify they sum exactly to DAU each day. Read which class moved: a fall in new is acquisition and cannot be a same-week product regression, a fall in retained is.
Cut the moved class by client_platform, app_version, country_code, tenure bucket and acquisition_channel, one dimension at a time, and rank the cuts by absolute member delta rather than percentage. A 20 percent drop inside a segment holding 1 percent of members cannot produce a 1.8 percent platform move.
Separate mix from rate: recompute the platform number holding the prior week's segment weights fixed. The difference between that and the actual move is the mix term, and it is a different product conversation from a within-segment decline.
Write the readout as flow plus segment plus residual, and name the single query that would close the residual instead of asserting a cause you have not isolated.

Follow-up

If the entire drop sits in the new class, how far back must the acquisition change have happened, and why is a same-week product explanation almost certainly wrong?
A qualified session needs 30 or more foreground seconds. How would you check whether a client timing change altered how strict that threshold effectively is?
What evidence would make you call this seasonal rather than a regression, and what would you tell the product owner in the meantime?

Suggested practice checklist

Roughly 90 minutes a night on weekdays with one longer weekend block. The plan deliberately cuts scope rather than compressing everything, on the assumption that finishing one thing a night beats half-starting four.

Day 1 — Fix the scope and set a baseline

Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list for everything else and keep it visible all week.
Take one 20-minute SQL prompt and one 10-minute metric question cold, and write the single sentence that says what blocked each attempt, since that sentence is what decides which two topics get the most evenings.
Set the week's one rule: one problem finished to completion every night, including the night you only have 40 minutes.

Deliverable: A one-page scope with an explicit not-doing list and two cold attempts, each carrying one sentence on what blocked it.

Day 2 — One query pattern, written three times

Choose the single pattern most likely to appear (a cohort retention grid, or a funnel counted by user) and write it three times from a blank file rather than editing the previous attempt.
On the third attempt, write the grain of every CTE as a comment before writing its body.
Stop at 90 minutes even if the third version is imperfect, and write the one thing you would fix with another hour.

Deliverable: Three independent versions of the same query plus a note on what changed between them.

Day 3 — Only the statistics you will be asked to defend

Write, in under 200 words, how you would decide whether a difference between two groups is real: the test, its assumptions, and what you would switch to when an assumption fails.
Compute a 95 percent confidence interval for a difference in proportions by hand on realistic numbers, then write in one sentence what changes if the two samples are paired rather than independent.
Write your answer to "what does a p-value mean", check it against a definition, and delete the version that describes it as the probability the hypothesis is true.

Deliverable: A 200-word written answer and one hand-computed interval you can reproduce under pressure.

Day 4 — One case, and the assumptions holding it up

Answer one product case aloud in 20 minutes with a recording running, then listen back with a pen and mark every claim you asserted without saying what it rested on: an assumed user behaviour, an assumed data source, an assumed baseline rate, an assumed grain.
Pick the three assumptions the recommendation actually depends on, write how you would check each one against data, and say which one being wrong would flip the recommendation rather than merely weaken it.
Write the four-step structure you used onto a card small enough to hold in working memory when you are nervous.

Deliverable: One recording, three load-bearing assumptions each with a written check, and a four-step structure card.

Day 5 — Your own work, timed

Write a 90-second version and a four-minute version of your main project, and time both out loud rather than reading them.
Prepare answers to the two follow-ups that always come: what you would do differently, and how you knew it worked.
Put one number in the first sentence and be able to say exactly where that number came from and what it excludes.

Deliverable: Two timed narratives with one defensible number in the opening line.

Day 6 — The one full rehearsal, in a longer weekend block

Run a 60-minute mock covering query work, a case and a behavioural question in a single sitting with no breaks, because sustained attention is the thing evenings have not trained.
Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.

Deliverable: Mock notes naming three failure moments with a specific fix written under each.

Day 7 — Taper

Write the 20-minute warm-up you will actually do on the morning of the interview: one query you can already write from a blank file, one metric you can define out loud, and nothing you have never seen before.
Re-read only your own notes from this week, and open no new material.
Write down the logistics: the tool you will be asked to work in, whether lookups are allowed, and the sentence you will use when you do not know something.

Deliverable: A one-page card holding the case structure, the project numbers, and the logistics.

What the behavioural round is actually scoring

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.

Tell me about a time you received constructive feedback. How did you respond?

Medium · behavioural and stakeholder questions

Approach

Pick a story where you drove the decision, not one where you observed it.
Name the disagreement or constraint, and how you resolved it with evidence.
Quantify the outcome, including what you would not claim credit for.

Follow-up

How did you know the outcome was caused by your change?
What did you decide not to do, and why?

Defend a qualified-session definition against two motivated objections

Hard · metric definition · gameability · north star

The north star is weekly members with at least one qualified session: 30 or more foreground seconds plus at least one non-negative engagement or authored item. A utility surface team argues the 30-second floor penalises fast successful visits. A video team argues requiring an explicit action undercounts passive watching. Both teams are reviewed on this metric. In fifteen minutes, defend or revise the definition, state what each proposed change does to gameability, and name the evidence that would justify a revision.

Approach

Split the two objections, because they attack different clauses and fail differently. The utility objection is about a threshold (30 seconds); the video objection is about the qualifying condition (an explicit action). Answering both with the same argument is the common tell that the definition was never understood.
Test each proposed change for gameability before discussing its merit. Dropping the action requirement makes the metric movable by autoplay, by longer video, and by any change that keeps an item in the viewport, which is precisely the failure the clause exists to prevent. A per-surface floor lets one team obtain a definitional lift without changing member outcomes, and makes the platform total a sum of incomparable parts.
Answer the video objection with evidence rather than principle, and say what evidence would move you: compare week-1 retention among members whose only qualifying signal was long dwell on video_short impressions against members whose qualifying signal was an explicit action. If a fitted dwell threshold predicts return at the same rate as a like, a dwell-based qualifier is defensible, fitted per media_type and re-fitted per period rather than inherited.
Answer the utility objection by separating the metric from the review. One definition platform-wide, with surface-level diagnostics beside it, and a review conversation that credits the utility surface on its own funnel rather than on a whole-platform north star it structurally cannot move. Forking the definition solves the review problem by destroying the metric.
Fix the change process in advance so revisions cannot be mistaken for wins: any new definition is dual-reported beside the old one for at least four weeks, the size of the definitional jump is published, and the team proposing the change does not own the analysis that evaluates it.

Follow-up

The utility team says they are graded on a number they cannot move. What do you actually offer them?
What evidence would make you drop the 30-second floor entirely, rather than adjust it?
Enforcement state changes after impressions are served. Does a session stay qualified when its only engagement was on content later removed?

Disagree with a product manager about push volume

Medium · causal reasoning · notifications · disagreement

A product manager proposes raising the daily push cap from 3 to 5, citing that members who open a push have 2.4 times the qualified-session rate of members who do not. You have fct_notification_decision with holdout_group in ('send','holdout_type','holdout_global') and 28-day incremental estimates by notification_type. The change is scheduled in a week. In ten minutes, write what you would put in the ticket: what the cited ratio measures, what number should decide this, and what version of the change you would support.

Approach

Name what the 2.4x measures in one line, without jargon: opening a push and starting a session are both produced by the same intent, so the ratio would look similar if the pushes had been replaced by silent no-ops delivered to the same members. It is a description of who opens things, not an effect.
Bring the replacement number in the same breath, because a disagreement without an alternative reads as obstruction: incremental qualified sessions per member, send arm minus holdout_global arm, 28 days, split by notification_type. Expect social_reciprocal and recommendation types to differ by a lot, which matters because a cap change does not raise them equally.
Attack the extrapolation, which is the actual flaw in the proposal. Even a positive increment at cap 3 says nothing about cap 5: frequency response is non-linear and, by construction, notifications 4 and 5 are the lowest-scoring ones the ranker had left. The quantity that decides this is the increment of the marginal notification, which only a cap experiment produces.
Price the cost the proposal leaves out, in measurable terms rather than as a worry: opt-out rate visible as suppression_reason = 'opt_out' growth, delivery permission loss visible in the delivered over sent ratio, both close to irreversible per member, and both slower than a 28-day session read.
Offer the version you would support so the disagreement resolves into a plan: a randomised cap ramp on a slice, opt-out and delivery-rate guardrails with a pre-registered stop rule, reads at week 4 and week 8, and agreement in advance on what increment justifies the permanent cap.

Follow-up

The PM says an eight-week ramp misses the quarter. What is the smallest experiment you would still sign?
Opt-out is rare. How do you get a usable read on it inside the ramp window?
The incremental estimate comes back positive but very small. What do you actually recommend?