As a Data Scientist at Prosper Marketplace, you are at the intersection of financial technology and advanced analytics. You are responsible for building and refining the models that power Prosper Marketplace's lending platform, directly influencing its risk assessment, credit scoring, and customer experience. Your work transforms raw data into actionable insights that help Prosper Marketplace maintain its marketplace while providing fair and transparent financial solutions to its users.
This role is critical to the business because it bridges the gap between complex statistical theory and real-world financial impact. You will collaborate closely with engineering, product, and operations teams to deploy models that operate at scale. Whether you are optimizing conversion funnels or enhancing the precision of Prosper Marketplace's underwriting engines, your contributions affect the company’s bottom line and the financial health of its members.
Preparation focus
editorialNo round sequence has been reported for this company, so work the categories below and confirm the format with your recruiter.
What to demonstrate
- Breadth across SQL, experimentation and product reasoning
- Ability to state assumptions before choosing a method
How to prepare
- Drill the practice exercises below and time yourself
- Prepare three quantified stories about decisions you drove
PracHub 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.
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.
Averaging per-user rates to produce a population rate
Decide which quantity you want: the mean of per-user ratios and the ratio of summed numerator to summed denominator are different estimands, and heavy users dominate one but not the other. For a ratio metric, aggregate numerator and denominator separately and use the delta method for its variance.
Reading an observational correlation as a causal effect
Name the confounder you are most worried about and the design that would remove it: an experiment, a difference-in-differences with a checked pre-period trend, an instrument, or a regression discontinuity. When none is available, state which direction the bias likely runs and bound the claim accordingly.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How would you handle missing values in a large dataset before feeding …
How would you handle missing values in a large dataset before feeding it into a model?
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.
- Say how the offline result would be validated online before it is trusted.
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?
Sessionise a provider heartbeat stream into supply sessions
You are given pings: provider_id, market_id, event_at_utc, status in ('idle','en_route','engaged','offline'), one row per app heartbeat, nominally every 30 seconds but with gaps. Reconstruct the supply-session table. A session starts at the first non-offline ping and ends at an explicit offline ping, at a market change, or when the gap to the next ping exceeds 10 minutes. Produce session_id, provider_id, market_id, online_at, offline_at, online_seconds, engaged_seconds, en_route_seconds, idle_seconds and end_reason, with the three state components summing to online_seconds exactly in integer seconds.
Approach
- Sort by (provider_id, event_at_utc), then build a new_session boolean: first ping of a provider, previous status equals 'offline', market_id changed, or the gap from the previous ping exceeds 600 seconds. A cumsum over that boolean is the session key, and it removes any need for a per-provider Python loop.
- Attribute duration to intervals, not to pings: each ping owns the seconds until the next ping inside the same session, and the final ping owns a capped 30 seconds. Because the state seconds are the intervals themselves, they sum to online_seconds by construction rather than by a correction step.
- Encode the three terminations distinctly. Gap timeout ends at last_ping + 30s with end_reason 'app_background_timeout'; an explicit offline ping ends at that ping with 'manual_offline'; a session with no terminating event before the data ends is 'session_still_open' with offline_at NaT.
- On a market change, close the old session at its last ping in the old market and open the new one at the first ping in the new market; the seconds in between belong to neither session, and the output should say so rather than quietly padding one side.
- Aggregate with a single groupby on the session key, pivoting the per-interval state into the three second columns, then assert the sum identity and that consecutive sessions for one provider never overlap.
Worked solution 40 min
- Sort, then compute gap = event_at_utc.diff() per provider and prev_status / prev_market via shift(1) within provider.
- new_session = provider changed | prev_status == 'offline' | market changed | gap > 600s; session_key = new_session.cumsum().
- interval_seconds = next_event_at - event_at within session, with the last row of each session clipped to 30 seconds; drop rows whose own status is 'offline' from the state attribution.
- Group by session_key: online_at = first event_at, offline_at from the termination rule, and sum interval_seconds overall and per status via a pivot.
- Assert engaged + en_route + idle == online_seconds with integer equality, and assert non-overlap per provider before returning.
Follow-up
- A provider is engaged on a 40-minute order and the app backgrounds mid-order. What does your 10-minute rule do to that session, and what does it do to utilisation?
- Utilisation divides engaged by online. Which of your three end_reason cases biases it most, and in which direction?
Decompose completed-order change into requests, fill, completion
You are given panel: market_id, period ('base' or 'current'), requests, matched, completed, one row per market per period. Completed orders satisfy C = R * f * c where f = matched/requests and c = completed/matched. Write decompose(panel) returning, per market, the contribution of the change in R, f and c to the change in C under two methods: the sequential chain rule with its interaction terms written out, and the log-mean (LMDI) decomposition. Contributions must sum to the change in C to floating-point tolerance under both methods. Handle a market with zero requests or zero matched in one period.
Approach
- Write the sequential identity before coding and confirm it telescopes: dC = (R1-R0)f0c0 + R1*(f1-f0)c0 + R1f1*(c1-c0) expands exactly to R1f1c1 - R0f0c0. It is exact but order-dependent, and the interaction terms live wherever the chosen order puts them.
- Implement LMDI with the logarithmic mean L(a,b) = (a-b)/(ln a - ln b) and L(a,a) = a: the contribution of R is L(C1,C0)*ln(R1/R0), and likewise for f and c. It is exact and order-independent, which is why it is the one to use when two factors move together.
- Handle the degenerate cases in code rather than in a comment: zero requests, zero matched (c undefined), and equal values hitting the log-mean's removable singularity. Return NaN with a reason column instead of a silent zero.
- Assert additivity per market with np.allclose on the sum of contributions minus the change in C, and raise if it fails; a decomposition that does not close is not a decomposition.
- Roll up by summing contributions across markets, since sums of exact per-market decompositions stay exact, and report the aggregate rates separately because they will not equal the request-weighted per-market rates once the market mix has moved.
Follow-up
- Requests are flat, fill fell two points, completed fell six percent. What do you query next to separate fewer online hours from worse dispatch?
- Aggregate fill rate fell while every single market's fill rate rose. Write the mix term that reconciles those two facts.
- Which of the two decompositions would you put in a recurring report, and what would you have to explain to its readers every month?
How do you ensure your code is modular and easy for other data scienti…
How do you ensure your code is modular and easy for other data scientists to maintain?
Approach
- State the window function and its partition and ordering out loud before writing it.
- Say which table is the grain you start from, and join outward from it.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- How does the query change if the join becomes one-to-many?
- What breaks if events arrive late or out of order?
Write a SQL query to identify the top three performing cohorts by loan…
Write a SQL query to identify the top three performing cohorts by loan default rate.
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- 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.
Follow-up
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
Describe a situation where you had to debug a production-level script …
Describe a situation where you had to debug a production-level script under a deadline.
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.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Follow-up
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
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?
Explain the time complexity of your Python solution and how you would …
Explain the time complexity of your Python solution and how you would optimize it for a larger dataset.
Approach
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
- 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?
- Which segment would you cut first, and what would that rule out?
Decide a price cut when guardrail and north star diverge
A market proposes cutting base_price_cents by 10%, holding the take rate fixed so provider_payout_cents per completed order falls 10% too. The forecast is requests +18%, completed orders +12%, and online hours roughly flat for the first four weeks. Completed orders per active consumer rises; provider earnings per online hour falls unless volume per hour compensates. State the exact breakeven for the guardrail, give the decision rule you would apply, and name the evidence from the first two weeks that would reverse it. Supply responds over weeks, not days.
Approach
- Write the guardrail as an identity before touching the forecast: provider earnings per online hour = (completed orders per online hour) x (earnings per completed order). Any argument about this trade-off is an argument about which factor moves more, so make the identity explicit.
- Solve the breakeven: earnings per order falls to 0.90 of baseline, so completed orders per online hour must reach 1 / 0.90 = 1.111, a rise of 11.1%, to hold hourly earnings flat.
- Apply the forecast: orders +12% with flat online hours gives 1.12 x 0.90 = 1.008, so hourly earnings rise about 0.8%. The forecast clears the breakeven by roughly one point, which is inside forecast error, so the correct statement is that the guardrail is neutral rather than positive.
- Run the sensitivity that decides the question: if online hours rise 5% because providers respond to higher volume, orders per online hour becomes 1.12 / 1.05 = 1.0667, and 1.0667 x 0.90 = 0.96, a 4% fall in hourly earnings. The sign of the guardrail is set by the supply response, not by the demand response.
- State the decision rule in a form someone can act on: proceed only with a pre-registered supply floor (for example, halt if earnings per online hour falls more than 3% against the matched control for two consecutive weeks) and only if the cut is tested in a subset of markets rather than launched, because a four-week read on a supply intervention measures the demand response and almost none of the supply response.
- Close the escape hatch explicitly: defending hourly earnings with provider incentives converts a pricing decision into a spend decision, and that spend lands in contribution margin per completed order, which is the guardrail on the other metric. Say this before someone proposes it.
Worked solution 35 min
- Write the earnings-per-hour identity and confirm both factors are computable from fct_supply_session and fct_order.
- Compute the breakeven: 1 / 0.90 = 1.111, so +11.1% orders per online hour.
- Evaluate the central forecast: 1.12 x 0.90 = 1.008, hourly earnings +0.8%.
- Re-run with online hours +5%: 1.12 / 1.05 = 1.0667; 1.0667 x 0.90 = 0.96, hourly earnings -4.0%.
- Write the decision rule with a numeric halt condition and the measurement horizon it requires.
- Add the note that an incentive backstop moves the cost into contribution margin per completed order rather than removing it.
Follow-up
- Providers respond over weeks. What would you measure at week eight that is uninformative at week two?
- The market wants to hold hourly earnings flat with a temporary bonus. What does that do to the payback calculation, and how would you report it?
- How would you randomise this given that price is market-visible and providers talk to each other?
A fill-rate step change that no dispatch change caused
SLA fill rate rose 2.3 points on a single day in every market at once and held there. A dispatch radius change shipped that same week, but only in three markets. The metric is requests matched within the market's SLA divided by all requests created, excluding requests abandoned within 10 seconds of creation. Decide whether the step is a real improvement, and give the one plot that distinguishes a definition change from a behaviour change.
Approach
- Start from the simultaneity. Marketplace behaviour does not step in every market on the same minute. A change that lands everywhere at once is a code, config or definition change; a real dispatch change appears only in the three markets that received it, and usually with a ramp.
- Plot the numerator count and the denominator count on the same axis instead of plotting the rate. A definition change normally moves exactly one of them by a level shift, and the 10-second exclusion moves the denominator down while leaving the numerator flat, because a request abandoned inside 10 seconds was never matched and so was never in the numerator.
- Backfill one definition across the whole window; do not difference the two definitions day by day. Old and new differ by the 10-second exclusion, which applies on every day of history, so the two series sit apart throughout the window and their gap dates nothing. The diagnostic is single-definition continuity: recompute the entire window under the new definition, then again under the old one. If each single-definition series runs continuously through the step date while the published series steps, the definition changed that day and history was never restated. If the step survives under a consistently applied definition, the data or the behaviour moved and the definition is not the story.
- The gap between the two definitions is still worth plotting, for its level rather than its timing. It should sit near the historical share of requests abandoned within 10 seconds of creation and stay roughly flat across the window. A gap that itself jumps at the step date means the excluded population changed as well, which is a data change wearing a definition change's clothes.
- Read the SLA source. The threshold is per market, so an edit to the SLA config, or a new market silently inheriting a default, shifts the numerator with a flat denominator, which is the opposite signature.
- Only once the step is explained should you evaluate the dispatch change, and then strictly inside the three treated markets against the untreated ones over the same days, both computed under one definition.
Follow-up
- How do you report a metric whose definition changed mid-quarter without restating history as an improvement?
- What would you require of any future metric change so this is unambiguous on day one?
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 ↗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 ↗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 ↗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 ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Half of this section is about translation. Be ready to describe how you explained a result to someone who did not want the method, only the implication, and what you did when the simplified version started being repeated in a way that overstated it. Correcting your own simplification is a strong beat.
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?
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?
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?
- 01
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.
- 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
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.
Is this an official Prosper Marketplace interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Prosper Marketplace. Rounds and questions reflect what candidates have reported, not a process Prosper Marketplace has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How long should I prepare for the technical interviews?
Plan for at least 2–3 weeks of focused practice. Refresh your knowledge of both SQL syntax and core machine learning concepts, and practice coding under time constraints.
PracHub interview research ↗What differentiates successful candidates?
The most successful candidates are those who demonstrate not just technical skill, but also a deep interest in the fintech domain. They ask insightful questions about Prosper Marketplace's business model and how their work connects to the user experience.
PracHub interview research ↗Is there a specific "Prosper Marketplace" way of doing things?
Candidates report that the interviews reward transparency and rigor. Strong candidates show work that is methodical, well-documented, and focused on delivering real value to users.
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.
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.
Grubhub Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for Grubhub data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.