Interview guides · OpenTable

OpenTable Data Scientist Interview Questions & Guide 2026

Data scientist prep for OpenTable candidates: drill A/B design, power and minimum detectable effect on original exercises.

The 60-second brief

As a Data Scientist at OpenTable, you are positioned at the forefront of a data-driven culture that significantly influences the dining and reservation experience for millions of users globally. Your role is vital in transforming complex datasets into actionable insights, which directly enhance product offerings, improve user satisfaction, and drive business growth. You will leverage analytical methods and machine learning techniques to solve real-world problems, such as optimizing reservation systems, personalizing user experiences, and forecasting trends in the dining industry.

SQL is seldom the hardest round and is often the one that eliminates people. The working bar is usually window functions, correct deduplication, and joins that do not silently fan out rows, rather than obscure syntax.

Focus areas

Judge cancellation cohorts only at equal maturity
Compute occupancy from sellable nights, never property averages
Cohort bookings on stay date, not booking date

Overview

The impact you generate extends beyond mere data analysis; you contribute to pivotal projects that enhance restaurant operations and customer engagement. Collaborating with cross-functional teams, including product managers and engineers, you will work on innovative solutions that shape how diners interact with the platform. This role is critical because it combines technical expertise with strategic thinking, allowing you to influence decisions that affect both user experience and company performance.

The OpenTable interview process

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

Application Review

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 to demonstrate

Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
The substance of the questions you ask back, which an experienced screener reads as a level signal

How to prepare

Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered

Technical Assessments

Much of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.

What to demonstrate

Whether the query you write matches the plan you just described
What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly

How to prepare

Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock

Behavioral Interviews

This round decides whether you owned a decision or watched one happen nearby. Interviewers for data roles listen for the point where the analysis stopped being a report and started changing what someone did, so build each story around that hinge: what was going to happen by default, what you found, and what happened instead. The most common weakness is a story that ends at delivery. If you can name the decision your work changed and the number that moved because of it, most follow-ups become easy.

What to demonstrate

Whether the decision was yours to influence, or whether you are narrating a team outcome in the first person
The counterfactual: what would have been done without your analysis, and why that default was worse
How far your involvement ran past the handoff, and whether you checked that the change did what you predicted

How to prepare

Pick three projects and write one sentence for each naming the decision-maker, the choice in front of them, and what they chose after seeing your work. If you cannot name a person and a choice, the story is not ready for this round.
Reconstruct the baseline for your strongest project from the original query or dashboard rather than memory, so the before-number survives a follow-up asking where it came from.
Prepare an honest version of a project where your recommendation was overruled, including what you did with the analysis afterwards.

Coding Exercise

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 to demonstrate

Whether an ambiguous term becomes a specific column and filter before any computation happens
Whether you read the schema for keys and cardinality rather than only for column names
Whether the result answers the question at the grain it was asked at, per user or per session or per day

How to prepare

Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over

Where candidates lose points

Reading cancellation, completion or repeat rates on cohorts that have not matured

A cohort of bookings made last week for stays six months out cannot have cancelled at the check-in gate yet, so its cancellation rate is mechanically near zero and its completion rate mechanically near zero as well, in opposite directions. Comparing that cohort with a mature one is not a noisy comparison, it is a guaranteed wrong one, and the bias always makes the recent period look different in a way that invites a false story about a recent change. Because lead time is heavily right-skewed, the mean lead time is a bad maturity threshold; use the cohort's 95th percentile, or report a hazard at a fixed age (cancelled within k days of booking) with k capped at the youngest cohort's elapsed age. The same applies to repeat rate, where the honest answer is often that the cohort in question is not readable for another nine months.

Running per-user experiments on shared, finite inventory

