As a Data Scientist at Grubhub, you play a pivotal role in transforming vast amounts of data into actionable insights that drive business decisions and enhance user experience. This position is essential for leveraging data to inform product development, optimize delivery logistics, and enhance customer satisfaction. You'll be working with a diverse set of data sources, including customer behavior analytics, operational metrics, and market trends, to inform strategies that impact millions of users and restaurants.
In your role, you will collaborate closely with engineering, product management, and marketing teams to extract meaningful insights and recommendations. You will tackle complex problems, such as predicting order volumes, improving delivery times, and personalizing user experiences, ensuring that Grubhub remains a leader in the competitive food delivery landscape. The responsibilities you will undertake are not only technically challenging but also strategically significant, making your work critical to the company's success and growth.
Initial Screening
reportedData Scientist covers at least four different jobs: experimentation, product analytics, causal work on observational data, and applied modelling that ships into a system. A screening call is the cheapest place to find out which of them is being hired for, and doing that diagnosis openly reads as senior rather than fussy. Ask what the last few pieces of work on the team actually were, and roughly how a week splits between querying, modelling and stakeholder time. Then say which parts of that you have done and which you have not. Claiming the whole range is the fastest way to be caught one round later.
What to demonstrate
- Whether you can distinguish the flavours of the role and locate your own experience inside one of them honestly
- Whether you name what you have not done instead of stretching to cover every line of the posting
- Whether your hard constraints (notice period, location, work authorisation, level) surface now rather than at offer stage
How to prepare
- Map the last two years of your time into rough percentages across query writing, experiment design, modelling and stakeholder work, so a question about scope has a real answer
- Mark every responsibility in the posting as done, adjacent or new, and prepare one sentence for each adjacent item naming the closest thing you have actually built
- Decide which logistics are non-negotiable before the call so you can state them in one sentence rather than negotiating live
Technical Interviews
reportedThis round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.
What to demonstrate
- Whether your row counts survive each join, and whether you notice on your own when they do not
- Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
- Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
- Reaching a defensible answer inside the window instead of a refined one after it
How to prepare
- Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
- Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
- Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither
Behavioral Assessments
reportedRounds of this kind usually include one question about work that did not go well, and it is the part that carries the most information. Anyone can narrate a shipped win. What the interviewer learns from a project that stalled is how you behave without a result to hide behind: whether you noticed the problem yourself, how long it took, and who you told. Answers that route the failure onto a data pipeline or a reorganisation close the topic without answering it, and the follow-up comes back to your own part.
What to demonstrate
- Whether you found the error yourself or someone else found it, and how long it sat before anyone knew
- What you changed afterwards, stated as a check you now run rather than a lesson you now believe
- Whether the mistake you choose has real cost attached, such as a quarter of misdirected roadmap or a metric that was reported upward, instead of one that flatters you
How to prepare
- Choose a failure you caught yourself and be ready to say what tipped you off. A story where someone else caught it is still usable, but you will be asked why you missed it.
- Write down the check you added afterwards and where it lives now, so the correction is a concrete artefact rather than a resolution.
- Rehearse saying the cost out loud. Candidates shrink the number by instinct once the interviewer is in the room.
Problem-Solving Evaluation
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
PracHub editorial advice for the preparation topics above.
Conditioning the analysis on completed orders
Wait-time distributions, price elasticities and rating models fit only on completed orders are conditioned on an outcome that the intervention itself changes. The requests that never matched, or that the consumer abandoned, are the population a liquidity fix targets, so excluding them biases every estimate toward the status quo and can flip the sign of a price elasticity. Any query starting FROM fct_order is already inside this trap; start from fct_request and left join.
Randomising individual consumers when supply is shared
A feature that makes treatment consumers book faster consumes the same idle providers the control consumers would have used, so the control group is degraded by the treatment and the measured lift overstates the market-level effect. The bias is largest precisely when supply is tight, which is when the feature is supposed to help, so the experiment is most misleading exactly where the decision matters. The fix is randomising the market or the time block (switchback) and clustering the variance at the randomisation unit, accepting far fewer effective units.
Reporting a p-value with no effect size or interval
Give the estimated difference with a confidence interval in the units the business cares about, then say whether that whole interval is worth acting on. A p-value only addresses whether you can rule out exactly zero; it says nothing about magnitude.
Never asking what decision the analysis will inform
Open with who makes the decision, what the options are, and by when. The answer determines the precision you need, the segments worth cutting, and whether an observational read suffices or an experiment is required.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Write a function to calculate the mean and standard deviation of a lis…
Write a function to calculate the mean and standard deviation of a list of numbers.
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Say what the estimate is of, and over what population it generalises.
- Write down the assumption the method needs before you use the method.
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?
Explain how gradient descent works and its application in machine lear…
Explain how gradient descent works and its application in machine learning.
Approach
- Check what information would not exist at prediction time, and exclude it.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- What would you monitor after launch to know the model is still valid?
- Where could label leakage enter this setup?
Discuss the time complexity of common sorting algorithms.
Discuss the time complexity of common sorting algorithms.
Approach
- Say how the offline result would be validated online before it is trusted.
- Set a baseline first, so any model has something honest to beat.
- Check what information would not exist at prediction time, and exclude it.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- What would you monitor after launch to know the model is still valid?
Implement SLA fill rate from its written definition
You are given requests (request_id, market_id, requested_at_utc, requested_at_local, matched_at_utc which is NaT when the request never matched, terminal_at_utc, request_status) and markets (market_id, timezone, sla_seconds). Implement fill_rate(requests, markets) returning the market-day SLA fill rate. Numerator: requests where matched_at_utc minus requested_at_utc is at most that market's sla_seconds. Denominator: all requests created in the window except those with request_status 'abandoned_pre_match' that terminated within 10 seconds of creation. Compute at market-hour grain first, then roll up to market-day. Return numerator and denominator counts alongside the rate.
Approach
- Merge sla_seconds onto requests by market_id first, so the SLA comparison is a vectorised column operation rather than a per-market branch.
- Bucket on requested_at_local, not requested_at_utc: a market-day is a local-calendar object, and a pandas datetime64 column can only carry one timezone, which is exactly why the local column exists in the source table.
- Build two integer columns on the full frame, eligible (1 minus the 10-second abandon exclusion) and matched_in_sla, instead of filtering rows away; the exclusion then stays auditable and both counts share one denominator.
- Aggregate with groupby([market_id, local_hour]).sum() on those two counts, then roll to market-day by summing the counts again and dividing once at the end.
- Return eligible and matched_in_sla next to the rate so a downstream consumer physically cannot re-average the rate across markets or hours.
Worked solution 25 min
- Merge markets onto requests (validate='m:1'), then derive time_to_match_seconds = (matched_at_utc - requested_at_utc).dt.total_seconds(), leaving NaN where matched_at_utc is NaT.
- Set excluded = (request_status == 'abandoned_pre_match') & ((terminal_at_utc - requested_at_utc).dt.total_seconds() < 10); set eligible = (~excluded).astype(int).
- Set matched_in_sla = (time_to_match_seconds.notna() & (time_to_match_seconds <= sla_seconds) & eligible.astype(bool)).astype(int).
- Group by market_id and requested_at_local.dt.floor('h'), summing eligible and matched_in_sla; this is the market-hour table.
- Roll to day by grouping the market-hour table on market_id and the local date, summing both counts, then dividing to get fill_rate.
Follow-up
- The 10-second exclusion removes 3% of requests in one market and 11% in another. What would you check before trusting either market's fill rate?
- A request can be re-offered after a provider declines. Does matched_at_utc still define your numerator, and what would you add to separate a dispatch problem from a supply problem?
Decompose one week of volume into request, fill and completion
fct_request has request_id, market_id, requested_at_utc, matched_at_utc, order_id (nullable), request_status. fct_order has order_id, request_id, order_status, started_at_utc, completed_at_utc, cancelled_by. For one ISO week and each market, return four counts: requests, matched requests, orders that started, orders that completed. Add fill rate (matched over requests) and completion rate (completed over matched). The query must start at the request grain and reach orders by LEFT JOIN so requests that never matched stay in the denominator. Also return post-match cancellations split by cancelled_by.
Approach
- Anchor FROM on fct_request filtered by requested_at_utc, then LEFT JOIN fct_order ON fct_order.request_id = fct_request.request_id. Starting from fct_order conditions the entire analysis on the outcome the funnel exists to explain.
- Confirm the join is one-to-one by comparing the row count before and after it. If fct_order ever carried two rows for one request, every count downstream inflates without any error.
- Compute all four counts as filtered aggregates in a single pass rather than four correlated subqueries, so every count is taken over one population and the rates are guaranteed to be consistent with each other.
- Express the rates as ratios of the summed counts and verify the identity completed/requests = fill rate times completion rate. That multiplicative structure is what makes a volume movement attributable to a specific stage.
- Split cancellations with COUNT(*) FILTER (WHERE order_status IN ('cancelled_pre_start','cancelled_post_start')) grouped by cancelled_by, because consumer, provider and system cancellations have different causes and different fixes.
Follow-up
- Completed orders fell four percent in one market while all three rates held steady. What moved, and what is the next cut?
- Fill rate rose and completion rate fell by similar amounts. How do you attribute the net change without double counting the cross term?
Seven-day signup-to-first-request conversion by weekly cohort
dim_user has user_id, side, signup_at_utc, signup_market_id, account_status. fct_request has request_id, consumer_id, requested_at_utc, market_id, client_platform. For each ISO signup week, return cohort size, the number of consumers whose first request falls within 168 hours of signup_at_utc, the conversion rate, and the share of those converters whose first request came from each client_platform. Consumers are the accounts with side IN ('consumer','both'). Report only cohort weeks whose 7-day window has closed for every member of the cohort.
Approach
- Rank each consumer's requests with ROW_NUMBER() OVER (PARTITION BY consumer_id ORDER BY requested_at_utc, request_id) and keep rn = 1. The request_id tiebreak makes the pick deterministic when two requests share a timestamp, which matters because the platform column is read off this row.
- MIN(requested_at_utc) would give the conversion count but not the platform of the first request. The ranked row carries the timestamp and the attributes together, which is the reason a window function earns its cost here rather than a group-by.
- LEFT JOIN the ranked first request onto the consumer cohort so non-converters remain in the denominator, then test requested_at_utc <= signup_at_utc + interval '168 hours'.
- Bucket with date_trunc('week', signup_at_utc) and keep only weeks where week_start + interval '14 days' <= now(). A week is not fully observed until the last member's 7-day window closes, which is 7 days after the week ends, not 7 days after it starts.
- Compute platform shares over converters only, and name the column so the denominator is unambiguous to whoever reads the output.
Worked solution 25 min
- Build the consumer cohort CTE with the side filter and count rows per signup week; this is the denominator.
- Build the ranked first-request CTE and assert it has exactly one row per consumer_id that has any request.
- LEFT JOIN, apply the 168-hour test, and aggregate to cohort week with COUNT() and COUNT() FILTER (...).
- Add the platform shares over converters and apply the cohort closure filter last so you can see how many weeks it removes.
Follow-up
- The conversion rate is flat overall while the acquisition_channel mix shifted hard toward paid_social. What do you report, and which decomposition do you show?
- A consumer signs up, requests nothing for 20 days, then requests. How does your metric treat them, and is a fixed 7-day window the right choice for this decision?
Given a dataset, how would you identify the key features that impact t…
Given a dataset, how would you identify the key features that impact the outcome?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- Fix the population and the time window before naming any metric.
- Decompose the metric into the rates that drive it, and say which one you would check first.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
Describe a complex data analysis project you worked on. What were the …
Describe a complex data analysis project you worked on. What were the challenges, and how did you overcome them?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- 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
- How would you detect that the metric is being gamed rather than genuinely improving?
- Which segment would you cut first, and what would that rule out?
How do you prioritize your work when handling multiple projects?
How do you prioritize your work when handling multiple projects?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- 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.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
What is the purpose of A/B testing, and how would you set it up?
What is the purpose of A/B testing, and how would you set it up?
Approach
- Name the guardrails that would stop a launch even on a positive primary result.
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Say whether units interfere with each other, and switch design if they do.
Follow-up
- How would you handle interference between treated and control units?
- What would you do if you could not randomise at all?
Can you describe the differences between supervised and unsupervised l…
Can you describe the differences between supervised and unsupervised learning?
Approach
- 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.
- State your assumptions explicitly before working the problem.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Price a provider incentive against contribution margin, not bookings
A market spent $40,000 in one week on provider bonuses in selected market-hour cells. Completed orders in treated cells rose 14%. Contribution margin per completed order in that market is $2.10. Define the metric that decides whether to repeat the spend, including how its denominator is produced rather than assumed. Then, given a randomised holdout that yields 9,000 incremental orders, state the cost per incremental order, say whether the spend pays back inside the week, and quantify exactly what future behaviour would be required for it to pay back at all.
Approach
- Reject the 14% as the input: orders in treated cells include volume displaced from adjacent hours and adjacent zones, where providers would have worked anyway. The denominator of any incremental metric has to come from untreated cells that share the same demand shock, randomised at the same granularity as the incentive, not from a before-and-after read on the treated cells.
- Define the decision metric: cost per incremental completed order = total incentive spend / (completed orders in treated cells minus the holdout estimate of what those cells would have done), with the holdout scaled by cell count and pre-period volume, and variance clustered at the randomisation unit because cells are the unit.
- Compute with the holdout number: 40,000 / 9,000 = $4.44 per incremental order against $2.10 of contribution margin, so the week loses 40,000 - 9,000 x 2.10 = $21,100. The spend is 2.1x the margin it buys.
- State the payback condition precisely instead of waving at lifetime value: each incremental order must be followed by about 1.12 additional margin-positive orders that would not otherwise have happened, since ($4.44 - $2.10) / $2.10 = 1.116, undiscounted and before any churn on the incentivised providers.
- Say what evidence would support that condition: a cohort read on the treated providers' completed orders in weeks two through six against the holdout providers, not a general retention curve, because the question is whether the incentive created a habit rather than whether providers retain in general.
- Close with the recommendation shape: do not repeat at this level; either cut the bonus to the level where cost per incremental order sits under margin, or move the spend to the cells where the holdout shows the incremental rate is highest, and re-measure, because targeting and increment are different things.
Worked solution 30 min
- Write the incremental metric with its counterfactual denominator, and state the randomisation unit as the same cell the incentive was applied to.
- Compute cost per incremental order: 40,000 / 9,000 = $4.44.
- Compute the week's net: 9,000 x 2.10 = $18,900 of margin against $40,000 of spend, a $21,100 loss.
- Compute the payback requirement: (4.44 - 2.10) / 2.10 = 1.12 additional margin-positive orders per incremental order.
- Name the cohort read that would test it and the horizon it needs.
- State the recommendation with the spend level at which the answer would flip.
Follow-up
- The market argues the bonus prevented provider churn that would have cost more. How would you test that claim?
- Cost per incremental order is $4.44 on average. What would you need to see to justify keeping the spend in one third of the cells?
- How does your answer change if the bonus is paid on online hours rather than on completed orders?
Contribution margin looks best in the least mature month
Contribution margin per completed order has risen for three consecutive months and is highest in the month that just closed. It is net take minus processing fees, refunds and chargebacks drawn from fct_money_movement, over completed fct_order rows, attributed to the order's completion month. Ledger rows carry order_id, entry_type, amount_cents (signed, positive into the platform), currency_code, fx_rate_to_usd, posted_at_utc, settled_at_utc and settlement_status. Explain the trend, correct it, and state what the corrected series shows.
Approach
- Check the join shape before reading any number. fct_order to fct_money_movement is one-to-many, so summing gross_booking_cents across the joined rows multiplies gross bookings by the number of ledger entries per order. Aggregate the ledger to order grain in a CTE first, then join one to one.
- Respect the ledger's conventions. Amounts are signed, so add them rather than subtracting absolute values; convert each row at its own fx_rate_to_usd before summing across currencies; and fix one explicit rule for 'pending', 'failed' and 'reversed' entries, applied identically in every month, since a failed charge is not collected revenue and a reversed one must not be counted as still collected.
- Measure the deduction lag instead of assuming it. Build a development table whose rows are completion months and whose columns are days since completion, holding cumulative refund plus chargeback dollars. Chargebacks in particular post on a long, right-skewed delay, so the newest month has absorbed only a fraction of its eventual deductions, and the exact fraction must be read from mature months rather than guessed.
- Restate the series on an ultimate basis. Either report only months that have reached a stated maturity, for example 95% developed, or scale each immature month's observed deductions by the inverse development factor and label those points as estimates on the chart.
- Re-read the trend after correction and say whether it survives. If the rise was development lag, the corrected series is flat or falling, and the correct recommendation is the reverse of the uncorrected one.
- Break the corrected margin into its drivers per completed order, net take, incentive intensity, refund rate and processing fee, so that whatever the corrected trend is can be explained rather than merely asserted.
Follow-up
- Your month-one development factor is averaged over nine prior months. What breaks it if the dispute policy changed six months ago?
- Finance closes on posted date and you are attributing to completion month. How do you present both without implying one is wrong?
For a candidate whose interviews will centre on A/B testing, metric movement and causal claims. Design comes before arithmetic, arithmetic before analysis, and the week ends by rehearsing the readout rather than the derivation.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Design one test end to end on paper
- Take a single feature change and write the full design: randomization unit, the exact point of exposure, the primary metric with its grain, guardrails, allocation, planned duration, and the decision rule committed before any data exists.
- Write why the randomization unit must sit at or above the level where treatment can spill over, and give one case where user-level randomization is still contaminated (shared accounts or devices, or two participants in the same marketplace).
- State in advance what you will do if the primary metric is flat while a secondary metric is significant.
Deliverable: A one-page test design with a decision rule written before launch.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Power arithmetic until it is automatic
- Compute required sample size per arm for a binary metric with the normal approximation, n is approximately 2 times (z for alpha/2 plus z for power) squared times p(1 minus p) divided by delta squared, for baselines of 2, 10 and 40 percent at a 5 percent relative lift, and note that for a fixed relative lift the requirement falls as the baseline rises because delta grows proportionally with p.
- Redo the calculation for a continuous metric using variance in place of p(1 minus p), and show why a heavy-tailed quantity such as revenue per user needs either far more traffic or a capped version with a stated cap.
- Convert one of the results into weeks given a weekly eligible traffic figure, then list the two honest ways to shorten it (accept a larger detectable effect, or reduce variance) and write why quietly lowering the power target is a decision to miss more real wins, not a speedup.
Deliverable: A small script or sheet that maps baseline, minimum detectable effect, alpha and power to sample size and weeks, cross-checked against a published calculator.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Variance and the unit-of-analysis problem
- Take a ratio metric whose denominator is not the randomization unit (clicks per session, randomized by user) and compute the standard error twice, once naively at session level and once by the delta method or a user-level bootstrap, then record how much the naive version understates it.
- Implement CUPED on simulated data: choose a pre-period covariate X measured before assignment, estimate theta as Cov(Y, X) divided by Var(X), and analyse Y minus theta times (X minus its mean) in place of Y. Confirm the variance of the adjusted outcome equals the raw variance multiplied by one minus the squared correlation between Y and X, so a correlation of 0.45 removes about 20 percent of the variance and not 80.
- Now run that simulation a few hundred times and confirm the adjusted effect estimate is unbiased for the same effect rather than numerically identical to the raw one. Within any single run the two differ, sometimes by a large fraction of the true effect, because the two arms' pre-period covariate means never coincide exactly in a finite sample; they agree in expectation, which is the property that matters and the one to state out loud.
Deliverable: A notebook showing the adjusted estimator with a measurably smaller variance than the raw one, plus a repeated-simulation table showing the two estimators agreeing on average while differing run by run.
Practice prompt ↗Practice prompt ↗04Validity threats you can actually test for
- Run a sample ratio mismatch check as a chi-square goodness-of-fit test against the intended allocation, and write the three causes you would chase first (assignment logged before exposure, an arm-specific redirect or load failure, bot filtering applied asymmetrically).
- Simulate peeking: generate A/A data, test daily at alpha 0.05 across 14 looks, record the inflated false positive rate, then apply an alpha-spending boundary or commit to a fixed horizon and confirm the rate returns to nominal.
- Write how you would separate a novelty effect from a durable lift using the treatment effect plotted against days since first exposure, and what shape would change your recommendation.
Deliverable: One table showing the peeking false positive rate before and after correction, plus a written SRM triage list.
Practice prompt ↗Practice prompt ↗Worked solution ↗05When randomization is not available
- Write the identifying assumption for difference-in-differences (parallel trends in the absence of treatment), then plot pre-period trends for two candidate control groups and justify rejecting one of them.
- Design a switchback test for a change where user-level randomization would leak across participants, choosing a time-block length against the carryover you expect and saying how you would detect carryover in the data.
- List what an interrupted time series or a synthetic control buys you and the one thing neither can rule out: an unobserved shock that coincides with the launch.
Deliverable: A one-page memo recommending a single quasi-experimental design and naming its weakest assumption explicitly.
Practice prompt ↗Practice prompt ↗06The readout query
- Write the assignment-to-exposure join that returns exactly one row per unit per experiment, and handle units appearing in both arms by excluding and counting them rather than silently keeping one.
- Compute the per-arm metric, its variance and the relative lift with a confidence interval in SQL, then reproduce the identical numbers in a notebook as a cross-check.
- Add a segment breakdown and write the sentence that keeps it from being p-hacking: segments declared in advance, everything else reported as exploratory and corrected for multiplicity.
Deliverable: A single query that outputs the full readout table, matched to a notebook recomputation.
Practice prompt ↗Practice prompt ↗07Present it to someone who will not read the appendix
- Give a 10-minute readout of a real or simulated experiment in the order decision, number, uncertainty, caveat.
- Have your listener ask "can we ship it" in the case where the primary is flat and a guardrail moved, and answer with a recommendation rather than a request for more data.
- Rewrite your opening line so the recommendation lands before any methodology.
Deliverable: A one-page readout whose first line is the recommendation.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Work that nobody used is a common and unflattering pattern in data careers, and interviewers probe for it. Have a story about an analysis that changed a decision, and be specific about how you got it in front of the person who could act. Also have one about work that went nowhere, with your reading of why.
Tell me about a time when you had to work collaboratively with a team.…
Tell me about a time when you had to work collaboratively with a team. What was your role, and what was the outcome?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Close with what you would do differently, concretely.
- Name the disagreement or constraint, and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that project again?
- How did you know the outcome was caused by your change?
Quantify your own impact without claiming the metric movement
At review you are asked what your work was worth this year. Your largest project was a dispatch change that shipped after your switchback read of +2.1 percentage points on SLA fill rate, 95% interval [0.9, 3.3]. Those markets run 250,000 requests a week at 88% fill, 93% completion. Over the following quarter, completed orders there rose 9%, about 239,000 orders, and six other launches shipped into the same window. You have the experiment readouts and the market-level series, and no budget for further study. Deliverable: the impact claim you make, the number attached to it, the evidence, and one project you score as zero or negative.
Approach
- Separate what you measured from what you observed: the switchback estimated a counterfactual contrast, while the 9% is an observed series containing seasonality, market mix, the other six launches and your change. Claim the first and say out loud that you are not claiming the second.
- Convert the experimental estimate into orders at the market base, and carry the interval through rather than reporting a point estimate that implies precision the design did not buy.
- Report the residual explicitly as unattributed rather than silently unclaimed; naming the gap is what makes the claimed portion credible.
- Score projects by decisions changed, not by metrics that happened to move afterwards, which is the only way work that correctly recommended shipping nothing scores above zero.
- Pick a genuine zero or negative with the real cause, and prefer a project where the technical work was sound but nobody used the output, since that is a scoping failure and naming it as such shows you can tell the two apart.
Follow-up
- How would you separate your change from the six other launches using only the data you already have?
- What would you have claimed if the switchback interval had included zero?
- Which of your projects had the highest value per week of your time, and is that the same as the one you led with?
Describe an analysis you got wrong after a decision shipped
Describe a number you published that turned out wrong, where someone had already made a decision on it. State the mechanism of the error rather than the feeling; how long it was live; who acted on it and what that cost; how it surfaced and whether you were the one who found it; and the control you put in afterwards. An error caught in review before anyone acted does not qualify for this question. Deliverable: three minutes, ending with the one process change that is still in place today.
Approach
- Choose an error with a real mechanism you can draw in one sentence, not a communication miss; the question is probing whether you understand how your own work fails, and a 'they misunderstood my chart' story answers a different question.
- State the blast radius honestly and numerically: days live, decisions taken, dollars or headcount moved. Vagueness here reads as an error you never actually measured.
- Say how it surfaced, including the unflattering version if someone else found it. Claiming self-detection on an error that a stakeholder caught is the fastest way to lose the room.
- Separate the mechanism from the conditions that let it survive: a wrong formula is one bug, but no reconciliation check and no second reader are the reasons it lived for weeks.
- End on a structural control, not an intention. 'I will be more careful' is not a control; a test that fails the job when two computations of the same metric disagree is.
Follow-up
- How soon after you knew did the decision-maker know, and who told them?
- Has the control you added caught anything since, and how would you know if it had silently stopped working?
- What class of error would that control still miss?
- 01
Tell me about a time when you had to work collaboratively with a team. What was your role, and what was the outcome?
- 02
At review you are asked what your work was worth this year. Your largest project was a dispatch change that shipped after your switchback read of +2.1 percentage points on SLA fill rate, 95% interval [0.9, 3.3]. Those markets run 250,000 requests a week at 88% fill, 93% completion. Over the following quarter, completed orders there rose 9%, about 239,000 orders, and six other launches shipped into the same window. You have the experiment readouts and the market-level series, and no budget for further study. Deliverable: the impact claim you make, the number attached to it, the evidence, and one project you score as zero or negative.
- 03
Describe a number you published that turned out wrong, where someone had already made a decision on it. State the mechanism of the error rather than the feeling; how long it was live; who acted on it and what that cost; how it surfaced and whether you were the one who found it; and the control you put in afterwards. An error caught in review before anyone acted does not qualify for this question. Deliverable: three minutes, ending with the one process change that is still in place today.
Is this an official Grubhub interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Grubhub. Rounds and questions reflect what candidates have reported, not a process Grubhub 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 for Data Scientists at Grubhub?
The interview process can be challenging, with a mix of technical and behavioral questions designed to assess both your skills and cultural fit. Candidates often report varying levels of difficulty depending on the interviewer's style.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates typically demonstrate strong technical expertise, effective problem-solving skills, and the ability to communicate complex ideas effectively. Showing alignment with Grubhub's values is also crucial.
PracHub interview research ↗What is the typical timeline from initial screen to offer?
The timeline can vary, but candidates usually receive feedback within a week of their final interview. It's essential to remain proactive in following up for updates.
PracHub interview research ↗What is the culture like at Grubhub?
Grubhub values collaboration, innovation, and a user-centric approach. The work environment encourages team engagement and open communication.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Turo Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Turo: a messy dataset, a fixed time budget, and a written analysis, reviewed for whether it states its assumptions and whether a reader could reproduce your numbers.
Rover Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Rover, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Prosper Marketplace Data Scientist Interview Questions & Guide 2026
Data-quality drills for Prosper Marketplace data scientist prep: survivorship and selection bias, leakage through time-ordered features, and extreme values where provenance decides the call. A logging fault or unit slip gets corrected or dr
Lyft Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for Lyft data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.