A Data Scientist at Fiverr plays a pivotal role in shaping the future of the world's leading marketplace for freelance services. At its core, Fiverr is a complex, two-sided ecosystem where millions of buyers and sellers interact daily. Data scientists are tasked with solving highly sophisticated problems that directly impact how these users discover, communicate, and transact with one another. By leveraging massive datasets, you will design and deploy algorithms that power search relevancy, recommendation engines, pricing optimization, and trust and safety protocols.
The impact of this role is immediate and highly visible. Unlike traditional tech companies where data science can sometimes be siloed, Fiverr integrates data scientists directly into product, engineering, and business verticals. Whether you are working on understanding user intent through advanced Natural Language Processing (NLP), optimizing the search ranking algorithms, or mitigating marketplace fraud, your models will directly influence the company’s bottom line and the user experience of millions worldwide.
What makes this role particularly exciting is the sheer diversity of the data. You will work with rich, unstructured text from gig descriptions, search queries, user reviews, and transaction histories. To succeed, a Data Scientist at Fiverr must possess not only exceptional technical and mathematical rigor but also a deep curiosity about human behavior and marketplace dynamics.
HR Recruiter Call
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
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
Practical Assignment
reportedA take-home is graded as an argument, not as a notebook. Somebody reads the submission without you in the room, so every choice has to survive on the page: why the question was framed this way, and what was deliberately left out. The gap between a strong and a weak submission is almost never model quality. It is whether the writeup names the specific question it answers and commits to a recommendation, including what evidence would overturn it. A high-accuracy model attached to no conclusion reads as effort that stopped before the decision.
What to demonstrate
- Whether the question you answered is stated outright, and whether it is the question the prompt posed rather than an easier neighbour of it
- Whether the recommendation is specific enough to act on, with the uncertainty attached to it instead of parked in a caveats section at the end
- Whether analytical choices such as the metric definition, the population filter and the time window are justified in the prose, not merely visible in code
How to prepare
- Take a dataset you have already worked with, write the one-paragraph conclusion first, then check whether the analysis you were planning actually supports it and cut whatever does not
- Practise stating a metric in one sentence that fixes the population, the time window and the denominator, then confirm your query computes exactly that sentence and nothing adjacent to it
- Hand a draft to someone outside the problem and ask them to tell you back what you recommended and why; anything they cannot recover is not on the page yet
Onsite Panel Interview
reportedA loop is not scored one interview at a time. The people you meet compare notes afterwards, usually in a meeting you are not in, and the outcome turns on what each of them can say about you when asked. That rewards something other than survival: every room needs one specific thing worth repeating, and none of them can contradict another. The common way to lose is to tell the same project four times with different numbers in it, or to be uniformly fine in a way that leaves nobody with anything to argue for.
What to demonstrate
- Whether your account of a project survives being told twice, with the same scale, the same metric definition and the same numbers each time
- Whether each interviewer leaves with one concrete claim they could make on your behalf later, rather than an absence of complaints
- Whether a question you already answered in an earlier room gets the same answer at the same depth, without visible impatience
How to prepare
- Write a one-page fact sheet for your two or three main projects that fixes the numbers you will quote: rows of data, the metric as a single sentence, the effect you measured and how long the work took. Say them aloud from the sheet until they come out identical every time
- For each kind of room you expect, decide the one sentence you want that interviewer repeating in a debrief, then check during the mock that you said it outright instead of implying it
- Rehearse answering the same project question twice in one sitting, the second time as though you had not just answered it, because the thing that needs fixing is the flatness that creeps into a repeated story
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.
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.
Ignoring interference between units in a marketplace experiment
Ask whether one unit's treatment can change another unit's outcome through shared inventory, a matching pool, a social graph or a common budget. Where it can, randomise at a level that contains the spillover, such as region or time slice, and say explicitly what that costs you in statistical power.
Generalising beyond the population the sample actually supports
State the frame the sample was drawn from and where it diverges from the population you want to talk about: time window, platform, geography, opt-in. If a group is excluded from the frame, either weight to known margins or narrow the claim rather than quietly extending it.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How would you design a classification model to identify and flag spam …
How would you design a classification model to identify and flag spam or policy-violating gig descriptions?
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?
- Where could label leakage enter this setup?
How would you build a model to predict user churn for buyers who haven…
How would you build a model to predict user churn for buyers who haven't made a purchase in the last six months?
Approach
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Say how the offline result would be validated online before it is trusted.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- Where could label leakage enter this setup?
- 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?
Write a function to clean and tokenize a messy user-generated gig titl…
Write a function to clean and tokenize a messy user-generated gig title, removing stop words and special characters.
Approach
- 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.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
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?
Implement a function to calculate the rolling average of user click-th…
Implement a function to calculate the rolling average of user click-through rates within a specific time window.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- 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?
Given a list of search query logs, write an efficient algorithm to fin…
Given a list of search query logs, write an efficient algorithm to find the top $K$ most frequent search terms.
Approach
- 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.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- How would you verify this result without re-running the same query?
- What breaks if events arrive late or out of order?
Allocate session time to local market-hours for utilisation
fct_supply_session has provider_id, market_id, online_at_utc, offline_at_utc (NULL while open), online_seconds, engaged_seconds, en_route_seconds, idle_seconds, where engaged plus en_route plus idle equals online. dim_market has market_id and timezone as an IANA name. Produce provider utilisation, engaged seconds over online seconds, per market per local hour for one week. Sessions cross hour boundaries and can run for hours, and open sessions must be clipped to the window end rather than dropped. The engaged total is per session with no timestamps, so state and defend your allocation rule.
Approach
- Pick one direction for time and stay in it: either generate the hour grid in market-local time and convert each bucket back to UTC for the overlap test, or convert each session once with (online_at_utc AT TIME ZONE 'UTC') AT TIME ZONE m.timezone. Mixing the two is where daylight-saving errors enter.
- Clip with overlap_seconds = EXTRACT(EPOCH FROM (LEAST(session_end, bucket_end) - GREATEST(session_start, bucket_start))), keeping only positive overlaps. COALESCE an open session's end to the window end before this so it contributes to the hours it genuinely covered instead of vanishing on a NULL comparison.
- Allocate engaged time by pro-rating: engaged_seconds * overlap_seconds / online_seconds. Say explicitly that this assumes engagement is uniform within the session, which smooths real peaks; an exact allocation needs an engagement event stream this table does not carry.
- Aggregate by summing allocated engaged and allocated online per market-hour and dividing the sums. Averaging per-session ratios into the hour weights a 12-minute session the same as a 6-hour one.
- Handle daylight saving deliberately. In a market-local series the spring-forward day has 23 local hours and the autumn day has 25, so a grid built by adding 24 rows per day either loses an hour or folds two distinct hours into one label.
Worked solution 40 min
- Take one session that crosses four hour boundaries and compute its four overlaps by hand; they must sum to its clipped duration.
- Build the bucket grid for one market and one day and count the rows: 24, except on the two daylight-saving days.
- Join, clip, pro-rate and aggregate, then compare summed allocated online seconds against summed clipped session durations for the market.
- Divide the sums and read one market-day as a series to check the shape against known demand peaks before trusting the whole week.
Follow-up
- How does uniform pro-rating bias a comparison between a market with long sessions and one with short ones?
- If you could add one column to fct_supply_session to make this exact, which would it be, and what does collecting it cost at this event volume?
How would you optimize a Python script that processes millions of rows…
How would you optimize a Python script that processes millions of rows of user transaction data to minimize memory usage?
Approach
- 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.
- 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?
- Which segment would you cut first, and what would that rule out?
If conversion rates suddenly drop on the checkout page, how would you …
If conversion rates suddenly drop on the checkout page, how would you investigate the root cause using data?
Approach
- 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.
- 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?
- Which segment would you cut first, and what would that rule out?
Choose one health metric for a single market week
A market lead wants one number on the weekly review slide for one market. They propose gross bookings. Last week in that market a 12.5% surge-driven price rise coincided with completed orders falling 4%, so gross bookings rose 8%. Using fct_request, fct_order and dim_user, propose a replacement. Give numerator, denominator, window and exclusions explicitly, name one guardrail, and say in one sentence why you rejected gross bookings and why you rejected raw signups. Do not propose a dashboard; propose one primary number and one guardrail.
Approach
- Name the decision the number serves before defining it: this slide decides whether the market gets more incentive budget next week, so the number has to move only when the market actually clears more orders at a defensible cost.
- Show arithmetically why gross bookings fails: 1.125 x 0.96 = 1.08, so an 8% rise is consistent with 4% fewer completed orders. A level metric that is price times volume cannot separate the two, and price is a lever the team controls.
- Define the replacement fully: completed orders per active consumer over the trailing 28 days, numerator = count of fct_order rows with order_status = 'completed' and completed_at_utc in the window for that market_id, denominator = distinct consumer_id in fct_request with requested_at_utc in the same window and the same market_id. State the exclusion for the documented 10-second mis-tap requests so the denominator matches the fill-rate definition.
- Attach the guardrail that blocks the cheap route: contribution margin per completed order, because the fastest way to raise orders per active consumer is a credit that never pays back, and the margin metric prices exactly that.
- Flag the known weakness out loud: this rate falls when acquisition succeeds, because new cohorts transact less than tenured ones, so report the denominator next to the rate and read frequency by tenure bucket before calling a decline an engagement problem.
Worked solution 20 min
- Write the decision the slide supports in one line, then list three candidate numbers: gross bookings, completed orders, completed orders per active consumer.
- Test each candidate against the given week: multiply 1.125 by 0.96 and confirm gross bookings rose 8% while the market served fewer orders.
- Write the surviving candidate as numerator, denominator, window and exclusions, naming the exact tables and columns.
- Write the guardrail with the same rigour, sourcing refunds, chargebacks and processing fees from fct_money_movement attributed to the order's completion month.
- Write one sentence beginning 'this breaks if' for the primary metric and confirm the guardrail blocks that route.
Follow-up
- The market runs a two-week promotion. Which of your two numbers moves first, and what would you expect the second to do in week three?
- If you could add exactly one more number to the slide, is it a supply-side metric or a consumer-side one, and what does it buy you?
- How would you handle a week where one large zone was closed for an event?
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 a candidate whose interviews will centre on A/B testing, metric movement and causal claims. Design comes before arithmetic, arithmetic before analysis, and the week ends by rehearsing the readout rather than the derivation.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Design one test end to end on paper
- Take a single feature change and write the full design: randomization unit, the exact point of exposure, the primary metric with its grain, guardrails, allocation, planned duration, and the decision rule committed before any data exists.
- Write why the randomization unit must sit at or above the level where treatment can spill over, and give one case where user-level randomization is still contaminated (shared accounts or devices, or two participants in the same marketplace).
- State in advance what you will do if the primary metric is flat while a secondary metric is significant.
Deliverable: A one-page test design with a decision rule written before launch.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Power arithmetic until it is automatic
- Compute required sample size per arm for a binary metric with the normal approximation, n is approximately 2 times (z for alpha/2 plus z for power) squared times p(1 minus p) divided by delta squared, for baselines of 2, 10 and 40 percent at a 5 percent relative lift, and note that for a fixed relative lift the requirement falls as the baseline rises because delta grows proportionally with p.
- Redo the calculation for a continuous metric using variance in place of p(1 minus p), and show why a heavy-tailed quantity such as revenue per user needs either far more traffic or a capped version with a stated cap.
- Convert one of the results into weeks given a weekly eligible traffic figure, then list the two honest ways to shorten it (accept a larger detectable effect, or reduce variance) and write why quietly lowering the power target is a decision to miss more real wins, not a speedup.
Deliverable: A small script or sheet that maps baseline, minimum detectable effect, alpha and power to sample size and weeks, cross-checked against a published calculator.
Practice prompt ↗Practice prompt ↗03Variance and the unit-of-analysis problem
- Take a ratio metric whose denominator is not the randomization unit (clicks per session, randomized by user) and compute the standard error twice, once naively at session level and once by the delta method or a user-level bootstrap, then record how much the naive version understates it.
- Implement CUPED on simulated data: choose a pre-period covariate X measured before assignment, estimate theta as Cov(Y, X) divided by Var(X), and analyse Y minus theta times (X minus its mean) in place of Y. Confirm the variance of the adjusted outcome equals the raw variance multiplied by one minus the squared correlation between Y and X, so a correlation of 0.45 removes about 20 percent of the variance and not 80.
- Now run that simulation a few hundred times and confirm the adjusted effect estimate is unbiased for the same effect rather than numerically identical to the raw one. Within any single run the two differ, sometimes by a large fraction of the true effect, because the two arms' pre-period covariate means never coincide exactly in a finite sample; they agree in expectation, which is the property that matters and the one to state out loud.
Deliverable: A notebook showing the adjusted estimator with a measurably smaller variance than the raw one, plus a repeated-simulation table showing the two estimators agreeing on average while differing run by run.
Practice prompt ↗Practice prompt ↗04Validity threats you can actually test for
- Run a sample ratio mismatch check as a chi-square goodness-of-fit test against the intended allocation, and write the three causes you would chase first (assignment logged before exposure, an arm-specific redirect or load failure, bot filtering applied asymmetrically).
- Simulate peeking: generate A/A data, test daily at alpha 0.05 across 14 looks, record the inflated false positive rate, then apply an alpha-spending boundary or commit to a fixed horizon and confirm the rate returns to nominal.
- Write how you would separate a novelty effect from a durable lift using the treatment effect plotted against days since first exposure, and what shape would change your recommendation.
Deliverable: One table showing the peeking false positive rate before and after correction, plus a written SRM triage list.
Practice prompt ↗Practice prompt ↗Worked solution ↗05When randomization is not available
- Write the identifying assumption for difference-in-differences (parallel trends in the absence of treatment), then plot pre-period trends for two candidate control groups and justify rejecting one of them.
- Design a switchback test for a change where user-level randomization would leak across participants, choosing a time-block length against the carryover you expect and saying how you would detect carryover in the data.
- List what an interrupted time series or a synthetic control buys you and the one thing neither can rule out: an unobserved shock that coincides with the launch.
Deliverable: A one-page memo recommending a single quasi-experimental design and naming its weakest assumption explicitly.
Practice prompt ↗Practice prompt ↗06The readout query
- Write the assignment-to-exposure join that returns exactly one row per unit per experiment, and handle units appearing in both arms by excluding and counting them rather than silently keeping one.
- Compute the per-arm metric, its variance and the relative lift with a confidence interval in SQL, then reproduce the identical numbers in a notebook as a cross-check.
- Add a segment breakdown and write the sentence that keeps it from being p-hacking: segments declared in advance, everything else reported as exploratory and corrected for multiplicity.
Deliverable: A single query that outputs the full readout table, matched to a notebook recomputation.
Practice prompt ↗Practice prompt ↗07Present it to someone who will not read the appendix
- Give a 10-minute readout of a real or simulated experiment in the order decision, number, uncertainty, caveat.
- Have your listener ask "can we ship it" in the case where the primary is flat and a guardrail moved, and answer with a recommendation rather than a request for more data.
- Rewrite your opening line so the recommendation lands before any methodology.
Deliverable: A one-page readout whose first line is the recommendation.
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.
How do you handle high-cardinality categorical features, such as gig c…
How do you handle high-cardinality categorical features, such as gig categories or user locations, in a gradient-boosting model?
Approach
- Name the disagreement or constraint, and how you resolved it with evidence.
- Quantify the outcome, including what you would not claim credit for.
- State the situation in two sentences and spend the rest on your reasoning.
Follow-up
- What would you do differently if you ran that project again?
- What did you decide not to do, and why?
Quantify your own impact without claiming the metric movement
At review you are asked what your work was worth this year. Your largest project was a dispatch change that shipped after your switchback read of +2.1 percentage points on SLA fill rate, 95% interval [0.9, 3.3]. Those markets run 250,000 requests a week at 88% fill, 93% completion. Over the following quarter, completed orders there rose 9%, about 239,000 orders, and six other launches shipped into the same window. You have the experiment readouts and the market-level series, and no budget for further study. Deliverable: the impact claim you make, the number attached to it, the evidence, and one project you score as zero or negative.
Approach
- Separate what you measured from what you observed: the switchback estimated a counterfactual contrast, while the 9% is an observed series containing seasonality, market mix, the other six launches and your change. Claim the first and say out loud that you are not claiming the second.
- Convert the experimental estimate into orders at the market base, and carry the interval through rather than reporting a point estimate that implies precision the design did not buy.
- Report the residual explicitly as unattributed rather than silently unclaimed; naming the gap is what makes the claimed portion credible.
- Score projects by decisions changed, not by metrics that happened to move afterwards, which is the only way work that correctly recommended shipping nothing scores above zero.
- Pick a genuine zero or negative with the real cause, and prefer a project where the technical work was sound but nobody used the output, since that is a scoping failure and naming it as such shows you can tell the two apart.
Follow-up
- How would you separate your change from the six other launches using only the data you already have?
- What would you have claimed if the switchback interval had included zero?
- Which of your projects had the highest value per week of your time, and is that the same as the one you led with?
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 high-cardinality categorical features, such as gig categories or user locations, in a gradient-boosting model?
- 02
At review you are asked what your work was worth this year. Your largest project was a dispatch change that shipped after your switchback read of +2.1 percentage points on SLA fill rate, 95% interval [0.9, 3.3]. Those markets run 250,000 requests a week at 88% fill, 93% completion. Over the following quarter, completed orders there rose 9%, about 239,000 orders, and six other launches shipped into the same window. You have the experiment readouts and the market-level series, and no budget for further study. Deliverable: the impact claim you make, the number attached to it, the evidence, and one project you score as zero or negative.
- 03
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 Fiverr interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Fiverr. Rounds and questions reflect what candidates have reported, not a process Fiverr has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How technical is the coding portion of the interview?
The coding interviews are practical and highly focused on data manipulation, string parsing, and algorithmic logic. You do not need to memorize obscure competitive programming algorithms, but you must be highly proficient in writing clean, bug-free Python code rapidly.
PracHub interview research ↗How heavily does Fiverr emphasize NLP for Data Science roles?
Very heavily. Because the core of Fiverr's marketplace relies on matches made through user-generated text (gigs, searches, messages), a strong understanding of NLP, text representation, and semantic understanding is highly advantageous for almost every data science team.
PracHub interview research ↗What is the hybrid or remote work policy for data science teams?
Fiverr typically operates on a hybrid model, balancing the collaboration benefits of in-office work with the flexibility of working from home. Specific expectations vary by office location (such as the Tel Aviv headquarters), so it is best to clarify current policies with your recruiter.
PracHub interview research ↗What is the typical timeline for receiving feedback after interviews?
While Fiverr strives to move candidates quickly, feedback timelines can vary. On average, candidates receive updates within one to two weeks after each round. Do not hesitate to check in with your recruiter if you have pending offers elsewhere.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Turo Data Scientist Interview Questions & Guide 2026
Take-home style practice for data scientists preparing for Turo: a messy dataset, a fixed time budget, and a written analysis, reviewed for whether it states its assumptions and whether a reader could reproduce your numbers.
Rover Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of Rover, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Prosper Marketplace Data Scientist Interview Questions & Guide 2026
Data-quality drills for Prosper Marketplace data scientist prep: survivorship and selection bias, leakage through time-ordered features, and extreme values where provenance decides the call. A logging fault or unit slip gets corrected or dr
Lyft Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for Lyft data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.