Independence between units fails when they compete for the same rooms on the same dates: a unit booked by a treatment user is removed from the control users' result sets, so the control arm is degraded by the treatment and the measured lift is inflated, sometimes to the point where a neutral change reads as a clear win. The effect is largest exactly where it matters most, in constrained markets and peak dates, and it is invisible in the usual diagnostics because both arms look balanced on pre-period covariates. Supplier-side treatments have the same problem in reverse, since a pricing or ranking change applied to some inventory changes the alternatives that every traveller sees. Randomise at the level that contains the competition, which is normally market-by-stay-week or a switchback on a market, and power the test on the number of clusters, not the number of users.

Averaging per-user rates to produce a population rate

Decide which quantity you want: the mean of per-user ratios and the ratio of summed numerator to summed denominator are different estimands, and heavy users dominate one but not the other. For a ratio metric, aggregate numerator and denominator separately and use the delta method for its variance.

Reading an observational correlation as a causal effect

Name the confounder you are most worried about and the design that would remove it: an experiment, a difference-in-differences with a checked pre-period trend, an instrument, or a regression discontinuity. When none is available, state which direction the bias likely runs and bound the claim accordingly.

Questions & practice

What is the bias-variance tradeoff?

Medium · statistics and probability

Approach

Translate the result into the decision it informs, in one plain sentence.
Write down the assumption the method needs before you use the method.
Sanity-check the answer against a simple bound or a simulated case.

Follow-up

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

Write a function to calculate the correlation coefficient between two variables.

Medium · statistics and probability

Approach

Sanity-check the answer against a simple bound or a simulated case.
Write down the assumption the method needs before you use the method.
Say what the estimate is of, and over what population it generalises.

Follow-up

Which assumption here is most likely to be violated in practice?
What sample size would you need to detect an effect half this size?

Describe a project where you used machine learning to solve a business problem.

Medium · machine learning and modelling

Approach

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

Follow-up

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

Decompose a blended ADR move into mix and rate

Hard · decomposition · mix effects · pandas · metric diagnosis

You have stayed-night data for two periods with destination_market_id, property_class, rate_plan, night count and unit_revenue_usd. Blended ADR fell 4.20 USD. Decompose that change into a within-segment rate component, a mix component and their interaction, so the three sum exactly to the blended delta. Segments exist in one period only, so an inner join is not acceptable. Return a per-segment table plus the three totals and the five segments with the largest absolute contribution. State the convention you use for a segment's missing base-period rate and what it does to the split.

Approach

Write the identity before any code. Blended ADR is sum over segments of r_i * w_i where r_i is segment ADR and w_i is the segment share of stayed nights. Then ADR1 - ADR0 = sum of (delta r * w0) + sum of (r0 * delta w) + sum of (delta r * delta w), and that expands algebraically back to r1w1 - r0w0, so it is exact rather than approximate.
Aggregate to the segment grain by re-summing revenue and night counts, then divide once. Averaging pre-computed per-night rates inside a segment reintroduces the same mean-of-ratios error the decomposition exists to expose.
Outer-join the two periods so entering and exiting segments survive as missing values, then handle them deliberately: for an entering segment w0 is 0, so its within term is zero for any choice of r0, and the total is unaffected. The r0 convention only moves value between the mix and interaction terms. Setting r0 to the period-0 blended ADR reads as 'a new segment is average until proven otherwise', which puts its deviation from average in the interaction term.
Assert the reconciliation to 1e-9 USD before reporting anything. If it fails, the cause is almost always a segment lost to an inner join or weights that do not sum to 1 within a period.
Rank segments by the absolute sum of their three terms and report the top five with the terms shown separately, because a segment can have a large mix term and a near-zero rate term, and only the second of those is a pricing decision anyone made.

Worked solution (40 min)

Aggregate each period to (destination_market_id, property_class, rate_plan): total revenue, total stayed nights; r = revenue/nights, w = nights/period total nights.
Outer-join period 0 and period 1 on the segment key; fill missing w with 0 and missing r with the corresponding period's blended ADR, recording which rows were filled.
Compute within = (r1 - r0) * w0, mix = r0 * (w1 - w0), interaction = (r1 - r0) * (w1 - w0).
Assert the three column sums add to blended ADR1 minus blended ADR0 within 1e-9, and that w0 and w1 each sum to 1.
Rank by abs(within + mix + interaction), return the top five with all three terms shown, and write one sentence naming which component carries the move.

