As a Data Scientist at Starbucks, you do not just analyze numbers; you help shape the daily rituals of millions of customers worldwide. Operating at the intersection of retail, technology, and consumer behavior, the data science team is responsible for driving decisions that impact thousands of physical stores and a highly active digital ecosystem. From optimizing the Starbucks Rewards loyalty program to refining supply chain logistics, your work directly influences how the company delivers its signature experience.
This role requires a unique blend of technical expertise and business acumen. You will work on complex, large-scale datasets to solve challenges such as predictive inventory management, personalized marketing campaigns, and store labor optimization. Many of these initiatives feed directly into Deep Brew, the proprietary Starbucks artificial intelligence engine that powers personalized recommendations, drive-thru menu boards, and automated inventory tracking.
To succeed in this position, you must be comfortable navigating ambiguity and translating complex statistical findings into actionable business strategies. Whether you are building predictive models in or writing advanced queries to extract customer insights, your contributions will help maintain its competitive edge as a leader in both retail operations and digital innovation.
Online Technical Assessment
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
Technical Evaluation
reportedA handful of shapes account for most of what gets asked in this format: a ranking or deduplication inside groups, a running or rolling total, a period-over-period comparison, and a cohort tracked forward over time. Recognising the shape quickly is most of the speed here; deriving it from scratch while a clock runs is where the time goes. Know that a window function keeps every row while a GROUP BY collapses them, and know which one the question needs. If the exercise is in Python instead of SQL, the same shapes arrive as groupby with transform, shift and merge, and the same grain mistakes are available.
What to demonstrate
- Whether you reach the right construct without a detour, such as ROW_NUMBER over a partition to deduplicate instead of a self-join against a MAX subquery
- Whether you know what your window frame actually is, since adding ORDER BY inside OVER changes the default frame and silently changes a running total
- Whether the thing runs. A near-miss that throws an error scores below a plainer query that returns the right rows.
How to prepare
- Write each of the four shapes once from memory against a small schema and keep the working version somewhere you will reread it: dedupe with ROW_NUMBER, a running total, a month-over-month change with LAG, and a retention table
- Compute one running total twice on data with tied timestamps, once on the default frame and once with ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and look at where the two disagree
- If Python is on the table, rebuild the dedupe and the running total with groupby and cumsum, then assert the two implementations return identical rows
Behavioral Interviews
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.
Case-Focused Interviews
reportedAn extra round usually exists because something is still open after the standard loop: a skill the earlier interviews did not sample, a level decision, or two interviewers who disagreed. It is rarely a rerun of what you already did well. Ask the recruiter who you are meeting, what function they sit in, and how long the session runs. That is an ordinary scheduling question, and the answer changes what you should prepare. What separates a strong candidate here is treating the round as a fresh evaluation with its own bar, rather than assuming earlier performance carries you through or sinks you.
What to demonstrate
- Whether you can answer well on ground the earlier rounds did not cover, without leaning on what you already said to someone else
- Consistency of the facts in your stories: the same sample size, timeframe, team size and scope of your own role as in earlier conversations
- How you handle an unfamiliar format live, including whether you ask what kind of answer is wanted before producing one
How to prepare
- Ask the recruiter for the interviewer's function, the length, and whether to expect a coding surface, a discussion, or a presentation. Preparing for a 30 minute conversation with a partner team is not the same work as preparing for a 60 minute technical block.
- Write out what each earlier round actually covered, then list the two or three areas nobody probed. That gap is the most likely subject of the extra round.
- Re-read the numbers in the project stories you have already told, so a second telling does not quietly contradict the first.
PracHub editorial advice for the preparation topics above.
Judging merchandising and recommendation changes on the surface they touch
Click-through or attributed revenue on a recommendation slot rises whenever the slot shows items the customer was going to buy anyway, so the surface metric measures capture rather than creation, and the units almost always come from a different slot, a search result or a later visit. The correct read is site-wide net revenue per session over a holdout, adjusted for returns, because surfacing more apparel or more discounted stock reliably moves both the return rate and the discount depth in the wrong direction while the click metric improves.
Crediting promotions and channels by last click, especially coupon codes
A discount code handed to a partner or an influencer is claimed by customers who were already at checkout, so last-click attribution books organic demand as partner-driven, and the reported return on that spend is an artefact of the code's visibility at the basket rather than of any persuasion. The same mechanism makes email and paid search look strong because they sit close to a purchase that other activity created. Incremental effects need a holdout, a geo split or a switched-off period; where none is possible, at minimum report the share of code redemptions from customers whose session began before any partner touchpoint, because that number alone usually collapses the claim.
Accepting a metric definition without asking about the denominator
Pin down the denominator, the eligibility filter and the time window before computing anything: conversion rate per session, per user, per eligible user and per new user are four different numbers with different behaviour. Restate the definition in one sentence and get agreement before you analyse.
Reaching for a model before the target metric exists
Before naming an algorithm, write down the label, the prediction time, and the action that changes when the score crosses a threshold. If you cannot say what decision the output drives, any modelling choice is guesswork dressed up as method.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Walk us through how you would build a recommendation system for season…
Walk us through how you would build a recommendation system for seasonal beverages.
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Translate the result into the decision it informs, in one plain sentence.
- Say what the estimate is of, and over what population it generalises.
Follow-up
- What sample size would you need to detect an effect half this size?
- How would you explain this result to someone who does not know statistics?
What is the difference between L1 and L2 regularization, and when woul…
What is the difference between L1 and L2 regularization, and when would you use each in a predictive model?
Approach
- Check what information would not exist at prediction time, and exclude it.
- Say how the offline result would be validated online before it is trusted.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- What would you monitor after launch to know the model is still valid?
- How would you choose the decision threshold, and who owns that choice?
How do you assess and handle multicollinearity in a multiple linear re…
How do you assess and handle multicollinearity in a multiple linear regression model?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- 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
- How would you choose the decision threshold, and who owns that choice?
- Where could label leakage enter this setup?
Net revenue per order without fanning out return rows
You get two DataFrames. order_lines has order_line_id, order_id, customer_id, quantity, unit_paid_price_cents, line_status, delivered_at_utc. return_lines has return_line_id, order_line_id, quantity_returned, refund_amount_cents, initiated_at_utc. One order line can have several return rows. Produce one row per order_id with gross_cents over delivered lines only, refund_cents from returns initiated within 90 days of that line's delivery, net_cents, and units_kept. The output must have exactly one row per order_id, and gross_cents must equal a total you compute without ever touching return_lines.
Approach
- Filter order_lines to line_status == 'delivered' first, and compute gross_cents = quantity * unit_paid_price_cents per line. Keep that per-line frame as the control total before any merge.
- Aggregate return_lines to one row per order_line_id with groupby('order_line_id').agg(sum of quantity_returned, sum of refund_amount_cents, min of initiated_at_utc) so the right side of the join is unique on the join key.
- Because the 90-day window is per return row, not per order line, apply the window before aggregating: join initiated_at_utc against the parent line's delivered_at_utc, keep rows inside the window, then aggregate. Doing it after aggregation loses the individual initiation dates.
- Left merge the aggregated returns onto the delivered lines with validate='m:1' so pandas raises instead of silently duplicating, then fillna(0) on the refund and quantity columns.
- Group to order_id, sum gross_cents, refund_cents, and units_kept = quantity - quantity_returned, and assert the gross total equals the control total computed in step one.
Worked solution 25 min
- Build a fixture where order 1 has one line of quantity 3 at 2000 cents with two return rows (1 unit refunded 2000, then 1 unit refunded 2000), and order 2 has one clean delivered line of quantity 1 at 5000 cents.
- Compute control_gross = 32000 + 15000 = 11000 from order_lines alone.
- Run the naive merge first and print the gross sum: it reports 17000, because the three-unit line appears twice.
- Run the pre-aggregated version and confirm total gross 11000, total refund 4000, total net 7000, and for order 1 specifically gross 6000, refund 4000, units_kept 1.
- Add an assertion that result.index.is_unique and result['gross_cents'].sum() == control_gross.
Follow-up
- The order line was paid in a non-USD currency with fx_rate_to_usd on the line. Where does the conversion belong, and what breaks if you convert after aggregating to order grain?
- Refunds arrive weeks after the order. Which date do you attribute refund_cents to when you report a monthly net revenue series, and why does the answer change how long you must hold the report back?
- How would the query change if a partial return could be refunded in two instalments under the same rma_id?
Write a SQL query to find the monthly active users on the Starbucks Re…
Write a SQL query to find the monthly active users on the Starbucks Rewards app who made purchases in consecutive months.
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- How would you verify this result without re-running the same query?
- How does the query change if the join becomes one-to-many?
Walk through a predictive modeling workflow you have built in Python, …
Walk through a predictive modeling workflow you have built in Python, explaining your choice of libraries and validation techniques.
Approach
- State the window function and its partition and ordering out loud before writing it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which table is the grain you start from, and join outward from it.
Follow-up
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
Explain how you would optimize a slow-running SQL join on a dataset co…
Explain how you would optimize a slow-running SQL join on a dataset containing billions of transaction records.
Approach
- 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.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
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?
How would you implement a rolling average of customer wait times using…
How would you implement a rolling average of customer wait times using window functions?
Approach
- State the window function and its partition and ordering out loud before writing it.
- Say which table is the grain you start from, and join outward from it.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
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?
Reconcile converting sessions against order lines with a null-safe anti-join
fct_session records order_id for the order placed inside a session; fct_order_line carries session_id, which is NULL for store, call centre and denied-consent orders. For last week, list sessions with is_bot_flagged = FALSE and order_id IS NOT NULL that have no row in fct_order_line with the matching session_id, and count them by entry_channel, device_type and tracking_consent. Use fct_session (session_id, started_at_utc, ended_at_utc, entry_channel, device_type, order_id, tracking_consent, is_bot_flagged) and fct_order_line (order_line_id, order_id, session_id, placed_at_utc).
Approach
- Before writing the join, count NULLs in the probe key: SELECT COUNT(*) FROM fct_order_line WHERE session_id IS NULL. That single number decides which anti-join forms are safe.
- Write the anti-join as NOT EXISTS correlated on session_id, or as a LEFT JOIN with WHERE ol.session_id IS NULL. Both are unaffected by NULLs in the probe side; NOT IN is not.
- Bound the probe side by placed_at_utc over the same week plus a buffer, since an order can be placed minutes after the session row is closed and a tight window manufactures false orphans.
- Group the survivors by tracking_consent first, because denied-consent orders are expected orphans by design and should be separated from genuine loss before anyone opens a ticket.
- Cross-check the residual against fct_session.order_id joined to fct_order_line.order_id: an orphan on session_id but a match on order_id is a tracking defect, not a missing order.
Worked solution 15 min
- Run the NULL count on fct_order_line.session_id and record it.
- Write the NOT IN version, observe zero rows, then write the NOT EXISTS version and observe the real set.
- Add WHERE session_id IS NOT NULL to the NOT IN subquery and confirm it now agrees with NOT EXISTS.
- Group the NOT EXISTS result by tracking_consent, entry_channel and device_type.
Follow-up
- Should denied-consent sessions be in this reconciliation at all, given they can never join, and what do you report instead for them?
- The orphan count triples on one device_type overnight. What are the two or three hypotheses you test first?
How would you design an experiment to test the effectiveness of a new …
How would you design an experiment to test the effectiveness of a new promotional offer on the mobile app?
Approach
- Say whether units interfere with each other, and switch design if they do.
- State the primary metric and the minimum effect worth shipping, then size the test.
- Name the guardrails that would stop a launch even on a positive primary result.
Follow-up
- What would you do if you could not randomise at all?
- What would you conclude if the result is positive but the test is underpowered?
Pick the decision metric for a recommendation carousel test
A product-page recommendation carousel is being replaced. The current readout is carousel click-through rate and revenue attributed to items clicked in the carousel; a previous change raised both by roughly a third and shipped. You have fct_session, fct_order_line, fct_return_line and dim_sku, and you can randomise sessions. Deliverable: name the primary metric you would decide on, two guardrails, and explain in one paragraph what attributed carousel revenue measures that is not value created.
Approach
- State the failure mode precisely. Attributed revenue measures capture, not creation: a carousel that shows the item a customer was already going to buy raises click-through and attributed revenue while site-wide revenue is unchanged, because the units moved off search, off another slot, or off a later visit.
- Put the primary at a surface that cannot be cannibalised from: net merchandise revenue per randomised session, site-wide, in constant currency, with refunds attributed back to the parent order's placed date so both arms sit on the same definition.
- Choose guardrails that catch the two ways revenue per session can rise while the business is worse off. Contribution margin per delivered order catches a carousel that surfaces clearance and discounted stock. Net unit return rate, split by reason class, catches one that surfaces fit-sensitive categories where a third of units come back.
- Set the read date from the return window, not from significance. Hold the revenue decision until the 95th-percentile return-initiation lag for the categories involved has elapsed, and pre-register the cap for revenue per session, since that metric is heavily skewed and an uncapped mean is driven by a handful of baskets.
- Keep attributed carousel revenue as a diagnostic and always report it next to the change in revenue from other surfaces in the same arm. That pairing makes cannibalisation visible instead of assumed away.
Worked solution 30 min
- Define the randomisation unit and the triggered population: sessions reaching a product page, noting that restricting to the triggered set raises power but narrows what the result generalises to.
- Compute net merchandise revenue per session by arm, refund-adjusted to the order's placed date, with a pre-declared cap on the per-session value.
- Compute contribution margin per delivered order by arm using unit_cost_cents, shipping_cost_cents, return_shipping_cost_cents and recovered_value_cents, and net unit return rate split into defect/damage, fit/description and remorse.
- Split revenue in each arm by originating surface and compare the carousel delta against the delta on search and other slots.
- Check sample ratio mismatch and confirm both arms have the same consent mix before reading anything.
Follow-up
- The test reads net revenue per session flat and contribution margin per order down four percent. What do you recommend, and what would change your mind?
- How would you detect that the new carousel pushed demand onto a scarce SKU and starved the control arm of inventory?
- What result would make you ship a revenue-neutral carousel anyway?
A published cohort number moved with no product change
The 90-day repeat rate for a first-delivery cohort published four weeks ago now reads 29%; the published snapshot says 22%. No product, pricing or lifecycle-email change landed in that window. You have the metric query in version control, the published snapshot table, and the underlying fct_order_line and fct_return_line. Deliverable: determine whether cohort membership changed, the metric definition changed, or the underlying data was restated, and say what you would do to the historical series before anyone reads a trend from it.
Approach
- Separate code from data with one experiment: run the version of the query that produced the published number against today's data, and run today's query against the same data. If old code on new data reproduces 22%, the data is stable and the definition moved; if new code on old data reproduces 29%, same conclusion from the other side.
- Diff cohort membership as a count, not a rate. Cohort membership is fixed at first delivery, so the denominator should be immutable. If it moved, someone re-indexed the cohort on signup or on order placement, or started excluding customers whose first order was later cancelled or fully returned.
- Diff the numerator rule line by line: does a second order have to contain a delivered, not-fully-returned line, or does any placed order count; is the 90-day clock measured from first delivery or from first order; is the window inclusive at the boundary.
- Test for restatement: compare row counts and terminal line_status values for the cohort's order lines then versus now. Late-arriving deliveries and backfilled refunds legitimately move both sides and are not a bug, but they mean the number was published before it was stable.
- Whichever it is, restate the entire history on one definition and annotate the change date on the chart. A series with a step change where the definition moved is worse than no series, because it reads as a result.
Follow-up
- If it turns out to be a restatement rather than a definition change, what publication lag would have prevented it, and what does that lag cost in decision speed?
- How would you make the definition self-documenting so the next person cannot silently change it?
- Someone has already briefed the 29% as a retention win. How do you correct that without the correction itself reading as a result?
Instead of guessing where the week should go, day one measures it under a fixed rubric and allocates the remaining hours in proportion to the gaps. The method is deliberately rigid: the allocation is written down before any studying starts and is not renegotiated when a topic turns out to be unpleasant.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Diagnostic, scored before you study anything
- Sit a 100-minute timed diagnostic in four blocks: 30 minutes of SQL across three prompts, 25 minutes of short-answer statistics, 25 minutes on one modelling or case prompt, and 20 minutes delivering one behavioural story aloud.
- Score each block from 0 to 3 on a fixed rubric where 3 is correct and fluent, 2 is correct but slow or prompted, 1 is partially correct, and 0 is stuck, grading the output rather than how the attempt felt.
- Allocate the hours for days two to five roughly in proportion to 3 minus the score in each block, write the allocation down, and commit to not revising it midweek.
Deliverable: A scored rubric and a fixed hour allocation for the rest of the week.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Largest gap: find the boundary rather than the subject
- Break the weakest area into five named sub-skills (for query work: grain control, window frames, date arithmetic, set logic with NULLs, and reading a query plan) and rate each one, so the rest of the week targets a sub-skill instead of a subject.
- Solve three problems chosen to sit just above where the rating drops off, and for each write the first move you failed to make.
- Re-solve one of them from memory four hours later, on paper, with nothing open.
Deliverable: A five-item sub-skill map with the two blocking sub-skills circled.
Practice prompt ↗Practice prompt ↗03Largest gap: drill the blocking sub-skill
- Do eight short repetitions of the same shape rather than eight different problems, so what you practise is the pattern and not the puzzle.
- Write the rule you now hold in one sentence, then test it against a case built to break it: a ranking function over a column with ties, or a two-sample test on observations that are obviously dependent.
- Have someone else read your one-sentence rule and find the precondition you left out.
Deliverable: One rule statement with its preconditions attached and one counterexample that would have caught the incomplete version.
Practice prompt ↗Practice prompt ↗04Second gap, plus maintenance on your strongest area
- Run the same sub-skill map and boundary protocol on the second-largest gap, compressed into half the day.
- Spend 25 timed minutes on your strongest area to stop it decaying, choosing the hardest problem you can still finish rather than an easy warm-up.
- Compare how the two areas fail: whether you lose time on recall, on setup, or on arithmetic, because the fix differs for each.
Deliverable: A second sub-skill map plus a one-line diagnosis of how each area fails you.
Practice prompt ↗Practice prompt ↗Worked solution ↗05The gap that is not a skill
- Record yourself answering one technical and one behavioural prompt, then count two things in the playback: how many seconds before your first clarifying question, and how many sentences you started without knowing where they ended.
- Rewrite your three most-used stock phrases into shorter versions, and practise saying "I do not know, here is how I would find out" without softening it into a guess.
- Deliver one answer again with a hard 90-second limit to force structure before detail.
Deliverable: Two recordings with a counted improvement in time-to-first-question.
Practice prompt ↗Practice prompt ↗06Retest under day-one conditions
- Sit the same 100-minute diagnostic structure with new prompts of comparable difficulty and score it on the identical rubric.
- Compare block by block, and for any block that did not move, change the method rather than adding hours: a block stuck at 1 usually means the practice was too varied, not too short.
- Write which single block you would still lose the offer on.
Deliverable: A second scored rubric placed next to the first, with one named remaining risk.
Practice prompt ↗Practice prompt ↗07Full loop under interview conditions
- Run a 60-minute mock covering the two blocks that moved least, with an interviewer instructed to interrupt and change direction.
- Write your recovery script for the moment you go blank: restate the question, state your assumption, name the first thing you would check.
- Reduce the week to the rule statements you wrote, each with its preconditions attached, then say every one of them out loud without reading it and cut any you cannot state in a single sentence, since a rule you have to reconstruct mid-answer will not survive being interrupted.
Deliverable: A one-page card holding the recovery script and only the rules you could state from memory.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Saying no well is a senior skill and it is rarely rehearsed. Think of a time you told someone their analysis was not worth doing, or that the experiment could not answer their question at the sample size available. Explain what you offered instead. Refusal without an alternative reads as obstruction rather than judgement.
Tell me about a project where the data did not support your initial hy…
Tell me about a project where the data did not support your initial hypothesis. How did you pivot?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Pick a story where you drove the decision, not one where you observed it.
- Quantify the outcome, including what you would not claim credit for.
Follow-up
- How did you know the outcome was caused by your change?
- What did you decide not to do, and why?
Defend a promotion read that contradicts the revenue number
You analysed a site-wide twenty-percent weekend event. Revenue over the event week rose eleven percent year over year, contribution margin per delivered order fell, and the two weeks after the event ran below the pre-period baseline. The merchandising lead who owns the event calendar has already circulated the revenue figure. You have ten minutes at a planning meeting attended by that lead and their director. Deliver the finding and the recommendation you would make for the next event, and describe how you handle the pushback in the room.
Approach
- Before the meeting, write the finding as one sentence about the event, not about the person who owns it: the event moved price and timing, not demand. Keeping the event owner's judgement out of the sentence is what keeps the holdout you want on the table.
- Open with the number they already have, then decompose revenue into traffic, conversion, units per order, net price per unit and keep rate, and show which term moved. If price per unit fell and units per order held, the revenue gain was volume bought at a lower price.
- Quantify the post-period dip as the pull-forward estimate, and state the measurement window explicitly. The window has to extend past the event because the demand was borrowed from the weeks after it.
- Convert to incremental contribution margin. At gross margin m on list price and discount depth d, holding contribution flat requires a unit lift of d / (m - d), valid when m > d, when the discount applies to every unit sold, when unit cost is constant, and when nothing was cannibalised from full-price SKUs. Compare the observed lift to that threshold.
- Say what would change your mind and propose the design that would settle it: a geo or customer holdout on the next event, with the number of units and weeks it needs.
- End on the next event, not a verdict on the last one, so the meeting produces a decision rather than a defence.
Follow-up
- The lead says the event acquired new customers whose lifetime value justifies the margin loss. How would you test that claim with dim_customer and fct_order_line?
- Your director wants one number to take to finance. Which one, and what caveat travels with it?
Disagree with a product manager about a recommendation slot
A product manager wants to ship a recommendation module that raised slot click-through by thirty-one percent and slot-attributed revenue by nineteen percent over a two-week test. You have the holdout and can compute site-wide net revenue per session. Over the same window the treatment arm shows a higher net unit return rate and higher promotional depth on purchased lines, and site-wide revenue per session is flat within noise. The product manager has a launch date. Present your position in a fifteen-minute meeting and state what you recommend.
Approach
- Concede the surface result rather than disputing it. Click-through did rise. The open question is whether the units are new or moved from a search result, another slot or a later visit.
- State the measurement claim in one sentence: slot-attributed revenue counts capture, and only the holdout prices the counterfactual of what those customers would have bought anyway.
- Give the site-wide read with an interval, and say whether the test was powered to detect the effect size being claimed. Flat within noise is not evidence of no effect, and treating it as such is the fastest way to lose the argument to someone who notices.
- Bring the two mechanisms that explain the gap and point at where they are visible: the module surfaces more apparel and more discounted stock, which moves quantity_returned in fct_return_line and line_discount_cents in fct_order_line.
- Recommend something shippable this week rather than a block: launch behind a holdout that stays on, with site-wide net revenue per session after returns as the read at return maturity, and the decision rule agreed now.
Follow-up
- The product manager says returns take ninety days and the launch cannot wait. What do you ship on in the meantime?
- What result would make you say the module is working?
- 01
Tell me about a project where the data did not support your initial hypothesis. How did you pivot?
- 02
You analysed a site-wide twenty-percent weekend event. Revenue over the event week rose eleven percent year over year, contribution margin per delivered order fell, and the two weeks after the event ran below the pre-period baseline. The merchandising lead who owns the event calendar has already circulated the revenue figure. You have ten minutes at a planning meeting attended by that lead and their director. Deliver the finding and the recommendation you would make for the next event, and describe how you handle the pushback in the room.
- 03
A product manager wants to ship a recommendation module that raised slot click-through by thirty-one percent and slot-attributed revenue by nineteen percent over a two-week test. You have the holdout and can compute site-wide net revenue per session. Over the same window the treatment arm shows a higher net unit return rate and higher promotional depth on purchased lines, and site-wide revenue per session is flat within noise. The product manager has a launch date. Present your position in a fifteen-minute meeting and state what you recommend.
Is this an official Starbucks interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Starbucks. Rounds and questions reflect what candidates have reported, not a process Starbucks has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How technical is the Starbucks Data Scientist interview process?
The process is highly technical in the early stages, requiring you to pass a rigorous 90-minute online assessment covering both SQL and Python programming. Later rounds focus more on statistical theory, machine learning application, and behavioral alignment.
PracHub interview research ↗What is the typical timeline from the initial application to an offer?
The entire process generally takes about 3 to 5 weeks. This timeline can vary depending on hiring manager availability and scheduling.
PracHub interview research ↗Does Starbucks allow remote work for Data Scientist roles?
Starbucks corporate roles, particularly those based out of the Seattle Support Center, typically operate under a hybrid model. Candidates should expect to spend a portion of their week working onsite at the Seattle headquarters.
PracHub interview research ↗What distinguishes a successful candidate in the behavioral rounds?
Successful candidates are those who can clearly articulate the business impact of their technical work. Rather than just explaining the algorithms they used, they explain how their models increased revenue, reduced costs, or improved the customer experience.
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.
Wayfair Data Scientist Interview Questions & Guide 2026
Case practice for the Wayfair data scientist interview, where the prompt is deliberately underspecified and your first move is scoping it into something measurable.
Zulily Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for Zulily data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
Zalando Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at Zalando candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
US Foods Data Scientist Interview Questions & Guide 2026
Prepare for the data scientist interview at US Foods with original practice on experiment design, SQL, and metric reasoning, each exercise paired with a worked solution and the reasoning behind it.