A Data Scientist at Patreon plays a critical role in driving the platform's mission to "fund the creative class." Operating at the intersection of product, engineering, and business strategy, you will leverage massive datasets to unlock monetization opportunities for over 300,000 creators. Your work directly impacts how millions of fans (patrons) engage with their favorite creators, making data science a cornerstone of the platform's product development and ecosystem growth.
In this role, you are not just a builder of dashboards or a runner of ad-hoc queries. You will work in lockstep with cross-functional partners to design core product features, establish critical business metrics, and develop robust experimentation frameworks. Whether you are optimizing membership conversion funnels, analyzing creator-patron network dynamics, or partnering with machine learning teams to deploy data products, your insights will shape the strategic direction of the company.
The data challenges at Patreon are highly complex and unique. Because the platform balances a dual-sided marketplace of creators and patrons, standard analytical frameworks often fall short. You will need to apply advanced statistical inference, causal modeling, and creative problem-solving to understand the real-world implications of product changes. It is a high-impact position where technical rigor meets creative business application.
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 Assessment
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
Hiring Manager Interview
reportedExpect a live problem with pieces of it missing, closer to a conversation than an exam. A metric moved, or somebody wants to know whether a change worked, and you are asked how you would find out. The manager is watching the first ninety seconds, specifically whether you establish what decision hangs on the answer before you start proposing methods. Candidates who open with a technique get steered back. Once the decision is clear, describe what the data would look like if the story were true, and say what you would accept as evidence that it is not.
What to demonstrate
- Whether you fix the decision the analysis serves before choosing an approach
- How you continue when you are told the data you just asked for does not exist
- Whether you state what would change your mind, not only what would confirm the hypothesis you started with
- How you size an effect before you have measured it
How to prepare
- Take a metric you know well and practise explaining in under two minutes the four things that could have moved it and how you would separate them
- Pick a recent launch or experiment and write the single number you would ask for first, plus what you would conclude if it came back flat
- Practise being interrupted: have someone remove a data source halfway through your answer and carry on without restarting
Virtual Onsite Loop
reportedWhere a loop ends with a senior leader, that conversation is rarely another skills test. The technical signal already exists by then, so the questions tend to open up: what you would look at first, where a metric you have heard about could mislead, what you would push back on. The decision being made is scope, which in practice means level and how much you would be trusted to own unsupervised. Treating it as a formality is the usual mistake. An open question late in the day is still being scored, and a vague answer reads as someone who has not run anything themselves.
What to demonstrate
- Whether your view of the business has anything specific behind it, given that you are working only from what is public and are expected to say so
- Whether the scope of work you describe owning matches the scope of the role, instead of sitting a level below it
- Whether you can disagree with something concrete and stay useful about it, rather than agreeing with everything said in the room
- Whether your questions are ones only this person could answer, as opposed to ones the recruiter already covered
How to prepare
- Build one view you could defend for two minutes using only public information: what the funnel probably looks like, which metric likely drives decisions, and where that metric could mislead. Being wrong for a stated reason survives this round; having no view does not
- Write down the largest piece of work you have owned from question to decision, who else touched it, and what you decided alone, then check that it reads at the level you are interviewing for
- Prepare one thing you would want changed if you joined and phrase it as a question rather than a verdict, so it opens a conversation instead of closing one
1 candidate reports. Individual accounts describe a particular role and hiring cycle.
Patreon Software Engineer Interview Experience — A Wordle-Style Coding Screen Nobody Warns You About
Not a question from the forum, which surprised me — I'd seen people on the forum say the phone screen here is basically coding rounds, IC/manager rounds, rate limiter, shopping cart, that sort of thing. The problem was roughly a guessing-word game: given a guess word and a target word, mark the status of each position. green: the two chars at this index are the same yellow: the two chars at this…
Read full experiencePracHub editorial advice for the preparation topics above.
Randomising individual members when the treatment travels along the social graph
If treated members post, comment or share more, their followers see the extra content whether or not those followers are treated, so the control group is partly treated and the measured difference understates the true effect. For features that redistribute a fixed amount of attention, the leakage runs the other way and the effect is overstated. The size of the bias scales with how dense the neighbourhood is, so it is largest exactly among the connected members whose behaviour the feature was built for. The fix is randomising clusters of the graph (ego networks or communities found by balanced partitioning), clustering the variance at that unit, and accepting that effective sample size falls by roughly the average cluster size.
Using report volume as a measurement of how much violating content exists
Reporting is a member behaviour, not an observation of the content. Report counts rise when the report control is made easier to reach, when a coordinated campaign targets an account, and when the audience shifts toward people who object; they fall when violating content is shown mainly to members who agree with it. A ranker that gets better at matching bad content to receptive audiences will drive reports down and harm up at the same time. Prevalence must come from a random sample of served impressions with recorded selection probabilities, labelled by humans against the written policy, and reported with an interval. Reports are useful as a detection signal and as a demand-side complaint rate, not as a denominator-anchored measure of harm.
Accepting a metric definition without asking about the denominator
Pin down the denominator, the eligibility filter and the time window before computing anything: conversion rate per session, per user, per eligible user and per new user are four different numbers with different behaviour. Restate the definition in one sentence and get agreement before you analyse.
Over-explaining the method and under-explaining the implication
Lead with the answer and what you would do about it, then give the approach when asked. Roughly one sentence of method per three of implication is the right ratio for a stakeholder-facing answer; the interviewer already knows what a regression is.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Classify daily actives into four mutually exclusive flow classes
sessions has member_id, session_start_utc (datetime64[ns]) and is_qualified (bool); members has member_id and tz_offset_minutes. Using qualified sessions only, put every active (member, local_date) pair into exactly one class: new (first ever qualified session that day), retained (also active the previous local day), reactivated (not active the previous day but active at least once in days d minus 28 through d minus 2), resurrected (not active at all in d minus 28 through d minus 1, active before that). Return a daily table of the four counts plus DAU, and report churn separately.
Approach
- Derive local_date as (session_start_utc + tz_offset_minutes).dt.date after joining members. A UTC day boundary cuts an evening session in half for large parts of the world, which depresses the metric by geography alone and makes country cuts uninterpretable.
- Reduce to distinct (member_id, local_date) rows first. Multiple qualified sessions in one local day are one active day, and forgetting this inflates every class equally while leaving the sum check passing, so it is invisible.
- The whole classification collapses to one lag. Sort by (member_id, local_date), take prev = groupby(member_id).local_date.shift(1), and let gap = local_date minus prev in days.
- Map gap to class: prev is NaT gives new; gap == 1 gives retained; 2 <= gap <= 28 gives reactivated; gap > 28 gives resurrected. This is exactly equivalent to the written windows, because the previous active date being in [d-28, d-2] is the same statement as the member being inactive on d-1 and active somewhere in that window.
- Compute churn on day d as members active on d-1 and absent on d. It belongs in its own table: its denominator is yesterday's actives, not today's DAU, so putting it in the same frame invites someone to add five numbers that do not sum to anything.
- Name the left-censoring limit before being asked, and name its direction. prev is NaT for anyone whose prior activity predates the window, so new absorbs those members and is inflated, while resurrected needs an observed gap above 28 days and therefore cannot occur before the 30th date at all. Drop that burn-in or carry a first-ever-active date computed from a longer history, and do not read the burn-in shape as a product change.
Worked solution 30 min
- q = sessions[sessions.is_qualified].merge(members[['member_id','tz_offset_minutes']], on='member_id'); q['local_date'] = (q.session_start_utc + pd.to_timedelta(q.tz_offset_minutes, unit='m')).dt.normalize()
- act = q[['member_id','local_date']].drop_duplicates().sort_values(['member_id','local_date'])
- act['prev'] = act.groupby('member_id').local_date.shift(1); act['gap'] = (act.local_date - act.prev).dt.days
- act['klass'] = np.select([act.gap.isna(), act.gap == 1, act.gap.between(2, 28)], ['new','retained','reactivated'], default='resurrected')
- flow = act.pivot_table(index='local_date', columns='klass', values='member_id', aggfunc='size').fillna(0).astype(int); flow['dau'] = flow[['new','retained','reactivated','resurrected']].sum(axis=1)
- churn: take act, compute next_date per member, and count members whose local_date == d-1 with no activity on d
Follow-up
- DAU is flat week over week but retained fell and reactivated rose by the same amount. What do you tell the product owner?
- Marketing turned on a paid campaign on Monday. Which of these four classes moves first, and how long before it shows up in the weekly active number?
- How would you extend this to say whether the reactivated members are the same people every week or a rotating set?
Simulate the false positive rate of a skewed A/A test
Per-member weekly impressions are strongly right-skewed. Simulate a population from Lognormal(mu=2.0, sigma=1.8), draw N members, split them at random into two arms, and run Welch's t-test on the per-member means. This is an A/A, so the null holds by construction and any rejection is a false positive. Report the empirical rejection rate at a nominal 5 percent for N of 4,000 and 100,000, each under a 50/50 and a 90/10 split, with the Monte Carlo standard error. Add a permutation test on the difference in means as a comparison arm. Say which cell is distorted and why.
Approach
- Build the harness so the null is true by construction: draw one population, then assign arms by a random permutation. Nothing differs between arms except the split, so every rejection is an error and there is no effect size to argue about.
- Choose B before running and derive the Monte Carlo standard error from it: sqrt(p(1-p)/B), which at p near 0.05 and B = 10,000 is about 0.22 percentage points. Any claim that 5.4 percent differs from 5.0 percent has to survive plus or minus roughly 0.43 points at 95 percent, so pick B for the difference you intend to resolve, not by habit.
- Run the four cells. Equal-sized arms are close to robust here because the skewness contributions of the two arms largely cancel in the t statistic; the 90/10 split is where the cancellation fails and the test is genuinely off nominal at small N. Report the numbers rather than asserting the direction in advance.
- Validate the harness before trusting the result: swap the lognormal for a Normal population and confirm every cell returns about 5 percent. If the Normal cells are off, the bug is in the code, not in the tail.
- Add the permutation arm: shuffle the arm labels, recompute the difference in means, and take the two-sided p as the share of shuffles at least as extreme. Under a random split exchangeability holds exactly, so this arm should sit at nominal in every cell and acts as the reference.
- Close with the operational consequence: the fix for the distorted cell is either balanced allocation, a permutation or bootstrap reference distribution, or a pre-registered cap, and a cap changes the estimand so it must be declared before the read, not chosen after seeing it.
Follow-up
- A pre-registered winsorisation at the 99th percentile fixes the level. What question is the capped metric now answering, and is it still the one the product owner asked?
- Repeat this with the ratio metric impressions per session rather than a per-member mean. What changes in the variance calculation?
- How much power did the 90/10 split cost relative to 50/50 at the same total N, and when is the ramp still worth it?
Write a data-quality audit over impression and engagement logs
You are given impressions (impression_id, event_date, viewer_member_id, content_id, rank_position, dwell_ms, served_at_utc), engagements (event_id, actor_member_id, content_id, impression_id nullable, action_type, occurred_at_utc, undone_at_utc nullable) and content (content_id, author_member_id, created_at_utc, enforcement_state, enforcement_at_utc). Write audit(impressions, engagements, content) returning one row per check with the failing row count and share. Cover at least six checks across uniqueness, value range, referential integrity and timestamp ordering. Mark each check block-the-refresh or log-only, and say which NULLs are by design rather than defects.
Approach
- Group the checks by failure class first, then write one vectorised expression per check, so the function stays a table of (name, predicate) rather than a wall of conditionals. Every check returns a boolean mask over one frame and the report is built by summing masks.
- Uniqueness and range: duplicated impression_id; rank_position < 1; dwell_ms < 0 or null; served_at_utc in the future relative to the partition date.
- Referential integrity: engagement rows whose non-null impression_id is absent from impressions; impression rows whose content_id is absent from content. Then the sharper one, which is what catches real pipeline breaks: engagement rows joined to their impression where viewer_member_id does not equal actor_member_id, or the two content_id values disagree.
- Timestamp ordering: undone_at_utc earlier than occurred_at_utc; engagement occurred_at_utc earlier than its impression's served_at_utc; content created_at_utc later than an impression of it.
- Separate by-design NULLs from defects explicitly. impression_id is NULL for follow, unfollow and profile_click, and for any deep-linked action, so its null rate is a distribution to monitor, not a check to fail. session_id is NULL for server-side actions. duration_seconds is NULL for non-video media.
- Classify severity by what the number is used for: referential mismatches between actor and viewer corrupt every rate denominated in impressions and should block; a small orphan-FK share from late-arriving partitions is log-only with a threshold and a trend.
Follow-up
- The orphan rate on engagement to impression is 0.4 percent and all of it is within two hours of the partition boundary. Block or log?
- enforcement_at_utc is later than impressions already served for that content. Is that a defect, and what does it do to a query you ran last week?
- How would you turn this audit into something that fails a pipeline rather than producing a report nobody opens?
Write a query to identify creators who have experienced a significant …
Write a query to identify creators who have experienced a significant drop in monthly recurring revenue (MRR) over the last three months.
Approach
- Say which table is the grain you start from, and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
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?
Debug a query that is failing to run due to syntax errors, and then op…
Debug a query that is failing to run due to syntax errors, and then optimize it to run more efficiently on a large dataset.
Approach
- Say which table is the grain you start from, and join outward from it.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- 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 would you verify this result without re-running the same query?
Split daily actives into new, retained, reactivated and resurrected
From daily_active(member_id, activity_date), one row per member per member-local day with a qualified session, classify every member active on day d into exactly one class: new (first-ever activity on d), retained (also active on d-1), reactivated (inactive on d-1 but active somewhere in d-28 to d-2), resurrected (inactive across all of d-28 to d-1 but active before d-28). Return day, class and member count; the four classes must sum to that day's active count. Report churn (active on d-1, absent on d) as a separate series, not a fifth class.
Approach
- Derive one value per row with LAG(activity_date) OVER (PARTITION BY member_id ORDER BY activity_date). Every class in the definition is a statement about the previous active day, so this single window function does all four.
- Map the definitions onto the gap: prev_date IS NULL means new; gap = 1 means retained; prev_date in [d-28, d-2], that is a gap of 2 through 28, means reactivated; prev_date earlier than d-28, a gap above 28, means resurrected. That equivalence is worth stating, because it is what makes the classes exhaustive rather than three predicates and an else.
- Write the classification as one CASE with branches in that fixed order, so exclusivity holds by construction. Four independent EXISTS subqueries look clearer and are the usual source of a member landing in two classes.
- Compute churn in a separate pass: day d-1's actives anti-joined to day d, indexed to the day the member went absent. Churn is not a class of actives on day d, since a churned member has no row on day d at all, and adding it would break the sum.
- Assert the check before showing anyone the result: for each day, the four class counts must sum to COUNT(DISTINCT member_id) in daily_active for that day. That check is the whole reason this decomposition is believed.
Worked solution 30 min
- WITH a AS (SELECT member_id, activity_date, LAG(activity_date) OVER (PARTITION BY member_id ORDER BY activity_date) AS prev_date FROM daily_active).
- Classify: CASE WHEN prev_date IS NULL THEN 'new' WHEN activity_date - prev_date = 1 THEN 'retained' WHEN activity_date - prev_date <= 28 THEN 'reactivated' ELSE 'resurrected' END.
- GROUP BY activity_date, class and count members.
- Churn: SELECT d.activity_date + 1 AS churn_date, COUNT(*) FROM daily_active d LEFT JOIN daily_active n ON n.member_id = d.member_id AND n.activity_date = d.activity_date + 1 WHERE n.member_id IS NULL GROUP BY 1.
- Run the sum check per day and only then join the class counts to the churn series for reporting.
Follow-up
- DAU is flat but the retained share fell four points while reactivated rose four. What happened, and what is the next query you run?
- How do these classes change if the day boundary is each member's local midnight rather than UTC midnight?
- Produce the same decomposition weekly instead of daily. Which class definition stops making sense?
What metrics would you design to measure the health and engagement of …
What metrics would you design to measure the health and engagement of a creator's community on Patreon?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- 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
- 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?
How do you handle a situation where your primary metric shows a positi…
How do you handle a situation where your primary metric shows a positive lift, but a critical guardrail metric shows a statistically significant decline?
Approach
- 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.
- State what result would change your recommendation, so the answer is falsifiable.
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 we observe a sudden 10% drop in active paid memberships across the …
If we observe a sudden 10% drop in active paid memberships across the platform, how would you investigate the root cause?
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- Fix the population and the time window before naming any metric.
- Decompose the metric into the rates that drive it, and say which one you would check first.
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?
A product manager wants to launch a new direct-sales feature for digit…
A product manager wants to launch a new direct-sales feature for digital goods. How would you evaluate the potential market size and define success for the MVP?
Approach
- 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.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
What statistical methods would you use to measure the impact of a prod…
What statistical methods would you use to measure the impact of a product launch if a randomized control trial (A/B test) is not technically feasible?
Approach
- Say whether units interfere with each other, and switch design if they do.
- Name the guardrails that would stop a launch even on a positive primary result.
- Name the randomisation unit first; it decides the variance and what the test can detect.
Follow-up
- How would you handle interference between treated and control units?
- What would you conclude if the result is positive but the test is underpowered?
How would you design an A/B test to evaluate a new checkout flow when …
How would you design an A/B test to evaluate a new checkout flow when there are strong network effects between creators and their patrons?
Approach
- Name the guardrails that would stop a launch even on a positive primary result.
- Say whether units interfere with each other, and switch design if they do.
- State the primary metric and the minimum effect worth shipping, then size the test.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- What would you do if you could not randomise at all?
Define a qualified session you can defend twice
The north-star counts weekly members with at least one qualified session. You own the definition. Today it reads: a session with 30 or more foreground seconds and at least one non-negative engagement or authored item, derived from fct_feed_impression.session_id, fct_feed_impression.dwell_ms, fct_engagement_event.action_type with is_negative_feedback = FALSE, and fct_content_item.created_at_utc. Write the definition precisely, including how a session closes and how undone actions count. Then defend it against two objections: that the 30-second floor excludes a real use, and that the engagement requirement is satisfiable by a mis-tap. Deliverable: the definition plus both rebuttals.
Approach
- Write the session boundary rule explicitly (inactivity gap, foreground only, how a background-to-foreground return is treated), because every rate in the tree is denominated in sessions and an unstated boundary makes the count a function of an SDK timeout nobody reviewed.
- Enumerate the qualifying acts from fct_engagement_event and the authored path from fct_content_item, and rule that an action with undone_at_utc within 60 seconds of occurred_at_utc does not qualify. That closes the mis-tap objection with data already logged rather than a new instrument.
- Answer the exclusion objection with evidence, not judgement: measure what fraction of sessions fall between 10 and 30 foreground seconds and what those members do the following week. Either accept the exclusion citing that number, or add a second qualifying path such as a completed deep-linked read, rather than lowering the floor globally.
- State what the definition deliberately is not: not time spent and not any impression, so a stickier or longer feed cannot move it without a member acting.
- Version the definition and pin it to a UI period, since moving the hide or like control changes the numerator with no change in member behaviour.
Worked solution 20 min
- Write the close rule: 30 minutes of foreground inactivity closes a session, a new foreground entry opens one, and a session is attributed to the viewer-local date of its first event using dim_member.tz_offset_minutes.
- Write the qualifying-act set: any fct_engagement_event row in the session with is_negative_feedback = FALSE and (undone_at_utc IS NULL OR undone_at_utc > occurred_at_utc + 60 seconds), or any fct_content_item authored by that member inside the session window.
- Run the sensitivity: recompute the weekly qualified-member count at foreground floors of 10, 30 and 60 seconds and record both the level and the week-over-week change under each.
- Write the two rebuttals, one paragraph each, each citing the specific number from step 3 that supports it.
Follow-up
- A platform team ships background prefetch that keeps the app foregrounded longer. Which part of your definition moves, and should it?
- You are asked to make this comparable across iOS, Android and web. What breaks first, and do you fix the definition or report the platforms separately?
Impressions dropped for three days, engagement events did not
Home_feed impressions on one client platform fell 22 percent for three days and then recovered. Engagement per 1,000 impressions on that platform rose 26 percent across the same three days and then returned to baseline. Raw engagement event counts were flat throughout. fct_engagement_event.impression_id is a nullable foreign key into fct_feed_impression, and warehouse foreign keys are declarative rather than enforced. Establish whether ranking improved or impression rows were lost, quantify the loss, and state the precondition your estimate depends on.
Approach
- Run the referential integrity test first, because it is decisive and cheap: count fct_engagement_event rows on those dates with impression_id IS NOT NULL that have no matching row in fct_feed_impression. Under normal operation this is near zero. Under impression loss it jumps, and each orphan is a directly observed missing impression.
- Check the reciprocal arithmetic. If the numerator is intact and the denominator loses a fraction f, the rate rises by 1/(1-f) - 1. An observed 26 percent rise implies f of about 0.206, which is consistent with the observed 22 percent drop within noise. A genuine ranking improvement has no reason to produce that near-exact reciprocal.
- Estimate total loss from the orphans: missing impressions is approximately orphan engagements divided by the baseline engagement-per-impression rate measured among matched rows on healthy days. State the precondition explicitly, that loss is independent of whether the impression was engaged with. If loss were correlated with engagement, this estimator is biased and the orphan count becomes a lower bound only.
- Characterise the loss as random or structured. Compare the distribution of impressions per session on the affected days against baseline: proportional loss shifts the whole distribution, while a failure that truncates a batch produces a distinctive spike of short sessions. Also check rows per hour to find the start and end of the window.
- Rule out a demand explanation. Sessions per member and engagement events per session should be flat if only logging broke. If sessions also fell, part of the impression drop is real and the two effects must be separated before quoting a loss figure.
- Recommend the operational response: mask these three dates in every impression-denominated rate, re-state them only if the upstream can replay, and note that any experiment reading on those dates is compromised for rate metrics but not for member counts.
Follow-up
- How do you decide whether to backfill the partitions or permanently mask the dates, and what does each choice cost downstream?
- An experiment was reading during those three days. Which of its metrics are still usable and which are not?
- What monitor would have caught this within an hour, and what is its false-positive cost?
Instead of guessing where the week should go, day one measures it under a fixed rubric and allocates the remaining hours in proportion to the gaps. The method is deliberately rigid: the allocation is written down before any studying starts and is not renegotiated when a topic turns out to be unpleasant.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Diagnostic, scored before you study anything
- Sit a 100-minute timed diagnostic in four blocks: 30 minutes of SQL across three prompts, 25 minutes of short-answer statistics, 25 minutes on one modelling or case prompt, and 20 minutes delivering one behavioural story aloud.
- Score each block from 0 to 3 on a fixed rubric where 3 is correct and fluent, 2 is correct but slow or prompted, 1 is partially correct, and 0 is stuck, grading the output rather than how the attempt felt.
- Allocate the hours for days two to five roughly in proportion to 3 minus the score in each block, write the allocation down, and commit to not revising it midweek.
Deliverable: A scored rubric and a fixed hour allocation for the rest of the week.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Largest gap: find the boundary rather than the subject
- Break the weakest area into five named sub-skills (for query work: grain control, window frames, date arithmetic, set logic with NULLs, and reading a query plan) and rate each one, so the rest of the week targets a sub-skill instead of a subject.
- Solve three problems chosen to sit just above where the rating drops off, and for each write the first move you failed to make.
- Re-solve one of them from memory four hours later, on paper, with nothing open.
Deliverable: A five-item sub-skill map with the two blocking sub-skills circled.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Largest gap: drill the blocking sub-skill
- Do eight short repetitions of the same shape rather than eight different problems, so what you practise is the pattern and not the puzzle.
- Write the rule you now hold in one sentence, then test it against a case built to break it: a ranking function over a column with ties, or a two-sample test on observations that are obviously dependent.
- Have someone else read your one-sentence rule and find the precondition you left out.
Deliverable: One rule statement with its preconditions attached and one counterexample that would have caught the incomplete version.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Second gap, plus maintenance on your strongest area
- Run the same sub-skill map and boundary protocol on the second-largest gap, compressed into half the day.
- Spend 25 timed minutes on your strongest area to stop it decaying, choosing the hardest problem you can still finish rather than an easy warm-up.
- Compare how the two areas fail: whether you lose time on recall, on setup, or on arithmetic, because the fix differs for each.
Deliverable: A second sub-skill map plus a one-line diagnosis of how each area fails you.
Practice prompt ↗Practice prompt ↗Worked solution ↗05The gap that is not a skill
- Record yourself answering one technical and one behavioural prompt, then count two things in the playback: how many seconds before your first clarifying question, and how many sentences you started without knowing where they ended.
- Rewrite your three most-used stock phrases into shorter versions, and practise saying "I do not know, here is how I would find out" without softening it into a guess.
- Deliver one answer again with a hard 90-second limit to force structure before detail.
Deliverable: Two recordings with a counted improvement in time-to-first-question.
Practice prompt ↗Practice prompt ↗06Retest under day-one conditions
- Sit the same 100-minute diagnostic structure with new prompts of comparable difficulty and score it on the identical rubric.
- Compare block by block, and for any block that did not move, change the method rather than adding hours: a block stuck at 1 usually means the practice was too varied, not too short.
- Write which single block you would still lose the offer on.
Deliverable: A second scored rubric placed next to the first, with one named remaining risk.
Practice prompt ↗Practice prompt ↗07Full loop under interview conditions
- Run a 60-minute mock covering the two blocks that moved least, with an interviewer instructed to interrupt and change direction.
- Write your recovery script for the moment you go blank: restate the question, state your assumption, name the first thing you would check.
- Reduce the week to the rule statements you wrote, each with its preconditions attached, then say every one of them out loud without reading it and cut any you cannot state in a single sentence, since a rule you have to reconstruct mid-answer will not survive being interrupted.
Deliverable: A one-page card holding the recovery script and only the rules you could state from memory.
Practice prompt ↗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.
Tell me about a project where you had to make tradeoffs between data q…
Tell me about a project where you had to make tradeoffs between data quality and project timelines. How did you communicate these trade-offs to stakeholders?
Approach
- Pick a story where you drove the decision, not one where you observed it.
- Close with what you would do differently, concretely.
- 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?
Choose between three requests with one analyst week
You have one analyst week and three open requests. Ranking wants an off-policy estimate of a candidate ranker, but log_propensity is NULL on 92 percent of home-feed impressions. Growth wants a week-1 retention read on a registration cohort whose day 7 to 13 window closes in four days. Integrity wants the audit sample re-sized because the prevalence interval cannot detect a 20 percent change. Give the order, what each requester gets and when, and the request you refuse outright with the reason.
Approach
- Sort by identification before sorting by importance. A request that cannot be answered correctly with any amount of effort is not competing for the week; it is competing for a different conversation.
- Rule out the off-policy estimate on positivity grounds and say it in one line: log_propensity NULL means serving was deterministic top-k, so the unserved slots had zero logging probability, and no inverse-propensity or doubly-robust estimator is identified there. The fix is a randomised exploration slot or an online test, which is a platform change and not an analyst task.
- Rule out the retention read on timing: days 7 to 13 must have closed for every member in the cohort. Reading it four days early truncates the window for the late-registering half of the cohort and biases the estimate by registration day, which correlates with acquisition channel.
- Do the integrity re-size, because it is tractable in hours and unblocks a standing measurement. At a two-sided alpha of 0.05 and 80 percent power, detecting a move from 0.50 percent to 0.40 percent needs roughly 70,000 labelled impressions per comparison period under simple random sampling, before any design effect from unequal weights. That number reframes the request: the honest deliverable may be a stratified design plus a longer comparison window, not a bigger weekly sample.
- Convert each refusal into a dated deliverable so the week does not end in three unhappy teams: ranking gets the exploration-slot design and the randomised fraction it needs; growth gets the date the cohort closes plus the activation rate on days 0 to 6, which is already readable and is a leading indicator of the number they want.
Follow-up
- Ranking says a biased estimate is better than none. Answer them in two sentences.
- How large an exploration fraction would you request, and what does it cost in served quality?
- If integrity cannot fund 70,000 labels a week, what do you offer instead?
Explain a prevalence interval to a non-technical executive
A weekly impression-weighted violating-content prevalence estimate came in at 0.42 percent, 95 percent interval 0.28 to 0.61, against 0.51 percent (0.35 to 0.72) the week before. The audit sample is 4,000 served impressions drawn with unequal, recorded selection probabilities across risk strata, labelled by humans against written policy. An executive asks whether the number went down and wants one figure for a board slide. In five minutes: answer the question, say what goes on the slide, and state what you would need to give a sharper answer next quarter.
Approach
- Answer the question in one sentence before explaining anything: the point estimate is lower, the intervals overlap across most of their range, and the week-over-week change is not distinguishable from zero.
- Show why with one arithmetic step rather than vocabulary. At n = 4,000 and p near 0.004 the simple-random-sampling standard error is sqrt(p(1-p)/n), about 0.10 percentage points, so an SRS interval would run roughly plus or minus 0.20 points and a 0.09 point move sits well inside it. Two facts about the reported interval belong in your head rather than on the slide. Its asymmetry comes from the construction, not from the weights: Wilson, Clopper-Pearson and logit intervals are built on a bounded scale, so near p = 0 the upper limit sits further from the point estimate than the lower one. The 1/p_i weights act on width only, through a design effect that multiplies the variance. Here the reported width of 0.33 points implies a standard error near 0.085 (0.33 divided by 3.92), so the design effect is about 0.7, which is what oversampling high-risk strata buys when selection probability correlates with the outcome. Uninformative weights would instead give a design effect of 1 + CV squared of the weights, above 1, and an interval wider than the SRS one rather than narrower.
- Replace the bare point estimate with a number that is stable at board cadence: the trailing four-week pooled estimate, formed by re-summing the weighted numerator and the weighted denominator across weeks. Averaging the four weekly rates gives a different and wrong number when weekly sample sizes differ.
- Price the precision the executive is implicitly asking for. Halving the interval width needs roughly four times the labelled sample, so 16,000 labels a week to go from a half-width near 0.17 points to one near 0.085. The cheaper lever is allocation rather than volume: the design already uses unequal, recorded, strictly positive selection probabilities and is already running a design effect near 0.7, so re-fitting the strata on current classifier scores and moving more of the 4,000 into the strata carrying the violating mass pushes that number down further without a fourfold labelling bill.
- State plainly what this number is not, because the executive will meet substitutes. Report volume and enforcement volume are member and operations behaviours; they can fall while prevalence rises if the ranker gets better at matching violating content to receptive audiences.
Follow-up
- The executive wants a weekly trend line on the slide anyway. What do you draw, and what do you label the band?
- How long would it take to detect a 20 percent reduction in prevalence at the current sample size?
- Why not score every impression with the classifier instead of paying for human labels?
- 01
Tell me about a project where you had to make tradeoffs between data quality and project timelines. How did you communicate these trade-offs to stakeholders?
- 02
You have one analyst week and three open requests. Ranking wants an off-policy estimate of a candidate ranker, but log_propensity is NULL on 92 percent of home-feed impressions. Growth wants a week-1 retention read on a registration cohort whose day 7 to 13 window closes in four days. Integrity wants the audit sample re-sized because the prevalence interval cannot detect a 20 percent change. Give the order, what each requester gets and when, and the request you refuse outright with the reason.
- 03
A weekly impression-weighted violating-content prevalence estimate came in at 0.42 percent, 95 percent interval 0.28 to 0.61, against 0.51 percent (0.35 to 0.72) the week before. The audit sample is 4,000 served impressions drawn with unequal, recorded selection probabilities across risk strata, labelled by humans against written policy. An executive asks whether the number went down and wants one figure for a board slide. In five minutes: answer the question, say what goes on the slide, and state what you would need to give a sharper answer next quarter.
Is this an official Patreon interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Patreon. Rounds and questions reflect what candidates have reported, not a process Patreon has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How technical is the SQL screen at Patreon?
The SQL screen is highly practical and rigorous. It often involves live coding on platform-relevant datasets and may require you to execute SQL queries within a Python wrapper. You should practice writing clean, optimized queries under time constraints.
PracHub interview research ↗What is Patreon's hybrid work policy?
Patreon operates under a hybrid work model. For employees based near office locations (such as San Francisco or New York), you are expected to be in the office two days per week to foster team collaboration and community.
PracHub interview research ↗How should I prepare for the Core Values round?
Review Patreon's core values: Put Creators First, Build with Craft, Make it Happen, and Win Together. Prepare specific, real-world examples from your past experience that demonstrate how you have embodied these principles in your professional work.
PracHub interview research ↗What is the typical timeline from the initial screen to an offer?
The entire process usually takes between three to five weeks. This timeline depends on your availability, the responsiveness of the recruiting team, and the scheduling requirements of the onsite interview panel.
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.
TELUS Digital AI Community Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of TELUS Digital AI Community, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Suno Data Scientist Interview Questions & Guide 2026
Timed practice for Suno data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.
Strike Social Data Scientist Interview Questions & Guide 2026
Product-sense practice for a Strike Social data scientist interview: define a social and content platforms metric, pick its guardrails, and argue why a tempting alternative would mislead you.
Reddit Data Scientist Interview Questions & Guide 2026
Data-quality drills for Reddit 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 dropped; a genu