Expected result: The three totals reconcile to the -4.20 USD blended delta to within 1e-9. A typical pattern for this shape of move is roughly -1.10 within segment, -3.30 mix and +0.20 interaction, supporting the statement that rates inside segments barely moved and the blended fall is a shift of stayed nights toward budget class and short lead times.

Verify it yourself

within + mix + interaction equals ADR1 - ADR0 exactly, to floating tolerance
Forcing w1 = w0 zeroes both the mix and interaction totals, leaving within equal to the whole delta
Forcing r1 = r0 zeroes both the within and interaction totals
Every entering segment has a within term of exactly 0, and changing the r0 convention leaves the reconciled total unchanged while moving value between mix and interaction

Follow-up

The mix term dominates. Name two operational causes that would produce exactly that pattern, and the query you would run to tell them apart.
Your comparison is the same ISO week a year apart. What breaks when a moving holiday falls inside one of them, and how do you align instead?
How would you present this so the decision-maker does not walk away believing prices were cut?

How would you optimize a query that retrieves customer data from a database?

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from it.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
State the window function and its partition and ordering out loud before writing it.

Follow-up

How does the query change if the join becomes one-to-many?
How would you verify this result without re-running the same query?

Implement a simple recommendation system for restaurant suggestions.

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from it.
State the window function and its partition and ordering out loud before writing it.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.

Follow-up

How would you verify this result without re-running the same query?
How does the query change if the join becomes one-to-many?

Rank market-weeks by qualified intents that never converted

Medium · anti-join · null-semantics · supply-gaps

Using the qualifying-intent definition over fct_search (trip_intent_key, searched_at_utc, destination_market_id, check_in_date, results_returned_count, is_bot_flagged) and fct_booking (trip_intent_key, booked_at_utc), produce a supply-acquisition list: the 20 (destination_market_id, ISO week of check_in_date) pairs with the most qualifying intents that never converted within seven days of their first search. Note that fct_booking.trip_intent_key is NULL for deep-link, offline and partner-channel bookings. Return market, check-in week, non-converting intents and total intents.

Approach

Reuse the qualifying-intent set: non-bot, results_returned_count > 0, collapsed to one row per trip_intent_key carrying its first search timestamp and the check_in_date from that first search.
Write the anti-join as NOT EXISTS, correlated on trip_intent_key with the seven-day window inside the subquery. NOT EXISTS is NULL-safe and lets the planner choose an anti-join.
If you insist on NOT IN, add WHERE trip_intent_key IS NOT NULL to the inner query. Without it, one NULL in the subquery makes the predicate UNKNOWN for every outer row and the result set is empty.
Group by destination_market_id and DATE_TRUNC('week', check_in_date), counting both non-converting and total intents so the reader sees volume and share together.
Order by non-converting intents descending and limit to 20. Ordering by share alone promotes market-weeks with five intents and one miss.

Worked solution (25 min)

Run the inner subquery alone and count its NULLs; that count is the reason the NOT IN form fails and is worth stating out loud before fixing it.
Build the qualifying-intent CTE and record its row count as the control total for the rest of the query.
Write the NOT EXISTS anti-join and confirm that non-converting plus converting equals the control total exactly.
Aggregate to market-week, order by volume, and limit.

Expected result: Twenty rows of (destination_market_id, check_in_week, non_converting_intents, total_intents); the NOT IN variant of the same query returns exactly zero rows, which is the diagnostic worth demonstrating.

Verify it yourself

non_converting_intents plus converting_intents equals the total qualifying intents for the same window.
No row has non_converting_intents greater than total_intents.
Rewriting the anti-join as LEFT JOIN with an IS NULL test gives identical counts; if it does not, the seven-day predicate has drifted into the WHERE clause and turned the LEFT JOIN into an inner join.

