This guide covers what a Data Scientist at Etsy is expected to do and how to prepare for the interview.
Recruitment Screening
reportedAn added round often puts you in front of someone outside the core hiring team: a partner engineer, a product owner, a domain expert, sometimes a more senior manager. The question they are really asking is not whether you can do the work but whether they would trust a number that came from you. That changes what a good answer looks like. Lead with what the decision cost and what it changed, keep the method available but not central, and be plain about the limits of your evidence. Overstating a result is the fastest way to lose this round.
What to demonstrate
- Whether you can explain a technical choice to someone who will never read your code, without either flattening it into nothing or hiding inside jargon
- Honesty about evidence strength: what the analysis establishes, what it only suggests, and what it cannot say at all
- How you take disagreement, specifically whether you update on a good objection, hold your position with reasons, or fold on contact
How to prepare
- Write the two-sentence version of your most technical project for a non-specialist, then check that neither sentence needs a method name to make sense.
- For one result you are proud of, write the strongest objection someone could raise and a response that concedes the part of it that is correct.
- Prepare one decision that turned out to be wrong: how you found out, what it cost, and what you changed afterwards. A senior cross-functional interviewer asks for this more often than a technical one does.
Technical Assessments
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
Interviews with Team Members
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.
2 candidate reports. Individual accounts describe a particular role and hiring cycle.
Etsy Machine Learning Engineer Interview Experience — A Recruiter Call That Felt AI-Scripted
View report detailsEtsy Data Scientist Interview Experience — Research Talk Plus a Live Autocomplete Coding Question
View report detailsPracHub editorial advice for the preparation topics above.
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.
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.
Reporting a mean for a heavy-tailed metric without saying what it hides
For spend, session length or items per order, a small fraction of units carries most of the total, so the mean has a wide standard error and one account can move it. Fix the handling before you see the result: cap or winsorise at a pre-declared percentile, and report the median or the share above a threshold next to the mean. Capping changes the estimand, so say which question the capped number answers, and check how much of any difference comes from the top 0.1 percent of units.
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.
Explain the bias-variance tradeoff and how you apply regularization te…
Explain the bias-variance tradeoff and how you apply regularization techniques in practice.
Approach
- Translate the result into the decision it informs, in one plain sentence.
- Sanity-check the answer against a simple bound or a simulated case.
- 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?
How do you address class imbalance when building a machine-learning mo…
How do you address class imbalance when building a machine-learning model to detect fraudulent listings?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Check what information would not exist at prediction time, and exclude it.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- Where could label leakage enter this setup?
- How would you choose the decision threshold, and who owns that choice?
Permutation test and block bootstrap for a switchback
You have mh: market_id, hour_start_utc, block_id, arm ('treat' or 'control'), eligible_requests, matched_in_sla. One row per market-hour, fourteen days in a single market, randomised in two-hour blocks. Without scipy.stats or statsmodels, produce three things: the effect estimate as the difference in ratio-of-sums fill rate between arms; a two-sided permutation p-value that reassigns arm at the block level holding the observed number of treated blocks fixed; and a 95% confidence interval from a bootstrap that resamples whole blocks with replacement. Use 10,000 iterations for each.
Approach
- Collapse to the randomisation unit first: sum eligible_requests and matched_in_sla per block_id and keep the arm label. Every later operation runs over 168 blocks, which is what makes the variance estimate honest.
- Estimate the effect as ratio of sums within each arm, not as the mean of per-block rates, because blocks carry very different volume and the mean of rates answers a different question.
- Permutation: shuffle the arm vector across blocks keeping the treated count fixed, recompute the same statistic, and report p = (1 + count of |stat*| >= |stat_obs|) / (B + 1). The plus-one is the correct finite-sample form and keeps p strictly positive.
- Bootstrap: resample block indices with replacement within each arm, recompute the ratio difference, and take the 2.5th and 97.5th percentiles; resampling blocks rather than hours propagates both the rate and the volume variation.
- State the effective sample size as 168 blocks rather than the request count, and convert that into the minimum detectable effect the design actually supports.
Worked solution 35 min
- blocks = mh.groupby(['block_id','arm'], as_index=False)[['eligible_requests','matched_in_sla']].sum().
- Define stat(arm_vector) = matched[treat].sum()/eligible[treat].sum() - matched[control].sum()/eligible[control].sum(), operating on NumPy arrays.
- Permutation loop: for each of 10,000 draws, rng.permutation of the arm vector, recompute stat, accumulate the count of |stat*| >= |stat_obs|.
- Bootstrap loop: draw block indices with replacement separately inside each arm, recompute stat, store; take np.percentile at 2.5 and 97.5.
- Report the point estimate in percentage points, the p-value, the interval, and the number of blocks.
Follow-up
- Blocks are two hours and the median order lasts 25 minutes. Where does carryover leak across the boundary, and what would you do with the first minutes of each block?
- How would you add covariate adjustment on pre-period market-hour fill rate without breaking the permutation argument?
Write a SQL query using window functions to calculate rolling seven-da…
Write a SQL query using window functions to calculate rolling seven-day active buyers by region.
Approach
- 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.
- Say which table is the grain you start from, and join outward from 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?
Given a user activity table, write a query to identify consecutive day…
Given a user activity table, write a query to identify consecutive days of platform engagement for each seller.
Approach
- 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.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
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.
Worked solution 15 min
- Count fct_request rows in the week per market and keep that number; it is the denominator every later number is checked against.
- Add the LEFT JOIN and re-count: the row count must be unchanged.
- Add the four filtered aggregates and the cancelled_by breakdown in one GROUP BY market_id.
- Compute both rates and test the multiplicative identity in the same query with a derived column.
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?
How would you measure the success of a major redesign of the Etsy home…
How would you measure the success of a major redesign of the Etsy homepage?
Approach
- 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.
- Fix the population and the time window before naming any metric.
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?
How do you prioritize competing analytical requests from multiple prod…
How do you prioritize competing analytical requests from multiple product managers?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Restate the decision this analysis has to support, and who acts on the answer.
- 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?
- What would you do if the primary metric and the guardrail moved in opposite directions?
A key engagement metric dropped unexpectedly by five percent week-over…
A key engagement metric dropped unexpectedly by five percent week-over-week. Walk through your diagnostic framework to identify the root cause.
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
- Name one primary metric, then the guardrail that stops it being gamed.
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?
Design a metric to track buyer satisfaction and long-term retention wi…
Design a metric to track buyer satisfaction and long-term retention within our marketplace.
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- Which segment would you cut first, and what would that rule out?
- What would you do if the primary metric and the guardrail moved in opposite directions?
Explain how you identify and mitigate common experimentation pitfalls …
Explain how you identify and mitigate common experimentation pitfalls such as sample ratio mismatch and novelty effects.
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 randomisation unit first; it decides the variance and what the test can detect.
Follow-up
- How would you handle interference between treated and control units?
- What would you do if you could not randomise at all?
Design an A/B test for a new checkout flow, determining sample size, d…
Design an A/B test for a new checkout flow, determining sample size, duration, and primary success metrics.
Approach
- Say whether units interfere with each other, and switch design if they do.
- Name the guardrails that would stop a launch even on a positive primary result.
- State the primary metric and the minimum effect worth shipping, then size the test.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- What would you do if you could not randomise at all?
Measure demand that never became a request
In constrained hours some consumers see a high quoted ETA or price and never create a request, so they have no row in fct_request. Leadership wants suppressed demand per market-hour. Propose a measurable proxy with an explicit numerator and denominator, state the direction and rough size of its bias, and name the one design that would identify the quantity rather than approximate it. You may use requested_at_local, surge_multiplier, quoted_eta_seconds, quoted_price_cents, request_status and fct_supply_session. Say plainly what your proxy cannot see, and what would falsify it.
Approach
- Refuse the question as stated, then fix it: 'suppressed demand' is undefined until you name a counterfactual policy. Demand at zero price and zero wait is not a business quantity. Define the target as requests that would have been created in this market-hour had the consumer been shown the quote typical of an unconstrained hour in the same market and hour-of-week.
- Give the cheap in-data proxy and be honest that it is a lower bound: numerator = requests with request_status in ('no_supply','abandoned_pre_match','consumer_cancelled_pre_match'), denominator = all requests in the market-hour excluding the 10-second mis-tap exclusion. It counts only consumers who got far enough to create a request, so it misses the entire population the question is about, and the miss grows precisely when scarcity is worst.
- Give the modelled proxy and its failure mode: fit expected requests per active consumer on market, hour-of-week and calendar controls using only hours with surge_multiplier = 1.00 and fill rate above SLA, then take shortfall = predicted minus observed. Bias: it attributes to suppression every reason a constrained hour differs from baseline. In a hour constrained by a demand spike, true demand exceeds baseline, so the shortfall understates suppression and can print zero or negative while suppression is real. It is not identified without variation in supply that is independent of demand.
- Name the identifying design: a market-hour switchback on the quoting policy, where treated blocks show the unconstrained-hour quote and control blocks show the live one. The difference in requests created per active consumer between blocks estimates the market-level quantity, with variance clustered at the block, burn-in blocks discarded, and block length longer than a typical order so effects do not leak across blocks.
- Add the cheap complement and its limit: a small-share consumer-level randomisation of the displayed quote identifies the individual request-creation elasticity with interference that is second order at small treatment shares, but it cannot give the market-level number because it holds the supply response fixed. State which of the two questions each design answers.
- Write the falsification test: if the proxy is measuring suppression, it should collapse in hours where supply was exogenously abundant at the same demand level, and it should not move when only the consumer mix changed.
Worked solution 40 min
- Rewrite the target quantity against a named counterfactual quoting policy, and say why the unconditioned version is not measurable in principle.
- Define the lower-bound proxy with numerator, denominator and window, and mark it explicitly as a floor.
- Define the modelled proxy, list the controls, and write out the case where its sign is wrong.
- Specify the switchback: randomisation unit, block length relative to order duration, burn-in, clustered variance.
- Write two sentences of bias disclosure that would go next to the number on any slide.
- Write the falsification check and what result would make you retract the proxy.
Follow-up
- A switchback that shows optimistic quotes creates orders the market cannot serve. How do you bound the harm and would you still run it?
- Your modelled proxy prints a large number in one zone and zero in the neighbouring zone in the same hour. What do you check first?
- How would you report this number to a leadership audience without it becoming a planning input it cannot support?
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?
For someone who has spent the last year in notebooks, dashboards or modelling work and has not written raw SQL under time pressure. The first four days rebuild query fluency against a fixture you control and can verify by hand; the last three attach that fluency to the rest of the loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Build a fixture you can check answers against
- Create a local Postgres or SQLite database with four tables (users, sessions, events, orders) holding roughly 200 rows you generated yourself, so you know the contents well enough to predict every result.
- Deliberately seed the cases that break queries: a user with no sessions, a session with no events, two orders sharing a timestamp, a NULL in one join key, and one duplicated user row.
- Before writing any SQL, hand-compute five answers on paper (how many users placed at least one order, median orders per ordering user, and three others) and save them as the ground truth for the week.
Deliverable: A one-command seed script plus a text file of five hand-computed answers to grade every later query against.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Joins, filters and NULL semantics
- Answer "which users have no orders" three ways (LEFT JOIN with IS NULL, NOT EXISTS, NOT IN) and confirm that the NOT IN version returns zero rows once the subquery contains a NULL, because the comparison is never TRUE.
- Reproduce the LEFT JOIN that silently collapses to an inner join by putting a right-table predicate in WHERE, then fix it by moving the predicate into the ON clause, and record both row counts.
- Create a fan-out bug on purpose by joining orders to order_items and summing the order total, then correct it with a pre-aggregated subquery and explain in one line which table changed the grain.
Deliverable: One annotated .sql file holding the three join traps, each with the wrong result and the corrected result side by side.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Window functions and frames
- Write three window queries against the fixture: a running order total per user, the rank of each order within its user by value, and the day gap to that user's previous order, then check each against the day-one ground truth.
- Run ROW_NUMBER, RANK and DENSE_RANK over a column containing ties, print all three side by side, and write one sentence on when each is the correct choice.
- Switch one query from the default frame (RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which is what you get when ORDER BY is present and no frame is written) to ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and explain why the output differs only when the ORDER BY column has duplicates.
Deliverable: Three verified window queries plus a short note explaining the RANGE versus ROWS difference in your own words.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04The four analytical query patterns
- Write a monthly retention grid: first order month per user, then months-since-first as the column, and verify that month zero equals the cohort size exactly.
- Sessionize the events table under a 30-minute inactivity rule using LAG plus a cumulative sum over a new-session flag.
- Build a four-step funnel that counts distinct users rather than events at each step, and state the rule you applied to a user who reaches step three without ever logging step two.
Deliverable: One file with the retention, sessionization and funnel patterns, each carrying a one-line note on the assumption it bakes in.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Write SQL the way you will have to write it live
- Set a 12-minute timer and solve three medium prompts in a plain editor with no execution and no autocomplete, then run them and tally syntax errors separately from logic errors.
- Narrate one solution aloud while writing it, stating the grain of each intermediate result (one row per user, one row per user-day) before you type its body.
- Rewrite your slowest solution as a CTE chain where every CTE name states its grain, and time yourself re-solving it from blank.
Deliverable: A recording of one narrated solution plus an error tally that separates syntax from logic.
Practice prompt ↗Practice prompt ↗06One day for everything that is not SQL
- Write the preconditions of the two-sample t-test from memory, then check them: independent observations, and a difference in means whose sampling distribution is approximately normal, which at large sample sizes follows from the central limit theorem rather than from normality of the raw values.
- Write the difference between an odds ratio from logistic regression and a relative risk, and state the condition under which the two are close (low outcome prevalence).
- Prepare a 90-second answer to "how would you know this model is any good" that names the metric, the baseline you would beat, and the cost of the errors you care about.
Deliverable: One page of notes covering test preconditions, the odds-ratio caveat and the model-quality answer.
Practice prompt ↗Practice prompt ↗07Full loop rehearsal
- Run a 45-minute mock with someone willing to interrupt: 20 minutes of SQL, 15 minutes defining a metric, 10 minutes on a past project.
- Re-solve from blank the two queries you were slowest on this week and compare the times against day five.
- Write a five-line answer to "walk me through a project" that puts a number in the first sentence and names the decision the work changed.
Deliverable: Mock feedback notes plus a timed project narrative you can deliver without reading it.
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 situation where you had to explain a complex statistic…
Tell me about a situation where you had to explain a complex statistical concept to a non-technical stakeholder.
Approach
- Quantify the outcome, including what you would not claim credit for.
- 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 did you decide not to do, and why?
- What would you do differently if you ran that project again?
Choose between three teams' requests with one analyst week
Three requests arrive the same morning and you have one analyst-week. Pricing wants a fee elasticity refresh for a change scheduled in ten days. Supply wants a churn model for approved providers who never opened a session. Finance wants the monthly contribution-margin restatement that attributes refunds and chargebacks in fct_money_movement to the order's completion month rather than the posting month. Deliverable: your ranking, the criterion behind it, the smallest useful version of each, and what you say to the two teams you rank below first.
Approach
- Rank on decision coupling rather than requester seniority or intrinsic interest: what decision hangs on this, on what date does it become useless, and how expensive is it to reverse if the answer is wrong.
- Notice the dependency before the ranking: the margin restatement changes the denominator of every unit-economics answer, including the elasticity work, so doing it second means redoing part of the first task.
- Unbundle each request into its smallest decision-bearing piece. The restatement is a change to the attribution date in one query, about half a day. The elasticity refresh needs a range and its preconditions, about two days. The churn model is the only item with no date and the longest build.
- Replace the churn model with the descriptive cut that may make it unnecessary: approved-provider time-to-first-session conversion by approval cohort and acquisition_channel, from dim_user provider_approved_at_utc against the first fct_supply_session.online_at_utc, one day. If conversion collapses in one channel or one market, the fix is operational and no model is needed.
- Communicate the ranking in writing where all three can see it, with the reason and the trigger that would reorder it, and give each deprioritised team a smaller concrete deliverable rather than a place in a queue.
Follow-up
- The supply lead escalates to your manager - what do you say, and what do you not say?
- What if the fee change's elasticity cannot be estimated observationally over the range they need?
- Which of the three would you drop entirely if you lost two days to an incident?
Handle a request to re-cut a test after the readout
A four-week consumer-credit test reads flat on completed orders per active consumer and negative on contribution margin per completed order, which was the pre-registered guardrail. The sponsor asks for three re-cuts: on gross bookings instead of margin, on a seven-day window instead of four weeks, and excluding one market that 'had an outage'. One of the three is defensible under conditions. Deliverable: which you run, which you decline, the words you use to decline, and what appears in the written readout about all three requests.
Approach
- Sort the three requests by one test: could this have been specified before anyone saw the result, and is it symmetric across arms. That test, not the sponsor's seniority, decides what you run.
- Decline the gross-bookings switch on mechanism rather than on process: the credit operates by spending incentive dollars, and gross bookings excludes incentive spend by construction, so it cannot see the cost the guardrail exists to catch.
- Decline the seven-day window because the credit's payback horizon is longer than the window, so a short read measures the redemption spike rather than the behaviour change, and because the window was chosen after the four-week result was known.
- Run the outage exclusion only under stated conditions: the outage is visible in a metric nobody selected, such as requests per market-hour in fct_request, it hit both arms in the same proportion, and it is timestamped independently of this test. Report it as a sensitivity beside the primary, never as a replacement.
- Put all three requests in the readout with their status and reasoning, which makes the selection visible and removes the incentive to ask again quietly; then give the sponsor a real path forward: the incentive level at which the credit would break even on contribution margin, and a powered follow-up if that level is reachable.
Follow-up
- The sponsor says the guardrail was the wrong metric all along - how do you respond?
- What if the outage is real but hit only the treatment arm?
- How would you have pre-registered exclusions so that this conversation never happened?
- 01
Tell me about a situation where you had to explain a complex statistical concept to a non-technical stakeholder.
- 02
Three requests arrive the same morning and you have one analyst-week. Pricing wants a fee elasticity refresh for a change scheduled in ten days. Supply wants a churn model for approved providers who never opened a session. Finance wants the monthly contribution-margin restatement that attributes refunds and chargebacks in fct_money_movement to the order's completion month rather than the posting month. Deliverable: your ranking, the criterion behind it, the smallest useful version of each, and what you say to the two teams you rank below first.
- 03
A four-week consumer-credit test reads flat on completed orders per active consumer and negative on contribution margin per completed order, which was the pre-registered guardrail. The sponsor asks for three re-cuts: on gross bookings instead of margin, on a seven-day window instead of four weeks, and excluding one market that 'had an outage'. One of the three is defensible under conditions. Deliverable: which you run, which you decline, the words you use to decline, and what appears in the written readout about all three requests.
Is this an official Etsy interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Etsy. Rounds and questions reflect what candidates have reported, not a process Etsy has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What is the overall difficulty level of the interview process, and how much preparation time should I plan for?
The interview loop is moderately to highly rigorous, particularly during the technical and product sense rounds. Most candidates benefit from 4 to 6 weeks of dedicated preparation, focusing heavily on SQL window functions, A/B testing methodologies, and structured product case studies.
PracHub interview research ↗What differentiates successful candidates from those who fall short?
Successful candidates consistently ground their answers in business context rather than just theoretical math. They structure ambiguous problems clearly, articulate the trade-offs of their proposed solutions, and demonstrate genuine empathy for Etsy's buyer and seller community.
PracHub interview research ↗How are remote and hybrid work policies handled for this role?
Etsy offers flexible work arrangements depending on the specific team and location, with many roles operating in a hybrid model that blends remote flexibility with purposeful in-person collaboration at hub offices such as New York or Brooklyn.
PracHub interview research ↗What is the typical timeline from initial recruiter screen to final offer?
The entire process typically spans 3 to 5 weeks from the initial recruiter outreach to final decision, though timelines can occasionally vary based on scheduling logistics and team alignment.
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.