At Zillow, a Data Scientist is at the heart of the company's mission to build the world's most trusted and vibrant home marketplace. You will work on complex, high-impact problems that directly influence millions of users looking to buy, sell, rent, or finance their homes. From refining the industry-standard Zestimate to optimizing search algorithms and personalized recommendation systems, your work will turn massive, unstructured real estate data into actionable insights and predictive models.
The role demands a unique blend of deep technical expertise, business acumen, and product curiosity. You will not just build models in isolation; you will partner closely with engineering, product management, and business operations to design experiments, measure success, and deploy scalable data-driven solutions. The scale of the data and the tangible real-world impact make this position both highly challenging and immensely rewarding.
Recruiter Screen
reportedMost candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.
What to demonstrate
- Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
- Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
- The substance of the questions you ask back, which an experienced screener reads as a level signal
How to prepare
- Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
- Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
- Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered
Technical Screening
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
Final Panel Loop
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.
Reading incentive impact without a cell-level holdout
A bonus in one hour or one zone pulls provider hours and consumer orders from adjacent hours and zones rather than creating them, so a before-and-after read on the treated cell counts displaced volume as incremental and can show a positive result for a spend that produced nothing. Only a randomised holdout at the same granularity as the incentive, or a comparison against untreated cells that share the demand shock, separates increment from displacement. Always state incremental orders per incentive dollar, never total orders in treated cells.
Defining the cohort on a post-treatment condition
Ask how rows entered the table. Filtering on something that treatment itself influences, such as users who finished onboarding or accounts still active at ninety days, breaks comparability between arms; define the population at an entry point that precedes exposure and keep everyone in it.
Analysing at a different unit than the one randomised
Say out loud what was randomised (user, device, account, cluster) and make the analysis unit match, or account for the clustering with cluster-robust standard errors, the delta method, or aggregation up to the randomised unit. Randomising users and then running a test over sessions understates variance and inflates the false-positive rate.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the mathematical formulation and loss function of a logistic r…
Explain the mathematical formulation and loss function of a logistic regression classifier.
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Set a baseline first, so any model has something honest to beat.
- Say how the offline result would be validated online before it is trusted.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- Where could label leakage enter this setup?
How does a random forest algorithm calculate feature importance, and w…
How does a random forest algorithm calculate feature importance, and what are the limitations of this approach?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Set a baseline first, so any model has something honest to beat.
- Say how the offline result would be validated online before it is trusted.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
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.
Write a Python function to perform exploratory data analysis (EDA) on …
Write a Python function to perform exploratory data analysis (EDA) on a dataset with missing values and explain your strategy for imputation.
Approach
- 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.
- 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?
Write a query to calculate the month-over-month growth rate of active …
Write a query to calculate the month-over-month growth rate of active listings using CASE/WHEN and self-joins.
Approach
- Say which table is the grain you start from, and join outward from it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
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 measure the success of a new search filter designed to h…
How would you measure the success of a new search filter designed to help users find homes with specific architectural styles?
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- State what result would change your recommendation, so the answer is falsifiable.
- 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?
- What would you do if the primary metric and the guardrail moved in opposite directions?
What visualization techniques and metrics would you use to present hou…
What visualization techniques and metrics would you use to present housing market trends to non-technical executive stakeholders?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- 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
- How would you detect that the metric is being gamed rather than genuinely improving?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How do you prioritize your work when managing multiple high-priority d…
How do you prioritize your work when managing multiple high-priority data science requests?
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.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- Which segment would you cut first, and what would that rule out?
If the click-through rate on premier agent profiles drops by 5%, how w…
If the click-through rate on premier agent profiles drops by 5%, how would you investigate the root cause?
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.
- 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?
Value a bonus at an order-count threshold without randomisation
A weekly bonus pays providers who complete at least 25 orders in a calendar week, and the app shows a live progress counter. Finance asks what the bonus does to next-week retention, defined as at least one completed order in week w+1. A randomised holdout was refused. You have 18 months of weekly per-provider completed-order counts from fct_order and bonus payments from fct_money_movement. Propose an identification strategy, name the assumption it rests on, give the test that would falsify that assumption here, and say what you do when the test fails.
Approach
- Propose the design the data invites: a sharp regression discontinuity in the running variable, completed orders in week w, at the cutoff of 25, comparing week w+1 retention just above and just below. Estimate with local linear regression on each side, an MSE-optimal bandwidth and bias-corrected robust confidence intervals. Avoid a high-order global polynomial, which gives weight to observations far from the cutoff and manufactures artefacts at the boundary.
- State the identifying assumption plainly: continuity of potential outcomes at the cutoff, meaning providers just below 25 are a valid counterfactual for those just above. A live progress counter is precisely the mechanism that destroys it, because providers who can reach 25 will, so the population just above is selected on motivation and availability rather than on chance.
- Falsify it before estimating anything. Run a density-continuity test on the running variable, looking for a deficit just below 25 and a spike at 25 and 26. Test continuity at the cutoff of variables fixed before the week began, including tenure, prior-week orders, market and approval date; a jump in any of them is the same warning arriving by a different route.
- When the density test rejects, say the design is not identified and stop treating the coefficient as causal. A donut specification that drops a window around the cutoff addresses heaping in a discretised running variable, not sorting driven by the incentive itself, so it does not rescue this case and offering it as a fix is the wrong answer.
- Rank the fallbacks by credibility rather than by convenience. First, an instrument the provider cannot observe or manipulate, used in a fuzzy design, where the exclusion restriction requires that the instrument affect retention only through bonus receipt, which disqualifies anything providers are told about. Second, difference-in-differences or synthetic control across markets whose bonus threshold moved on known dates, clustering at market and showing the pre-trend leads. Third, negotiate a staggered rollout, which is usually cheaper to obtain than it looks and turns the question back into an experiment.
- Bound the claim even under a valid design. Regression discontinuity identifies a local effect at 25 orders per week. It says nothing about providers at 5 or at 60, while the decision Finance is making, whether to keep funding the bonus, is about the whole distribution.
Worked solution 40 min
- Histogram weekly completed-order counts in unit-width bins from 15 to 35 and look for a deficit below 25 and a spike at 25 to 26.
- Run a local-polynomial density-continuity test at the cutoff and record the estimate, standard error and p-value.
- Test continuity at the cutoff of pre-determined covariates: tenure in weeks, prior-week completed orders, market and provider_approved_at_utc cohort.
- If either test rejects, write the regression discontinuity off as descriptive, document the bunching evidence, and cost the fallback designs including a staggered threshold rollout.
- If both pass, estimate with local linear regression, MSE-optimal bandwidth and robust bias-corrected intervals, and report the local effect with its bandwidth sensitivity and its explicit scope limit.
Follow-up
- The counter is hidden for a random subset of providers next quarter. What design does that enable, and what does it identify?
- The density test passes in one vertical and fails in another. Would you publish the estimate from the vertical that passed?
- What would have to be true for an instrument based on a provider market-level threshold to satisfy the exclusion restriction?
Separate a client release regression from a broken event pipeline
Requests from one client platform fell 12% over four days while the other two platforms held flat. fct_request carries client_platform ('ios','android','web') and requested_at_utc, and you can join app version onto each request. A staged rollout of a new build for that platform started on day one and reached full traffic on day four. Decide whether requests genuinely fell or simply stopped being recorded. Deliverable: a verdict, the evidence that settles it, and the one query result that would change your mind.
Approach
- Plot the daily platform series against the rollout share. A regression inside the new client code tracks the rollout curve; a logging or ingestion break is a step at a deploy or partition boundary and hits every version of that platform at once.
- Split within the platform by app version. If users still on the old build dropped by the same amount, the new build cannot be the cause and the search moves to server-side or pipeline changes.
- Test whether rows are missing rather than events. Anti-join fct_order back to fct_request on request_id: an order whose parent request row does not exist is proof of row loss, because the order could not have been created without a request.
- Treat unchanged downstream rates as suggestive only. Uniform row loss leaves fill rate, completion rate and dispatch_attempts intact, but so can a proportional fall in genuine demand. What decides it is a count that does not travel the same logging path, such as the orphan count above or the platform's share of authenticated sessions.
- If the build is implicated, resist a naive before-and-after on the same version. Rollout cohorts self-select, since users who auto-update differ from users who do not, so rely on the ramp-shape argument or on a held-back slice if the release had one.
Follow-up
- The rollout shipped with no holdback. How would you bound the effect without one?
- Requests recovered on day five with no code change deployed. What is now the leading hypothesis?
- What instrumentation would make this ambiguity impossible to reach next time?
For someone who can already write the query and train the model but stalls when asked what to measure or whether a change is worth making. Metric definition and case structure come first; the technical work is kept as maintenance rather than the centre of the week.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Metric anatomy
- For three products you use daily, write one primary metric, two input metrics that plausibly move it, and one guardrail that would catch a cheap way of moving the primary at the cost of the product.
- For one of them, specify the metric precisely enough that two analysts would return the same number: numerator, denominator, unit of observation, time window, and how returning and deleted accounts are treated.
- Pick a ratio metric and write what happens to it when the denominator shrinks for reasons unrelated to the numerator, with a concrete example of that happening.
Deliverable: A one-page metric tree for one product, with the primary metric written as an unambiguous spec.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Diagnosing a drop without guessing
- Take the prompt "weekly active users fell 8 percent week over week" and write the segmentation plan before proposing any cause: platform, region, tenure cohort, acquisition channel, and whether the movement sits in the numerator or in a changed denominator.
- List the instrumentation failures that manufacture fake drops (a client release that stopped firing an event, a bot filter change, a shifted date boundary or timezone) and write the query that rules out each one.
- Rehearse stating the boring explanations first, seasonality and day-of-week composition, before reaching for a product cause.
Deliverable: A drop-diagnosis checklist short enough to recite from memory in under a minute.
Practice prompt ↗Practice prompt ↗03Should we build it
- Take a feature idea and write it as a bet: what you believe is true, what would have to be true for it to pay off, the metric that would confirm it, and the effect size that would justify the engineering cost.
- Size the opportunity top-down and bottom-up, then reconcile the two numbers in writing instead of quoting whichever is friendlier.
- Write the counter-metric that would make you kill the feature even if it wins on the primary metric.
Deliverable: A one-page product memo ending in a decision rather than a list of considerations.
Practice prompt ↗Practice prompt ↗04The places aggregate numbers lie
- Construct a Simpson's paradox numerically: two segments where the treatment wins within each segment yet loses overall, and identify the shift in segment weights that causes it.
- Take a heavy right-tailed quantity such as revenue per user and write why the mean is the wrong summary, which percentile you would report instead, and what a moving mean with a stable median tells you.
- Write your definition of a session for the product from day one, then name two real behaviours it misclassifies.
Deliverable: One page holding a worked Simpson's paradox table and a session definition with its two known failure cases.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Technical maintenance, aimed at metrics
- Solve four timed SQL prompts that all end in a ratio metric, so the question of grain stays live in every answer.
- Compute a 95 percent confidence interval for a proportion on a small sample, and state why the normal approximation is unreliable when either np or n(1 minus p) falls below roughly 10, along with which interval you would use instead.
- Take one metric from your day-one tree, write the query that computes it correctly, then write the query that computes it wrong in the most plausible way and explain how you would notice.
Deliverable: Four solved prompts plus a matched correct and plausible-wrong query for one metric.
Practice prompt ↗Practice prompt ↗06Turning engineering work into data science stories
- Write three project stories as situation, decision, trade-off, outcome, each carrying one number and one thing you got wrong.
- For the story you will lead with, prepare an answer to "what would you do differently" that names a decision you made, not a constraint you were handed.
- Practise the sentence that reframes a systems project as a question project: the question the work answered, ahead of the pipeline it shipped.
Deliverable: Three written stories with the lead story delivered aloud and timed under four minutes.
Practice prompt ↗Practice prompt ↗07Mock case and gap list
- Run a 40-minute mock case with someone playing a product manager who pushes back on your metric choice, and record it.
- Listen back and mark every moment you proposed a solution before the success metric existed.
- Rewrite those moments as the question you should have asked, and rehearse the first 90 seconds of the case until scoping comes before solving.
Deliverable: A recorded case plus a rewritten opening 90 seconds.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Most of the questions in this section reduce to one thing: can you be handed a vague request and come back with something useful? Prepare an example where the ask was underspecified, you chose an interpretation, and you said out loud which interpretation you chose. Describing how you narrowed the question matters more than the technique you eventually used.
How do you handle NULL values when performing a LEFT JOIN, and what ar…
How do you handle NULL values when performing a LEFT JOIN, and what are the implications on your final aggregate metrics?
Approach
- Quantify the outcome, including what you would not claim credit for.
- State the situation in two sentences and spend the rest on your reasoning.
- Name the disagreement or constraint, and how you resolved it with evidence.
Follow-up
- What did you decide not to do, and why?
- What would you do differently if you ran that project again?
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?
Describe an analysis you got wrong after a decision shipped
Describe a number you published that turned out wrong, where someone had already made a decision on it. State the mechanism of the error rather than the feeling; how long it was live; who acted on it and what that cost; how it surfaced and whether you were the one who found it; and the control you put in afterwards. An error caught in review before anyone acted does not qualify for this question. Deliverable: three minutes, ending with the one process change that is still in place today.
Approach
- Choose an error with a real mechanism you can draw in one sentence, not a communication miss; the question is probing whether you understand how your own work fails, and a 'they misunderstood my chart' story answers a different question.
- State the blast radius honestly and numerically: days live, decisions taken, dollars or headcount moved. Vagueness here reads as an error you never actually measured.
- Say how it surfaced, including the unflattering version if someone else found it. Claiming self-detection on an error that a stakeholder caught is the fastest way to lose the room.
- Separate the mechanism from the conditions that let it survive: a wrong formula is one bug, but no reconciliation check and no second reader are the reasons it lived for weeks.
- End on a structural control, not an intention. 'I will be more careful' is not a control; a test that fails the job when two computations of the same metric disagree is.
Follow-up
- How soon after you knew did the decision-maker know, and who told them?
- Has the control you added caught anything since, and how would you know if it had silently stopped working?
- What class of error would that control still miss?
- 01
How do you handle NULL values when performing a LEFT JOIN, and what are the implications on your final aggregate metrics?
- 02
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.
- 03
Describe a number you published that turned out wrong, where someone had already made a decision on it. State the mechanism of the error rather than the feeling; how long it was live; who acted on it and what that cost; how it surfaced and whether you were the one who found it; and the control you put in afterwards. An error caught in review before anyone acted does not qualify for this question. Deliverable: three minutes, ending with the one process change that is still in place today.
Is this an official Zillow interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Zillow. Rounds and questions reflect what candidates have reported, not a process Zillow has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the Data Scientist interview process at Zillow?
The interview process is widely considered moderately difficult to highly challenging, primarily due to the depth of the technical screening. Success requires not just writing working code, but demonstrating optimal coding practices and deep mathematical comprehension of your models.
PracHub interview research ↗What is the typical timeline from the initial recruiter screen to a final offer?
The entire process generally takes between three to four weeks. This timeline can vary depending on candidate availability, team-specific requirements, and scheduling logistics for the final panel interviews.
PracHub interview research ↗Does Zillow support remote work or hybrid arrangements for Data Scientists?
Zillow operates with a highly flexible, cloud-first working model, allowing many data science roles to be fully remote within the United States. However, some teams may require occasional travel or alignment with specific regional hubs.
PracHub interview research ↗How can I stand out during the business case study interview?
You can stand out by demonstrating a deep understanding of Zillow's specific marketplace dynamics. Avoid generic answers; instead, frame your solutions around Zillow's actual products, user behaviors, and business challenges.
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.
Whatnot Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at Whatnot candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
Uber Drivers Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Uber Drivers, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
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.
TaskRabbit Data Scientist Interview Questions & Guide 2026
Timed practice for TaskRabbit data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.