Follow-up

Which of these market-weeks are a supply shortage and which are a restriction or price problem? Which column separates them, and what join do you need?
You run the query and get zero rows. Walk me through how you find out why, without changing the query at random.
How would you exclude intents that did convert under a different trip_intent_key, such as the same traveller shifting their dates by a week?

Describe how you would approach predicting customer dining preferences based on historical data.

Medium · product sense and metrics

Approach

Fix the population and the time window before naming any metric.
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

What would you do if the primary metric and the guardrail moved in opposite directions?
Which segment would you cut first, and what would that rule out?

How do you prioritize tasks when working on multiple projects?

Medium · product sense and metrics

Approach

Restate the decision this analysis has to support, and who acts on the answer.
Fix the population and the time window before naming any metric.
State what result would change your recommendation, so the answer is falsifiable.

Follow-up

What would you do if the primary metric and the guardrail moved in opposite directions?
Which segment would you cut first, and what would that rule out?

Given a dataset of restaurant reviews, how would you extract insights to improve customer satisfaction?

Medium · product sense and metrics

Approach

State what result would change your recommendation, so the answer is falsifiable.
Fix the population and the time window before naming any metric.
Restate the decision this analysis has to support, and who acts on the answer.

Follow-up

What would you do if the primary metric and the guardrail moved in opposite directions?
Which segment would you cut first, and what would that rule out?

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

Medium · a/b testing and experimentation

Approach

Decide the analysis before seeing data, including how long it runs and when you look.
Name the randomisation unit first; it decides the variance and what the test can detect.
State the primary metric and the minimum effect worth shipping, then size the test.

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 differences between supervised and unsupervised learning.

Medium

Approach

Work from the decision backwards to the evidence you would need.
State your assumptions explicitly before working the problem.
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?

Cut variance with CUPED and stratification on a seasonal outcome

Medium · cuped · variance-reduction · stratification

A 14-day test on completed stay-nights per exposed traveller is under-powered: the outcome is zero for 91% of travellers and heavy-tailed above that. You have 8 weeks of pre-period history. Pre-period completed stay-nights correlate with the in-test outcome at rho = 0.45, but only 38% of exposed travellers existed before the test started. Write the CUPED estimator, give the variance reduction it buys on paper and the reduction you will actually realise, say how you treat the 62% with no history, and name what you would stratify on.

Approach

Write the estimator: Y_adj = Y - theta * (X - Xbar) with theta = Cov(Y, X) / Var(X) estimated pooled across arms, and the treatment effect taken as the difference in mean Y_adj. Because X is measured before assignment, using both arms to estimate theta does not bias the contrast.
Give the variance identity Var(Y_adj) = Var(Y) * (1 - rho^2) and convert it into an MDE multiplier of sqrt(1 - rho^2), which is the number the sizing conversation actually needs.
Handle the coverage problem without changing the population. Set X to its group mean for travellers with no pre-period so their adjustment term is exactly zero; the estimator stays unbiased and they simply contribute no reduction. Dropping them would redefine the test population as returning travellers only.
Re-state the realised reduction over the full population rather than the headline one: if the two groups have comparable outcome variance, the reduction is roughly the covered share times rho^2, which is a much smaller number than the paper figure and is the one to put in the plan.
Stratify on pre-assignment variables that predict the outcome: the has-history indicator itself, destination_market_id bucket, lead-time bucket, device_type and loyalty_tier. Use post-stratification with fixed population weights and keep strata coarse enough that every stratum holds both arms.
Guard the heavy tail with a winsorisation percentile chosen and written down before unblinding, and report capped and uncapped estimates side by side.

Worked solution (30 min)

