As a Data Scientist at TaskRabbit, you are not just analyzing numbers; you are optimizing the connections that power the gig economy. TaskRabbit operates a complex two-sided marketplace connecting "Taskers" (service providers) with Clients (people needing help). Your role is critical in ensuring this marketplace remains healthy, efficient, and equitable.
You will work within the Data organization, often embedded in cross-functional pods alongside Product Managers, Engineers, and Designers. Your work directly influences core product mechanics, such as recommendation algorithms, dynamic pricing models, fraud detection, and supply-demand matching. Because TaskRabbit is part of the IKEA Group, you may also encounter unique opportunities to leverage data in bridging the digital and physical retail worlds, focusing on furniture assembly and logistics.
This position requires a blend of technical rigor and product intuition. You will be expected to uncover insights that drive strategic decisions, whether that means reducing customer churn, improving Tasker retention, or optimizing the "booking funnel." It is a role for someone who enjoys seeing their code and analysis translate into real-world interactions in homes across the globe.
Recruiter Screen
reportedA screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.
What to demonstrate
- Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
- Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
- Whether timeline, location and compensation expectations make the rest of the loop worth scheduling
How to prepare
- Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
- Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
- Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice
Technical Screen
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
Virtual Onsite Loop
reportedWhere a loop includes a partner from outside the data team, that conversation usually carries the same weight as the technical ones and gets the least preparation. The person opposite you will not follow a derivation and does not need to. They are working out whether having you involved would make their decisions better or slower. The failure mode is not being too technical. It is answering a question about a decision with a description of your method, leaving the translation to them. What they carry into the debrief is the sentence you handed them, not the analysis underneath it.
What to demonstrate
- Whether a statistical result arrives as something the partner could act on, with the one caveat that would change their decision kept and the rest left out
- Whether you can state what you need from their side, in their terms: instrumentation that does not exist yet, a definition they own, or a holdout they have to agree to
- Whether uncertainty is given as a range someone can plan against, rather than as hedging that invites them to ignore the result
- Whether you ask what decision is actually on the table before explaining anything
How to prepare
- Take a result you know well and write the version for someone who stops reading after one sentence, then the three-minute version, and check the short one is not the long one with the qualifications stripped out
- For a past project, list everything you asked a non-technical partner for and how you phrased it, then rewrite each ask so it names what goes unmeasured without it
- Practise saying where a result does not apply, out loud, in one sentence that a partner could repeat accurately to someone else
PracHub editorial advice for the preparation topics above.
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.
Treating abandoned requests as missing rather than censored
Consumers who give up before matching are censored observations, so the mean time-to-match computed over matched requests understates true waiting and improves mechanically whenever abandonment rises. A change that makes people quit sooner will look like a latency win. Use survival methods with abandonment as the censoring event, or never report time-to-match without reporting abandonment next to it.
Stopping an experiment the moment it crosses significance
Fix the sample size or duration before launch, or use a method built for continuous monitoring such as a sequential test, always-valid confidence intervals, or group-sequential boundaries. Repeatedly checking a fixed-horizon p-value against 0.05 pushes the real false-positive rate well above 5 percent.
Dropping rows with missing values without naming the mechanism
Say whether the values are missing at random, missing by a known process, or missing in a way that depends on the outcome, and handle them accordingly. Deleting incomplete rows silently redefines the population whenever missingness correlates with what you are measuring.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
"Explain Feature Importance Analysis to a product manager. How do you …
"Explain Feature Importance Analysis to a product manager. How do you determine which variables matter most?"
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Translate the result into the decision it informs, in one plain sentence.
- Sanity-check the answer against a simple bound or a simulated case.
Follow-up
- What sample size would you need to detect an effect half this size?
- How would you explain this result to someone who does not know statistics?
"What is the difference between L1 and L2 regularization, and when wou…
"What is the difference between L1 and L2 regularization, and when would you use each?"
Approach
- Say what the estimate is of, and over what population it generalises.
- Translate the result into the decision it informs, in one plain sentence.
- Sanity-check the answer against a simple bound or a simulated case.
Follow-up
- Which assumption here is most likely to be violated in practice?
- What sample size would you need to detect an effect half this size?
"How would you build a model to predict customer churn?" (Focus on fea…
"How would you build a model to predict customer churn?" (Focus on feature selection, time windows, and defining the target variable).
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.
- Pick an evaluation metric that matches the cost of each error type, not a default.
Follow-up
- What would you monitor after launch to know the model is still valid?
- How would you choose the decision threshold, and who owns that choice?
Trailing 30-day prior-order counts without rolling or asof
You are given orders: order_id, consumer_id, completed_at_utc (tz-aware UTC), about two million rows, one row per completed order. For every order, compute how many completed orders the same consumer had in the 30 days before that order, counting the window as [t - 30 days, t) so the order itself and any exact-timestamp twin are excluded. You may not use groupby().rolling, merge_asof, or apply over groups. Return the input frame, in its original row order and index, with one added integer column prior_30d.
Approach
- Sort once by (consumer_id, completed_at_utc) while keeping the original index, and move to NumPy int64 nanoseconds; the whole problem is two searchsorted calls per group, and a Python loop over two million rows is what makes this fail on time rather than on logic.
- Find group boundaries with np.flatnonzero on a consumer_id change mask instead of iterating a groupby object, then slice the timestamp array per block.
- Within a block, prior_30d[i] = searchsorted(ts_block, t_i, 'left') - searchsorted(ts_block, t_i - 30 days, 'left'), which is exactly the half-open window and needs no special case for the first order.
- State the tie rule out loud: side='left' on the upper bound means simultaneous orders do not count each other, which is the defensible choice when the timestamp has second resolution.
- Scatter the result back through the sort permutation so the added column aligns with the caller's frame, and assert the index is unchanged before returning.
Worked solution 30 min
- order_idx = np.lexsort((ts_ns, consumer_ids)); ts = ts_ns[order_idx]; cid = consumer_ids[order_idx].
- starts = np.concatenate(([0], np.flatnonzero(cid[1:] != cid[:-1]) + 1, [len(cid)])).
- For each block, lo = np.searchsorted(block, block - 308640010**9, 'left'); hi = np.searchsorted(block, block, 'left'); out_block = hi - lo.
- Concatenate block results, then invert: result = np.empty(n, int); result[order_idx] = out_sorted.
- Attach as orders['prior_30d'] and assert the frame's index and row order are identical to the input.
Follow-up
- How does the implementation change if the count must be restricted to the same market?
- This column will feed a model scored at request time. What leakage would you check for, and which timestamp defines the cut-off?
"How would you handle missing data in a dataset of 1 million rows?"
"How would you handle missing data in a dataset of 1 million rows?"
Approach
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
"Write a query to find the top 3 Taskers by revenue in each city for t…
"Write a query to find the top 3 Taskers by revenue in each city for the last month."
Approach
- 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.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
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 table of user logins and task bookings, calculate the daily a…
"Given a table of user logins and task bookings, calculate the daily active users and the conversion rate."
Approach
- 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.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- What breaks if events arrive late or out of order?
- How would you verify this result without re-running the same query?
Rolling 28-day completed orders per active consumer, computed daily
fct_request has request_id, consumer_id, market_id, requested_at_utc. fct_order has order_id, consumer_id, market_id, order_status, completed_at_utc. For each market and each of the last 90 report days, return completed orders whose completed_at_utc falls in the trailing 28 days including the report day, divided by the count of distinct consumers with at least one request in that same 28 days. Emit a row for every report day, including days with no activity. COUNT(DISTINCT ...) as a window aggregate is not available to you.
Approach
- Split the problem on the property that matters: the numerator is additive across days and the denominator is not. Compute them separately and join on (market_id, report_day) at the end.
- Build one per-market calendar that runs from 27 days before the first report day to the last report day, 117 rows per market, and report only the last 90. Both trailing windows read 27 days of history, so a calendar that starts on the first report day under-counts the first 27 rows of the output with no error anywhere.
- Numerator: aggregate completed orders to (market_id, order_day), LEFT JOIN the calendar so empty days exist as rows, then SUM(...) OVER (PARTITION BY market_id ORDER BY day RANGE BETWEEN INTERVAL '27 days' PRECEDING AND CURRENT ROW). The RANGE frame is only safe because the calendar join made every day present.
- Denominator: reduce requests to distinct (consumer_id, market_id, activity_day). Each activity day makes that consumer active on report days d through d+27, and those windows overlap, so naively summing per-activity-day contributions counts a frequent consumer many times over.
- Make the coverage disjoint with LEAD: for activity day d with next activity day d_next, exclusive coverage is d through LEAST(d + 27, d_next - 1), and d through d + 27 when d_next is NULL. Emit +1 at each interval start and -1 the day after its end, then take a running SUM over the calendar to get the distinct active count per day in one pass. Feed the emission from the warm-up days too, or a consumer whose last request predates the window drops out of denominators they still belong in.
- Join numerator to denominator on (market_id, report_day) and divide with NULLIF. Keep both sides on UTC days or convert both to market-local days; using local days on one side and UTC on the other shifts the ratio by up to a day of volume.
- Report the denominator next to the ratio. The ratio falls whenever acquisition succeeds, because new consumers transact less than tenured ones, so the two numbers are only interpretable together.
Worked solution 45 min
- Build the per-market calendar first and confirm it has 117 rows per market, 90 report days plus the 27-day warm-up, zero-activity days included.
- Validate the denominator for one market and one report day against a direct COUNT(DISTINCT consumer_id) with a plain BETWEEN filter; the running-sum answer must match exactly, not approximately.
- Validate the numerator the same way on the same day with a plain range filter.
- Join, divide with NULLIF, and read the 90-day series for step changes that line up with calendar effects rather than product changes.
Follow-up
- The ratio has fallen for six straight weeks while completed orders grew. What is your first hypothesis, and which query separates denominator drift from a real engagement decline?
- A consumer requests in two markets inside the same window. How does your denominator treat them, and do the market denominators sum to a company-level denominator?
"How do you measure the health of a two-sided marketplace?"
"How do you measure the health of a two-sided marketplace?"
Approach
- Fix the population and the time window before naming any metric.
- 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.
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?
"We noticed a drop in the number of completed tasks in NYC last week. …
"We noticed a drop in the number of completed tasks in NYC last week. How would you investigate this?"
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- 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.
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?
Build the provider funnel tree and name the bottleneck
Using dim_user (provider_applied_at_utc, provider_approved_at_utc, provider_status), fct_supply_session and fct_order, build the provider-side metric tree from application to four-week survival. For one weekly cohort the counts are 10,000 applicants, 6,200 approved, 3,100 with a first session within 14 days of approval, 2,480 with a first completed order, and 1,240 still completing orders in week four. Give each stage a numerator, denominator and window, compute the stage rates and the end-to-end rate, and say which stage you would work on and why the largest absolute drop is not automatically the answer.
Approach
- Lay the tree out as sequential conditional rates rather than as shares of the original cohort, so each stage has the previous stage as its denominator and the stages multiply to the end-to-end rate.
- Define each stage with its window attached, because every one of these has a reporting lag: approval rate (denominator = applicants in the cohort week), time-to-first-session within 14 days of approval, first completed order conditional on having a session, and week-four survival defined on completed orders rather than on sessions, since an online provider who completes nothing has not survived in any useful sense.
- Compute: 62.0%, 50.0%, 80.0%, 50.0%, and 1,240 / 10,000 = 12.4% end to end. Confirm the product: 0.62 x 0.50 x 0.80 x 0.50 = 0.124.
- Note that the largest absolute drop is application to approval at 3,800, but approval is a deliberate quality bar, so moving it means changing the bar rather than fixing a leak. The largest addressable drop is approval to first session at 3,100, where the providers have already passed the bar and the platform has already paid the acquisition and vetting cost.
- Say what you would look at inside that stage before proposing a fix: the distribution of days from approval to first session, whether the mass is at day 14 (a slow start that a nudge can move) or spread flat (a decision not to work), and end_reason on the first session for those who started and stopped.
- State the reporting lag the tree forces: a cohort cannot be read before approval plus four weeks, so weekly decisions run on a trailing cohort and early stages are read earlier than late ones.
Worked solution 20 min
- Write the four stages with numerator, denominator and window, each denominator being the previous stage's numerator.
- Compute the four conditional rates: 6200/10000, 3100/6200, 2480/3100, 1240/2480.
- Compute the end-to-end rate two ways: 1240/10000 and the product of the four rates, and confirm they match at 12.4%.
- Rank the stages by absolute loss, then re-rank by addressable loss after removing the policy-set stage.
- Name one diagnostic query for the chosen stage.
Follow-up
- Approval rate rises to 75% next quarter. What do you expect to happen to the three downstream rates, and how would you tell improvement from dilution?
- Would you define week-four survival on sessions or on completed orders, and what does the choice change?
- The first-session stage has a 14-day window. How did you choose 14, and what does a 7-day window do to the number?
Company take rate fell while every market's take rate rose
Monthly net take rate fell from 18.4% to 17.9% company-wide, yet all 46 markets individually improved or held. Net take rate is SUM(gross_booking_cents - provider_payout_cents - consumer_incentive_cents - provider_incentive_cents) / SUM(gross_booking_cents) over completed fct_order rows, per market per calendar month. dim_market carries launched_on, vertical and currency_code. Explain the arithmetic, quantify how much of the decline is mix and how much is within-market, and say which of the two numbers an operating team should be held to.
Approach
- Write the company metric as a weighted mean of market take rates, take_total = sum over m of w_m x take_m, where w_m is that market's share of gross bookings. The weights must be dollars, not order counts, because the metric is a ratio of dollars; weighting by orders yields a decomposition that does not reconcile.
- Apply the exact three-term shift-share: delta take = sum(delta w_m x take_m0) + sum(w_m0 x delta take_m) + sum(delta w_m x delta take_m). Report the interaction term rather than quietly folding it into one side.
- Rank markets by delta w_m x (take_m0 - take_total0) to name which cells are doing the mixing. Recently launched markets with heavy incentive intensity are the usual source, since their take rate is structurally lower while their share is growing fastest.
- Fix the currency basis before summing. fct_order amounts sit in the market's own currency per dim_market.currency_code, so any cross-market sum needs a rate; holding the rate at its month-zero value separates real weight shifts from FX movement.
- Publish both series: the raw company number, and a mix-adjusted number computed by holding w_m at a stated reference month. Say plainly which one operating teams are accountable for and which one the P&L actually sees.
Follow-up
- A market launched mid-month. Does it belong in either month's weights, and what does including it do to the interaction term?
- Leadership wants a single headline number. Which do you give them, and what do you put beside it?
Four days spend equal time on query work, statistics, modelling and product judgement at deliberately shallow depth, which produces a scored map of where you actually stand. The last three days spend everything on the two areas the role weights most, and close by re-running day one to measure movement.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Breadth pass: query fluency
- Solve six prompts spanning aggregation, joins, window functions and date arithmetic in 60 minutes total, stopping at 10 minutes each whether or not it works, and mark every prompt as solved, solved slowly, or stuck.
- For each unsolved prompt write the single blocking sentence (I lost the grain, I did not know the frame clause, I could not express the date boundary) instead of reading the solution.
- Translate one pandas transformation you know well into SQL and one SQL query into pandas, checking that both return the same row count and the same totals.
Deliverable: A scored six-row table, one line per prompt, saved for the day-seven re-run.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Breadth pass: statistics and inference
- Answer ten short questions in writing with nothing open: what a p-value is conditional on, what a 95 percent interval covers across repeated samples, when a paired test is the right one, what the bootstrap estimates, why multiple comparisons inflate false positives, how controlling the family-wise error rate differs from controlling the false discovery rate, what power depends on, what a missed real effect costs a product, the three situations where the central limit theorem does not rescue you (small n, very heavy tails, dependent observations), and what a standard error is the standard deviation of.
- Grade yourself against a reference and count only the answers that were exactly right, not the ones that were nearly right.
- Rewrite the two weakest answers the following morning from memory in full sentences.
Deliverable: Ten graded answers with an honest count of exact hits.
Practice prompt ↗Practice prompt ↗03Breadth pass: modelling
- Take one tabular dataset end to end in 90 minutes: a leakage-safe split, a baseline that is not a model (majority class or historical mean), one regularized linear model, one gradient-boosted tree, and a single evaluation metric chosen before you look at any result.
- Write why that metric fits the cost structure: precision at a fixed recall for alerting, calibration for anything feeding a price or a threshold, ranking metrics for retrieval, and note that area under the ROC curve is insensitive to class balance in a way that can flatter a rare-positive problem.
- Name the leak you were most likely to introduce (an encoding fit on all rows before splitting, or a feature computed after the label's timestamp) and write the check that would have caught it.
Deliverable: A notebook whose first cell states the metric and the baseline, plus two lines on what beat what and by how much.
Practice prompt ↗Practice prompt ↗04Breadth pass: product judgement
- Answer three case prompts aloud at 15 minutes each, timing how long passes before you state a success metric.
- For one case write the first segmentation you would run and the row counts you expect per segment, so that a tiny segment cannot quietly drive the conclusion.
- Take a metric definition you did not write, from a public dashboard, a textbook, or documentation you already have open, and list every place two analysts implementing it would diverge: which rows the denominator admits, whether the unit is an account or a person, what the time window is anchored to, and what happens to data that arrives late. Then write the one question that would close the largest of those gaps.
Deliverable: Three recorded case answers plus an ambiguity list for a metric someone else defined, ending in the single question you would ask about it.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Depth, first area
- Rank the four areas by how many bullet points in the role description each one covers, pick the top one, and spend the entire day inside it.
- Work the six hardest problems you can find in that area and for each write the generalizable move you should have reached for first, rather than the answer.
- Re-solve the two you failed the same evening with notes closed.
Deliverable: Six generalizable moves written as instructions to yourself, not as solutions.
Practice prompt ↗Practice prompt ↗06Depth, second area, and the seam between them
- Repeat the depth protocol on the second-ranked area with the same six-problem structure.
- Construct one problem that requires both areas at once, for example a metric redefinition whose effect you must validate with a test whose readout you then have to query.
- Solve your own combined problem end to end and note where the handoff between the two areas cost you time.
Deliverable: One combined problem, solved end to end, with the handoff failure written down.
Practice prompt ↗Practice prompt ↗07Integration and re-measurement
- Re-run the six prompts from day one under the same clock and compare both correctness and time.
- Run a 60-minute mixed mock that moves between areas without warning, since switching cost is what breadth passes do not train.
- Write the two areas you would still fail on, and the sentence you will use in the interview when you hit one of them.
Deliverable: A before-and-after score table plus a written plan for the two remaining gaps.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Data people depend on systems owned by other teams, and much of the job is negotiating for instrumentation, access, or a fix to a broken pipeline. Prepare an example of getting something changed upstream that you did not control. Describe what you asked for, what you traded, and how you worked while you waited.
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?
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?
Turn a one-line supply request into a scoped analysis
A cross-functional lead messages: 'can you look into whether we have enough drivers in the north zone?' No metric, no deadline, no stated decision. You have fct_supply_session (online_seconds, engaged_seconds, idle_seconds, market_id, offline_at_utc), fct_request (request_status, requested_at_local, market_id, dispatch_attempts) and dim_market (timezone). Deliverable: the three questions you ask before touching data, then a scoping note under 150 words naming the decision it serves, the one number that answers it with numerator, denominator and window, the first cut you run, and the date you return.
Approach
- Ask what lever is being considered, because 'enough supply' has no definition independent of the action: a provider incentive budget, a dispatch radius change and a recruiting target each need a different number and a different window.
- Ask what happens if the answer is 'yes, enough', since a question with the same action under both answers is not worth running, and ask when the decision is made, which sets the depth you can afford.
- Translate the vague word into a measurable pair with opposite signatures: share of requests with request_status = 'no_supply' plus provider utilisation (SUM(engaged_seconds) / SUM(online_seconds)) by market-hour. High utilisation with rising no_supply is supply-constrained; high idle_seconds with flat request counts is demand-constrained.
- State the data handling that changes the answer: clip open sessions (offline_at_utc IS NULL) at the window edge rather than dropping them, and cut by requested_at_local using dim_market.timezone, because supply shortage is an hour-of-day phenomenon that a UTC cut smears away.
- Commit to a first cut and a return date, and name explicitly what you are not doing, so the scope can be argued with before the work rather than after it.
Follow-up
- The lead says 'just give me the driver count' - how do you respond without refusing the request?
- What single additional table would let you distinguish a dispatch problem from a genuine supply shortage?
- How does your answer change if the zone is one part of a market rather than a market_id of its own?
- 01
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.
- 02
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.
- 03
A cross-functional lead messages: 'can you look into whether we have enough drivers in the north zone?' No metric, no deadline, no stated decision. You have fct_supply_session (online_seconds, engaged_seconds, idle_seconds, market_id, offline_at_utc), fct_request (request_status, requested_at_local, market_id, dispatch_attempts) and dim_market (timezone). Deliverable: the three questions you ask before touching data, then a scoping note under 150 words naming the decision it serves, the one number that answers it with numerator, denominator and window, the first cut you run, and the date you return.
Is this an official TaskRabbit interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at TaskRabbit. Rounds and questions reflect what candidates have reported, not a process TaskRabbit has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult are the technical rounds?
The technical rounds are generally described as "Medium." They are fair and practical. You won't typically see dynamic programming hard-level LeetCode questions, but you *will* need to write flawless SQL and demonstrate a deep understanding of ML fundamentals.
PracHub interview research ↗What is the work-life balance like for the Data team?
TaskRabbit is well-regarded for its work-life balance. Reviews highlight generous PTO, company-wide closure weeks, and a supportive culture. While there can be "thrash" or shifting priorities, the company generally respects personal time.
PracHub interview research ↗Is the role remote or hybrid?
The role follows a Hybrid model. You are generally expected to be in the office (typically SF, NYC, or London) about 2 days per week. This is to foster collaboration and team cohesion.
PracHub interview research ↗What differentiates a top candidate from an average one?
A top candidate connects the data to the user story. Instead of just building a model with 95% accuracy, they ask, "Does this model actually help a Client get their furniture assembled faster?" They show empathy for the Taskers who rely on the platform for income.
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.
Zillow Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Zillow, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
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.