As a Data Scientist at Just Eat Takeaway, you operate at the intersection of complex logistics, consumer behavior, and food technology. Your work directly influences the efficiency of our marketplace, from optimizing delivery times and restaurant recommendations to refining our pricing strategies. You aren't just building models; you are solving real-world problems that affect millions of users and thousands of restaurant partners every single day.
This role requires a blend of rigorous statistical thinking and product intuition. You will be expected to design experiments that provide actionable insights, diagnose metric fluctuations in a high-velocity environment, and communicate findings to cross-functional stakeholders. Because Just Eat Takeaway operates at massive scale, your ability to write efficient SQL and design robust experimentation frameworks is vital to our continued growth.
You will join a fast-paced, collaborative environment where data is the primary driver of product evolution. While the work is intellectually demanding and often involves navigating the ambiguity of a global marketplace, the impact of your contributions is highly visible. We look for candidates who are not only technically proficient but also curious about the business outcomes their models drive.
Screening Calls
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 Assessments
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
Collaborative Sessions
reportedBecause the format is not fixed, prepare the reasoning rather than the ritual. Nearly every version of this round draws on the same underlying material: a design you can defend, a metric you can define exactly, an analysis whose assumptions you can state out loud. Only the wrapper changes, whether that is a take-home, a live case, a deep dive on past work, or a rough estimate on a whiteboard. Answers rehearsed to fit one shape stall the moment the shape differs. Practise naming the assumption behind a number, then saying how much the conclusion moves if that assumption is wrong.
What to demonstrate
- Whether your justification for a method survives the question 'why not the simpler thing', including when the simpler thing would have worked
- Precision under pressure: what exactly counts as an active user, a conversion or a success, over what window, with what exclusions
- Whether you carry an argument through to a recommendation instead of stopping at a list of tradeoffs
How to prepare
- For each project you plan to mention, write the metric definition in one sentence: numerator, denominator, time window, exclusions. Say it out loud once, because vagueness shows up in speech before it shows up on paper.
- Rehearse the same project at three lengths: two minutes, ten minutes, and a deep dive on one technical decision. Cutting live is harder than it sounds.
- For your headline result, write down what would have had to be true for it to be wrong, and how you ruled that out.
Final Assessment
reportedWhere a loop ends with a senior leader, that conversation is rarely another skills test. The technical signal already exists by then, so the questions tend to open up: what you would look at first, where a metric you have heard about could mislead, what you would push back on. The decision being made is scope, which in practice means level and how much you would be trusted to own unsupervised. Treating it as a formality is the usual mistake. An open question late in the day is still being scored, and a vague answer reads as someone who has not run anything themselves.
What to demonstrate
- Whether your view of the business has anything specific behind it, given that you are working only from what is public and are expected to say so
- Whether the scope of work you describe owning matches the scope of the role, instead of sitting a level below it
- Whether you can disagree with something concrete and stay useful about it, rather than agreeing with everything said in the room
- Whether your questions are ones only this person could answer, as opposed to ones the recruiter already covered
How to prepare
- Build one view you could defend for two minutes using only public information: what the funnel probably looks like, which metric likely drives decisions, and where that metric could mislead. Being wrong for a stated reason survives this round; having no view does not
- Write down the largest piece of work you have owned from question to decision, who else touched it, and what you decided alone, then check that it reads at the level you are interviewing for
- Prepare one thing you would want changed if you joined and phrase it as a question rather than a verdict, so it opens a conversation instead of closing one
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.
Denominator drift in per-active-user metrics
Orders per active consumer falls when acquisition succeeds, because new cohorts transact less than tenured ones, so the metric penalises the thing the company is trying to do. A team that optimises it will quietly prefer weaker acquisition. Decompose into cohort size times cohort frequency, or hold the cohort fixed and read frequency by tenure bucket, before drawing any conclusion about engagement.
Optimising accuracy on a heavily imbalanced target
State the base rate first, then choose the metric from the relative cost of a false positive against a false negative: precision and recall at the operating threshold, PR-AUC, or expected cost. At a 1 percent positive rate, predicting the majority class for everyone scores 99 percent accuracy and is worthless.
Solving silently instead of narrating the reasoning
Say which branch you are taking and why you chose it over the alternative, for example checking the denominator first because it changes what the comparison means. A correct answer that arrives with no visible path scores below a rigorous one that needed a hint.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
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.
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?
Net take and margin per market-month without ledger fan-out
You have orders (order_id, market_id, completed_at_utc, order_status, gross_booking_cents, provider_payout_cents, consumer_incentive_cents, provider_incentive_cents, tip_cents) and ledger (ledger_id, order_id, entry_type in charge, refund, chargeback, incentive, payout, adjustment, processing_fee; amount_cents signed positive into the platform; posted_at_utc; settlement_status). For completed orders, produce a market-month frame with net take, margin before support cost, and the order count. Attribute refunds, chargebacks and processing fees to the order's completion month, not the posting month, and drop ledger rows whose settlement_status is 'pending' or 'failed'.
Approach
- Aggregate the ledger to the order grain before touching orders: filter settlement_status, then pivot entry_type into one summed column each. Merging first and summing after multiplies gross_booking_cents by the number of ledger rows on that order.
- Merge the pivoted ledger onto orders with validate='m:1' so an unexpected duplicate raises instead of silently inflating every total.
- Net take = gross_booking - provider_payout - consumer_incentive - provider_incentive over completed orders only; tips are excluded on both sides because they pass through to the provider and never enter platform revenue.
- Add the signed ledger columns rather than subtracting absolute values: refunds, chargebacks, payouts and processing fees are negative under this convention, so margin = net_take + refund + chargeback + processing_fee. Verify the sign on one known order before trusting the aggregate.
- Group by market_id and completed_at_utc month, never posting month; that is the whole point of the attribution rule, and it is why a month's margin is not final until the chargeback window closes.
- Carry completed_orders in the output so per-order margin can be recomputed downstream without averaging an average.
Worked solution 30 min
- led = ledger[~ledger.settlement_status.isin(['pending','failed'])]; wide = led.pivot_table(index='order_id', columns='entry_type', values='amount_cents', aggfunc='sum', fill_value=0).
- comp = orders[orders.order_status == 'completed']; m = comp.merge(wide, on='order_id', how='left', validate='m:1').fillna({col: 0 for col in wide.columns}).
- net_take = gross_booking_cents - provider_payout_cents - consumer_incentive_cents - provider_incentive_cents.
- margin = net_take + refund + chargeback + processing_fee, using the signed ledger columns directly.
- Group by market_id and completed_at_utc.dt.to_period('M'), summing net_take and margin and counting order_id.
Follow-up
- A chargeback posts two months after completion and changes an already-reported month. How do you publish a metric that is not final, and what lag would you quote?
- Should the denominator be matched orders, completed orders, or completed-and-settled orders? Argue for one and name what it hides.
Audit supply-session integrity without shrinking the frame
You are given sessions: session_id, provider_id, market_id, online_at_utc, offline_at_utc (NaT while open), online_seconds, engaged_seconds, en_route_seconds, idle_seconds, offers_received, offers_accepted, orders_completed, end_reason. Write audit(sessions) returning one row per rule with the rule name, violation count, violation share and up to five example session_ids. Cover at least: engaged + en_route + idle not equal to online_seconds; for closed sessions, online_seconds disagreeing with offline_at minus online_at by more than 2 seconds; offers_accepted greater than offers_received or orders_completed greater than offers_accepted; two overlapping sessions for the same provider; offline_at_utc NaT while end_reason is not 'session_still_open'.
Approach
- Express every rule as a boolean Series over the whole frame rather than as a filtered sub-frame, so all rules share one denominator and can be combined or counted together afterwards.
- Apply the duration rule only to closed sessions and keep the 2-second tolerance as a named constant in the output, since clock rounding is a real effect and hiding the tolerance makes the report unreproducible.
- Detect overlaps in one sort: order by (provider_id, online_at_utc), fill NaT offline times with a far-future sentinel, take a per-provider shifted cumulative max of offline_at_utc, and flag rows whose online_at_utc is strictly less than it. That is O(n log n) and needs no self-join.
- Emit rules with zero violations as explicit rows, so a rule that passed is distinguishable from a rule that never ran.
- Keep impossible values and merely suspicious ones in separate rows with the threshold stated: a 30-hour online session breaks no invariant but belongs in the same report.
Follow-up
- One rule fires on 0.4% of rows, all in a single market. How would you decide between an ingestion bug and genuine provider behaviour?
- Which of these rules would you make a blocking pipeline test, and which only a monitored alert, and what distinguishes the two?
Can you explain the difference between `RANK`, `DENSE_RANK`, and `ROW_…
Can you explain the difference between RANK, DENSE_RANK, and ROW_NUMBER and provide a scenario for each?
Approach
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- 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?
Given a table of order logs, how would you use window functions to cal…
Given a table of order logs, how would you use window functions to calculate the rolling average of order value per user?
Approach
- Say which table is the grain you start from, and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
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?
How would you design a metric to measure the success of our restaurant…
How would you design a metric to measure the success of our restaurant recommendation system?
Approach
- 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.
- 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?
- How would you detect that the metric is being gamed rather than genuinely improving?
If you notice a sudden drop in order volume in a specific region, how …
If you notice a sudden drop in order volume in a specific region, how would you go about diagnosing the root cause?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- 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?
How would you define "customer loyalty" for our platform, and what dat…
How would you define "customer loyalty" for our platform, and what data would you use to track it?
Approach
- 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.
- 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?
- How would you detect that the metric is being gamed rather than genuinely improving?
What trade-offs do you consider when balancing delivery speed versus d…
What trade-offs do you consider when balancing delivery speed versus delivery cost?
Approach
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
- Decompose the metric into the rates that drive it, and say which one you would check first.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
How do you determine the required sample size for an A/B test, and wha…
How do you determine the required sample size for an A/B test, and what factors influence your power calculation?
Approach
- State the primary metric and the minimum effect worth shipping, then size the test.
- 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?
What are the most common pitfalls you encounter when running A/B tests…
What are the most common pitfalls you encounter when running A/B tests in a marketplace environment?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Name the guardrails that would stop a launch even on a positive primary result.
- Decide the analysis before seeing data, including how long it runs and when you look.
Follow-up
- What would you do if you could not randomise at all?
- How would you handle interference between treated and control units?
Cut variance in an underpowered market-hour fill-rate test
A switchback test randomises matching logic by market-hour and reads SLA fill rate. Ten weeks of pre-period fct_request history exist for every market and hour-of-week. Blocks are scarce and the test is underpowered at the effect size that would justify shipping. Specify a variance-reduction plan: the covariate, how you estimate the adjustment coefficient, the variance reduction you expect as a function of the covariate correlation, and the preconditions that keep the adjusted estimator unbiased. Say which part of the diurnal cycle you would remove by design rather than by adjustment.
Approach
- Choose the covariate from pre-period data only: the same market and hour-of-week fill rate averaged over the four preceding weeks. Hour-of-week rather than hour-of-day, because weekday and weekend demand shapes differ enough that collapsing them destroys most of the correlation.
- State CUPED exactly. Y_adj = Y - theta * (X - mean(X)), with theta = Cov(Y, X) / Var(X). Then Var(Y_adj) = Var(Y) * (1 - rho^2). At rho = 0.7 that leaves 51% of the variance, a 49% reduction, which shrinks the MDE by a factor of sqrt(0.51) = 0.71, about 29% smaller for the same block count, or equivalently about half the blocks for the same MDE.
- List the preconditions, because they are what makes the adjustment legitimate rather than cosmetic: X must be measured before assignment and must be untouched by treatment; theta is a single constant, best estimated on the pre-period so its estimation error cannot correlate with the in-test outcome; and the adjustment removes variance only, never bias, so it cannot rescue a broken randomisation or an SRM.
- Handle the ratio metric correctly. Fill rate is a ratio of sums over requests while randomisation is at the block, so decide the estimand first, then linearise. If the estimand is the demand-weighted ratio of sums, apply the delta method to get the per-block influence values and run CUPED on those; applying CUPED to raw per-block rates understates variance when block sizes vary widely.
- Remove the biggest variance component by design instead of by adjustment: stratify assignment within market by hour-of-week, so each arm receives the same peak and off-peak mix by construction. The diurnal cycle dominates block-level variance here, and balancing it does not depend on a correlation estimate holding up in-test.
- Validate before spending live weeks. Replay an A/A over historical blocks with the same stratification and adjustment, and confirm the realised standard error matches the planned one.
Worked solution 30 min
- Build the covariate: per market and hour-of-week, mean fill rate over the four weeks before the test window opens.
- Estimate rho on pre-period data by correlating the covariate with a held-out later pre-period week, and estimate theta = Cov(Y, X) / Var(X) on the same pre-period.
- Compute the expected variance ratio 1 - rho^2 and translate it into either a smaller MDE (factor sqrt(1 - rho^2)) or a smaller block requirement (factor 1 - rho^2).
- Stratify the live assignment by hour-of-week inside each market so the diurnal mix is balanced by design.
- Replay an A/A on historical blocks with the full pipeline and compare the realised standard error against the planned one before starting.
Follow-up
- The realised correlation between pre-period and in-test fill rate is 0.35. Is CUPED still worth running, and what else would you reach for?
- A market adds a large block of new supply mid-test. What does that do to the covariate and to theta?
- Would you ever adjust on a covariate measured after assignment, and what breaks if you do?
Attribute a four percent completed-order drop to one funnel stage
Completed orders in one market fell 4.1% week over week. No experiment ran and no price changed. You have fct_request (request_id, consumer_id, market_id, requested_at_utc, requested_at_local, matched_at_utc, terminal_at_utc, request_status, order_id), fct_order (order_id, request_id, order_status, completed_at_utc) and dim_user (user_id, first_completed_order_at_utc). Attribute the drop across requests, fill rate and completion rate, then cut the factor that moved by new versus returning consumer and by local hour. Deliverable: one sentence naming the stage that moved, plus the share of the drop you could not attribute.
Approach
- Anchor all three stages on the same request cohort, keyed on requested_at_utc, so that requests x fill rate x completion rate multiplies back exactly to completed orders. Counting orders by completed_at_utc instead breaks the identity and the factors stop reconciling.
- Decompose in logs: delta ln(completed) = delta ln(requests) + delta ln(fill) + delta ln(completion). The identity is exact, so the three contributions add up with no cross-term to argue about. Convert back to percentage points only for the write-up.
- Handle the window edge before comparing. Require terminal_at_utc inside the window, or trim the last few hours, so orders still in flight at the newer window's edge are not counted as failures to complete.
- Cut the factor that moved by tenure (new = first_completed_order_at_utc is NULL or inside the window) and by requested_at_local hour. A loss concentrated in returning consumers at peak hours reads as liquidity; one concentrated in new consumers reads as acquisition mix.
- Split requests into active consumers x requests per active consumer. If active consumers rose while requests per active fell, the second number is cohort dilution from new signups, not disengagement, and needs a tenure-held-fixed read before anyone calls it engagement.
- Report the residual honestly: sum the segment contributions weighted by their prior-week share of the base, and state how much of the move those segments fail to explain.
Follow-up
- Fill rate fell but provider online hours were flat. Which two queries separate a dispatch regression from a demand spike?
- The whole drop sits in one origin geohash prefix. What do you check before calling it a supply problem?
- How would your answer change if a new service tier launched mid-week inside the same market?
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.
Half of this section is about translation. Be ready to describe how you explained a result to someone who did not want the method, only the implication, and what you did when the simplified version started being repeated in a way that overstated it. Correcting your own simplification is a strong beat.
How do you handle network effects or interference when testing a new d…
How do you handle network effects or interference when testing a new delivery algorithm?
Approach
- Close with what you would do differently, concretely.
- Pick a story where you drove the decision, not one where you observed it.
- State the situation in two sentences and spend the rest on your reasoning.
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?
Defend a finding that a provider bonus is incremental but uneconomic
A provider bonus ran in 40 treated market-hours. The program owner's read is +12% completed orders versus the prior week in the treated cells. Your holdout analysis, against untreated cells that shared the same demand shock, puts the effect at 0.06 incremental completed orders per incentive dollar, 95% interval [0.01, 0.11], against contribution margin of $1.40 per completed order. The owner presents the +12% at a review tomorrow and has not seen your number. Deliverable: what you do before the meeting, what you say in it, and the evidence you bring.
Approach
- Reproduce the owner's +12% exactly, from their cells and their window, before doing anything else; a disagreement where you cannot reproduce the other number is a credibility fight rather than a measurement one.
- Be precise about what you found: the interval [0.01, 0.11] excludes zero, so the bonus does buy orders and you are not claiming otherwise. The argument is about price, not existence, and saying 'it did nothing' hands the owner a refutation built from your own numbers.
- Set the bar in the same units as the estimate: breaking even at $1.40 of contribution margin needs 1 / 1.40, about 0.71 incremental orders per dollar. The upper end of your interval, 0.11, is about six and a half times short of that, so every value the data support loses money - which is what makes a wide interval decision-ready without being narrowed.
- Invert the ratio, because per-dollar increment is easy to nod at and hard to feel: 0.06 orders per dollar means about $16.70 of bonus per incremental order against $1.40 of margin, the optimistic end 0.11 is about $9.10, and the pessimistic end 0.01 is about $100.
- Show the displacement rather than asserting it, and keep the evidence cells out of the comparison set: adjacent untreated hours and adjacent zones where completed orders fell while treated cells rose is the signature of volume moved rather than created. State the precondition - if displacement also reached the difference-in-differences comparison cells, their post-period is depressed by the treatment, the estimate is biased upward, and 0.06 is an upper bound rather than a point estimate.
- Separate the measurement question from the decision question and name what would change your mind: a randomised holdout at the same granularity as the incentive, sized in advance, with a date. Offer to run it rather than only to block the program.
Follow-up
- The owner argues the bonus buys provider retention rather than orders - how would you test that claim, and over what horizon?
- At what contribution margin per completed order would 0.06 orders per dollar break even, and is that margin reachable in this marketplace?
- How would you tell displacement across hours apart from a genuine demand shift?
- 01
How do you handle network effects or interference when testing a new delivery algorithm?
- 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
A provider bonus ran in 40 treated market-hours. The program owner's read is +12% completed orders versus the prior week in the treated cells. Your holdout analysis, against untreated cells that shared the same demand shock, puts the effect at 0.06 incremental completed orders per incentive dollar, 95% interval [0.01, 0.11], against contribution margin of $1.40 per completed order. The owner presents the +12% at a review tomorrow and has not seen your number. Deliverable: what you do before the meeting, what you say in it, and the evidence you bring.
Is this an official Just Eat Takeaway interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Just Eat Takeaway. Rounds and questions reflect what candidates have reported, not a process Just Eat Takeaway has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How long does the entire interview process typically take?
The timeline can vary, but generally expect the process to take several weeks. We recommend staying in close contact with your recruiter for updates.
PracHub interview research ↗Is the technical assessment purely coding-based?
No, it often includes a case study component where you are asked to apply your knowledge to a hypothetical business problem. Focus on your methodology and communication during these sessions.
PracHub interview research ↗What is the culture like at Just Eat Takeaway?
We are a fast-moving, global organization. We value collaboration, data-driven decision-making, and a hands-on approach to problem-solving.
PracHub interview research ↗How can I best prepare for the behavioral rounds?
Use the STAR method (Situation, Task, Action, Result) to structure your answers. Ensure your examples highlight your contributions and your ability to work within a team.
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.
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.