Compute the paper reduction: rho^2 = 0.45^2 = 0.2025, so 20.25% of the variance, and an MDE multiplier of sqrt(0.7975) = 0.893, a 10.7% smaller MDE.
Compute the realised reduction: 0.38 * 0.2025 = 0.077 under equal within-group outcome variance, an MDE multiplier of sqrt(0.923) = 0.961, so 3.9% smaller.
Note the direction of the residual error: returning travellers usually carry the larger outcome variance, so 7.7% is a conservative floor rather than a point estimate.
Define the strata grid and confirm every cell has both arms and enough mass to estimate a within-stratum difference, collapsing sparse cells upward before unblinding.
Fix theta, the strata, the winsorisation percentile and the readout date in the plan document before the test starts.

Expected result: Y_adj = Y - theta(X - Xbar) with theta = Cov(Y,X)/Var(X); 20.25% variance reduction on the covered 38%, about 7.7% across the whole population, which is an MDE roughly 3.9% smaller. Travellers with no pre-period keep X at the group mean and are retained.

Verify it yourself

Run the estimator on a pre-period A/A: the CUPED point estimate must sit at zero like the unadjusted one while the variance falls. If the mean moves, theta is being estimated on post-treatment data.
Confirm rho was computed on the outcome exactly as the test defines it, same window and same maturity rule, not on a longer or more mature window.
Confirm the adjusted and unadjusted point estimates agree to well within one standard error; CUPED changes precision, not the estimate.

Follow-up

The outcome is completed stay-nights but the test ran 14 days and mean lead time is 38 days. What are you actually measuring, and what does that do to rho?
When does CUPED bias the estimate rather than only tighten it?
Would you rather spend the effort on CUPED or on switching the primary metric to a booking-axis proxy? Argue it.

Cancellation rate improved the week a status label changed

Medium · definition-change · cancellation · changepoint · reclassification

Traveller-initiated cancellation rate, defined as fct_booking rows with booking_status IN ('cancelled','no_show') AND cancellation_reason = 'traveller' over bookings created in the same lead-time bucket, fell from 22% to 17% in one week and has stayed there. A payments change shipped that week. You have fct_booking (booking_id, booked_at_utc, booking_status, cancelled_at_utc, cancellation_reason, lead_time_days, rate_plan, payment_timing). Determine whether traveller behaviour changed, and produce a series that is comparable across the changepoint. Use no table outside fct_booking.

Approach

Recompute the rate with the reason filter removed. If total cancellations per cohort are flat while the traveller-reason slice fell, no behaviour moved and rows were relabelled; that single comparison is worth more than any amount of segment hunting.
Plot the cancellation_reason distribution by week. A reclassification shows as one reason losing very close to what another gains, on one date, with no ramp, which is a shape genuine behaviour almost never produces.
Locate the changepoint on cancelled_at_utc, not on booked_at_utc. A relabel applies to cancellations processed after the deploy, including cancellations of bookings made months earlier, so the booking-date view smears the step across many cohorts and hides it.
Establish whether the relabel was retroactive. If historical rows were rewritten in place, the original series no longer exists in this table, and the only honest statement is which history is reconstructed and which is original.
Hold cohort maturity fixed throughout. Compare hazard at a fixed age, the share cancelled within k days of booking with k no greater than the youngest cohort's elapsed age, so the post-change weeks are not simply younger than the pre-change ones.
Rebuild a comparable definition: publish the all-reason rate while the split is unreliable, or publish the new split forward with the changepoint annotated on every chart that crosses it.

Follow-up

Which definition do you publish going forward, and what do you do with the eight quarters of history behind it?
Payment-failure cancellations are now separable from traveller ones. What decision does that actually enable, and which team owns it?
How would you detect the next relabel automatically, without knowing in advance which column it lands in?

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.

Being wrong in public

A number you shipped turned out to be wrong, and someone had already acted on it. That is one of the most useful stories a data person can carry. What is being scored is how fast you noticed, who you told first, and what you changed in the process so the same class of error could not repeat quietly.

Tell me about a time you faced a significant challenge in a project. How did you overcome it?

