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.
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.
Application Review
reportedMost candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.
What to demonstrate
- Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
- Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
- The substance of the questions you ask back, which an experienced screener reads as a level signal
How to prepare
- Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
- Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
- Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered
Technical Assessments
reportedMuch 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
reportedThis 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
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
PracHub editorial advice for the preparation topics above.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
What is the bias-variance tradeoff?
What is the bias-variance tradeoff?
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 …
Write a function to calculate the correlation coefficient between two variables.
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…
Describe a project where you used machine learning to solve a business problem.
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
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.
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 dat…
How would you optimize a query that retrieves customer data from a database?
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.
Implement a simple recommendation system for restaurant suggestions.
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
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.
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…
Describe how you would approach predicting customer dining preferences based on historical data.
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?
How do you prioritize tasks when working on multiple projects?
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 …
Given a dataset of restaurant reviews, how would you extract insights to improve customer satisfaction?
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 pl…
How would you design an A/B test for a new feature on the OpenTable platform?
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.
Explain the differences between supervised and unsupervised learning.
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
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.
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
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?
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.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Fix 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02One 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Only 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04One 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Your 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.
Practice prompt ↗Practice prompt ↗06The 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.
Practice prompt ↗Practice prompt ↗07Taper
- 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
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. H…
Tell me about a time you faced a significant challenge in a project. How did you overcome it?
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
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
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?
- 01
Tell me about a time you faced a significant challenge in a project. How did you overcome it?
- 02
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.
- 03
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.
Is this an official OpenTable interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at OpenTable. Rounds and questions reflect what candidates have reported, not a process OpenTable has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the interview process, and how much preparation time is typical?
The interview process is rigorous, and candidates often spend several weeks preparing. Focus on building a strong foundation in data science principles and practicing coding challenges.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates typically showcase a blend of technical expertise, problem-solving skills, and a strong alignment with OpenTable's values of collaboration and user focus.
PracHub interview research ↗What is the culture like at OpenTable?
OpenTable fosters a collaborative and innovative culture, emphasizing teamwork and a commitment to delivering exceptional user experiences.
PracHub interview research ↗What is the typical timeline from the initial screen to an offer?
The timeline can vary but typically spans 2-4 weeks from the initial screening to the final decision, depending on the availability of interviewers and candidates.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Booking.com Data Scientist Interview Questions & Guide 2026
A prep plan for Booking.com data scientist candidates built on spaced review: write a full answer before opening any solution, keep a running list of the assumptions you failed to state, and repeat every missed exercise three days later ins
The Travelers Companies Data Scientist Interview Questions & Guide 2026
A prep plan for The Travelers Companies data scientist candidates built on spaced review: write a full answer before opening any solution, keep a running list of the assumptions you failed to state, and repeat every missed exercise three da
United Airlines Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at United Airlines candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
Universal Orlando Resort Data Scientist Interview Questions & Guide 2026
Prepare for the data scientist interview at Universal Orlando Resort with original practice on experiment design, SQL, and metric reasoning, each exercise paired with a worked solution and the reasoning behind it.