Medium · behavioural and stakeholder questions

Approach

Name the disagreement or constraint, and how you resolved it with evidence.
Pick a story where you drove the decision, not one where you observed it.
Close with what you would do differently, concretely.

Follow-up

What would you do differently if you ran that project again?
How did you know the outcome was caused by your change?

Disagree with a product manager about the denominator

Medium · disagreement · look-to-book · demand unit

A product manager wants to ship a filter-refinement panel that lets travellers re-sort and narrow results more easily. Early data shows it increases searches per trip_intent_key from 6.2 to 9.4. The team's headline metric is bookings divided by fct_search rows, which falls from 4.1% to 2.9% under the change. The PM reads this as the feature hurting conversion and wants to kill it. You think the denominator is wrong. Prepare how you make that case in a working session without winning on a technicality.

Approach

Recompute the metric on the defensible denominator first and bring both numbers: DISTINCT trip_intent_key values with at least one booking within 7 days of the first search for that key, over DISTINCT keys with is_bot_flagged = FALSE and results_returned_count > 0. If intent-level conversion is flat or up while search-level conversion falls, the disagreement resolves itself in one table.
Explain the mechanism rather than the rule: searches per intent is a property of the interface, so any feature that encourages comparison inflates the denominator and any feature that discourages it improves the metric while demand is unchanged. That makes the current metric reward a worse product, which is an argument the PM has reason to care about.
Concede what the search count does tell you and keep it: report searches per intent as a separate diagnostic, since 6.2 to 9.4 may be healthy exploration or may be people failing to find anything, and those have opposite implications.
Distinguish the two hypotheses with evidence rather than assertion: compare results_returned_count and time-to-first-booking per intent between arms. Rising refinement with stable intent conversion and stable zero-result rate reads as exploration; rising refinement with a rising zero-result rate reads as failure to find.
Agree the decision rule with the PM before reading the result, so the metric change is not seen as moving the goalposts after the fact, and put intent-level conversion on the team's dashboard alongside the old number rather than replacing it silently.

Follow-up

Intent-level conversion is also down, by 0.3pp. Does your recommendation change?
The PM says changing the metric now looks like you are protecting a feature. How do you answer?
What would you need to see to agree the feature should be killed?

Retract an occupancy comparison after the decision shipped

Hard · error disclosure · occupancy denominators · accountability

Three weeks ago you published a market occupancy comparison that led to marketing spend being moved out of one market. Reviewing the query, you find the two markets used different denominators: sellable nights from fct_rate_availability_snapshot (units_sold_to_date + units_available) for one, and capacity_units from dim_supply_unit for the other. The second market is mostly individual_host supply with large units_blocked, so its occupancy was understated. The spend move is already live. Prepare the correction: who you tell, in what order, and what the note says.

Approach

Quantify the error before telling anyone, because the first question will be 'how wrong'. Recompute both markets on sellable nights, which excludes units_blocked, and report the corrected gap and its sign, not just that the original was wrong.
Separate the numerical error from the decision error. The comparison was invalid, but the spend move may still have been right; establishing whether the decision would have flipped is a different analysis and it is the one the business needs.
Tell the decision-maker directly and first, before it appears in a dashboard or a peer surfaces it. Order matters because being told by a third party converts a mistake into a credibility problem.
Write the note with the correction, the size, the decision implication, and the reversal cost in that order. Three weeks of moved spend has a real cost to undo, and a correction that does not price the reversal forces the reader to do the work you skipped.
Name the specific control that would have caught it and put it in place in the same note: an assertion in the query that both arms use the same denominator expression, and the denominator named in the chart title. A retraction without a mechanism reads as an apology rather than a fix.

Follow-up

The corrected numbers still support the original decision. Do you still send the note, and does it read differently?
Your manager suggests quietly fixing the dashboard and not raising it. How do you respond?
What would you have had to do differently three weeks ago, in the query itself, rather than in your review habits?