As a Data Scientist at Twitch, you occupy a central role in shaping the world's biggest live streaming service. You work at the intersection of massive user engagement, real-time video streaming, interactive chat dynamics, and complex monetization models spanning advertising, commerce, and creator partnerships. Your daily objective is to turn petabytes of high-velocity consumer data into strategic clarity, helping product managers, finance leaders, and engineers make high-stakes decisions with confidence.
Your impact is direct and measurable across the entire ecosystem. Whether you are modeling viewer retention during major esports tournaments, optimizing ad-insertion algorithms, or analyzing subscription churn across global creator communities, your insights drive product roadmaps. You tackle ambiguous business problems by designing robust experiments, building predictive models, and constructing comprehensive dashboards that illuminate viewer and broadcaster behavior at a global scale.
The role demands a rare blend of rigorous technical execution and commercial intuition. You will experience significant autonomy in choosing your analytical tools, but you will also face high expectations for accuracy, speed, and communication depth. Success at requires you to partner cross-functionally, write clean code, and translate complex statistical findings into compelling narratives that influence executive leadership and technical teams alike.
Recruiter Screen
reportedMost candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.
What to demonstrate
- Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
- Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
- The substance of the questions you ask back, which an experienced screener reads as a level signal
How to prepare
- Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
- Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
- Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered
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
Technical Evaluation
reportedMuch of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.
What to demonstrate
- Whether the query you write matches the plan you just described
- What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
- Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly
How to prepare
- Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
- Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
- Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock
Final Round 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
9 candidate reports. Individual accounts describe a particular role and hiring cycle.
Twitch Backend Engineer interview with AWS system design prompts
I interviewed at Twitch for a Software Engineer role. The process felt challenging and deliberate over roughly a few weeks, with a testing approach that was more distinctive and less focused on standard LeetCode problems. It started with a timed coding assignment. After that, I had a recruiter phone call, followed by a hiring manager discussion as the second phase. The technical testing used ques…
Read full experienceTwitch Software Engineer interview: OOP assessment and no offer
I interviewed for a Software Engineer role at Twitch. The process felt fairly standard: a recruiter screen followed by an assessment focused on object-oriented programming. The recruiter screen covered my resume and previous work. The technical assessment involved an OOP coding question. I wasn't offered the role. My main takeaway was to be ready to code directly around object-oriented fundamenta…
Read full experienceTwitch Software Engineer interview with a CodeSignal design and debugging assessment
I applied to Twitch for a Software Engineer role, completed an assessment focused on design and debugging tasks, and then didn't move forward. The OA was a CodeSignal-style assessment with a system-design-and-coding prompt split into two parts. First, I had to implement classes and functions. Then I had to debug a helper class. I didn't hear back after the assessment. My takeaway was that the "de…
Read full experienceTwitch Software Engineer interview with an unexpected behavioral call
I went through Twitch's early pipeline for a Software Engineer role, starting with a Codesignal pre-screen to earn an invitation. The behavioral intro call caught me off guard, and I didn't progress. The Codesignal pre-screen was a coding assessment. The intro and recruiter call focused on behavioral questions I hadn't expected, and I felt that my answers weren't strong. I didn't advance. My take…
Read full experienceTwitch Software Engineer interview with a two-hour assessment
I interviewed for a Software Engineer role at Twitch and went through an unusually long assessment. I never received clear follow-up afterward. The process began with a recruiter conversation. The online assessment was a single extended technical assessment that lasted about two hours. I wished I could see my scores, but I never received them. I didn't hear back, and the experience left me thinki…
Read full experiencePracHub editorial advice for the preparation topics above.
Comparing consumption week over week across the release calendar and the rights calendar.
A major release, a season drop or a live event produces a spike that dwarfs almost any treatment effect, and the effect is not confined to the new title because it pulls attention from everything else in the same window. Separately, licensed content leaves the catalogue when its window expires, so consumption falls with no product change and the drop is attributed to whatever shipped that week. Both need to be handled by an explicit control: a comparison period chosen for calendar equivalence, a covariate for scheduled releases, or a pre-registered rule for excluding a window, decided before the numbers are seen.
Counting plays without a qualification threshold, or changing the threshold without restating history.
Playback arrives as heartbeats, so a play only exists once you decide what counts, and the common 30-second convention is not a neutral analytics choice: in music it is also the boundary at which a play becomes payable, which makes the warehouse definition a payout definition. The threshold interacts violently with content length, so a catalogue of three-minute tracks and one of forty-minute episodes move in opposite directions when you change it, and a skip-heavy surface can add plays while adding no hours. Any metric mixing pre-threshold and post-threshold counts, or pooling short-form and long-form on a per-stream basis, moves by double digits for reasons that have nothing to do with the product.
SQL that silently fans out on a one-to-many join
State the grain of each table and the grain you want in the result before writing the join. Pre-aggregate the many side to the join key, or use EXISTS or a window function, and verify with a row count against COUNT(DISTINCT id) rather than trusting that the numbers look plausible.
Sizing estimates built on unnamed, unrevisable assumptions
Write each assumption as a named number you can change, then show the arithmetic so the interviewer can challenge one input instead of the whole answer. Finish by saying which assumption the result is most sensitive to, which matters more than the point estimate.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the concept of statistical power and how you calculate it when…
Explain the concept of statistical power and how you calculate it when dealing with heavily skewed engagement distributions.
Approach
- Say what the estimate is of, and over what population it generalises.
- Write down the assumption the method needs before you use the method.
- Translate the result into the decision it informs, in one plain sentence.
Follow-up
- Which assumption here is most likely to be violated in practice?
- What sample size would you need to detect an effect half this size?
Explain how you would model viewer churn probability using survival an…
Explain how you would model viewer churn probability using survival analysis or logistic regression.
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
Duration-decile-weighted completion rate with fixed reference weights
Implement this metric. Numerator: qualified streams with completion_ratio at or above 0.9. Denominator: qualified streams with a non-null duration_seconds, so live events are out. Compute the rate inside each (content_type, duration decile) cell, then aggregate with catalogue-mix weights fixed from a reference month. You get streams and content for the last eight weeks plus ref_streams for the reference month. Return the weighted index and the unweighted global rate for each of the eight weeks, and the share of reference weight your cells actually covered.
Approach
- Fix the decile boundaries from the reference month, within content_type, over that month's qualified streams. Not over the catalogue, and not per week: the weights and the cells have to be defined on the same population or the weighted sum is adding rates over cells the weights do not describe.
- Store the boundaries explicitly and bin every week against them with pd.cut, with open-ended outer edges, so a duration longer than anything in the reference month still lands in the top cell instead of becoming NaN and quietly leaving the denominator.
- Weights are the reference month's share of qualified streams per (content_type, decile) cell, summing to one across all cells. Apply them to each week's cell rates and report the covered weight separately, because a week missing a cell entirely gives a renormalised index, and renormalising silently is how the series gains a step change nobody can explain.
- Keep the unweighted rate beside it. The pair is the deliverable: the weighted line is the answer, and the gap between the two is the size of the mix effect you removed, which is the first thing anyone reading it will ask about.
- Sanity-test the whole construction by feeding the reference month back in as the current week; the weighted and unweighted rates must then be identical to floating-point error.
Worked solution 40 min
- Join content onto ref_streams, filter to is_qualified with duration_seconds not null, and take within-content_type deciles of duration_seconds at quantiles 0.1 through 0.9, replacing the outer edges with negative and positive infinity.
- Weights: value counts of (content_type, decile) over the reference month, divided by that month's total qualified, non-null-duration streams.
- For each of the eight weeks, filter and join identically, bin with pd.cut against the stored per-type boundaries, and compute each cell rate as the mean of (completion_ratio at or above 0.9), keeping the cell's stream count alongside.
- Weighted index = sum(weight times rate) over cells present that week, divided by the sum of weight over those same cells; record that divisor as covered_weight.
- Unweighted rate = the week's overall mean of the same indicator. Assemble the eight-row output.
Follow-up
- The weighted index is flat and the unweighted rate fell four points. What shipped?
- When would you refresh the reference month, and what do you owe the series when you do?
- Podcast episodes and film have very different completion shapes. Would you ever report one number across them at all?
Given a table of chat events, write a query to identify top chatters a…
Given a table of chat events, write a query to identify top chatters and their message frequency per channel using advanced aggregations.
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.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- What breaks if events arrive late or out of order?
- How would you verify this result without re-running the same query?
Extract retention cohorts over a twelve-month period using complex joi…
Extract retention cohorts over a twelve-month period using complex joins and conditional aggregation in SQL.
Approach
- 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.
- Say which table is the grain you start from, and join outward from it.
Follow-up
- How would you verify this result without re-running the same query?
- What breaks if events arrive late or out of order?
Home-row impressions that never converted, and an empty result
fct_impression has impression_id, profile_id, content_version_id, surface, slate_position, rendered_at and viewport_visible_ms. fct_stream has stream_id, profile_id, content_version_id, started_at, is_qualified and a nullable impression_id, populated only when the play started from a rendered slate. For surface = 'home_row' impressions rendered yesterday with viewport_visible_ms > 0, return content_version_id and the number of impressions that produced no qualified stream within 30 minutes. A colleague's draft filters WHERE impression_id NOT IN (SELECT impression_id FROM fct_stream) and returns zero rows on data that plainly contains misses. Explain why, then write the correct query.
Approach
- Name the mechanism rather than the symptom. fct_stream.impression_id is nullable, so the subquery returns a set containing NULL. In SQL's three-valued logic x NOT IN (..., NULL) evaluates to UNKNOWN whenever x matches nothing else, never to TRUE, so the WHERE clause admits no rows. This is correct engine behaviour on correct data.
- Fix with NOT EXISTS, which is a correlated existence test and is NULL-safe by construction, or with LEFT JOIN ... WHERE s.impression_id IS NULL. Adding IS NOT NULL to the subquery also works but leaves the same landmine armed for whoever edits the query next.
- Put is_qualified = true and the 30-minute window inside the join or the correlated predicate, never in an outer WHERE over a LEFT JOIN. An outer filter on a right-side column turns a LEFT JOIN back into an inner join and returns the exact complement of the set you were asked for.
- Match on impression_id, not on (profile_id, content_version_id). The second is a many-to-many between two event tables and will count one stream against every impression of that title for that profile.
- Keep viewport_visible_ms > 0. A row that was never scrolled into view is not a recommendation that failed; it is a recommendation that was never made, and including it depresses every title's conversion by whatever share of the row went unseen.
Worked solution 20 min
- Prove the mechanism in one line: SELECT COUNT(*) FROM fct_stream WHERE impression_id IS NULL. A non-zero count is the entire explanation and should be shown before the rewrite.
- Rewrite as NOT EXISTS, with is_qualified and started_at BETWEEN rendered_at AND rendered_at + INTERVAL '30 minutes' inside the correlated predicate.
- Compute eligible and converted impression counts per content_version_id separately; the requested answer must be their difference.
- Spot-check one high-count content_version_id by listing its impressions alongside any streams sharing those impression_ids.
Follow-up
- Two home rows on the same screen render the same title, and the stream carries one impression_id. Should the other impression count as a miss? Defend whichever rule you pick.
- Would NOT EXISTS and LEFT JOIN ... IS NULL produce the same plan here, and is there a case where you would prefer one over the other?
- What attribution window between rendered_at and started_at do you allow, and why does an unbounded window overstate conversion rather than merely add noise?
How would you design a metric to evaluate the long-term health of a st…
How would you design a metric to evaluate the long-term health of a streamer's community on the platform?
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.
- 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?
- How would you detect that the metric is being gamed rather than genuinely improving?
An experiment shows a statistically significant lift in short-term eng…
An experiment shows a statistically significant lift in short-term engagement but a drop in long-term retention. How do you evaluate the final launch decision?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- 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?
A key engagement metric dropped by ten percent week-over-week. Walk th…
A key engagement metric dropped by ten percent week-over-week. Walk through your systematic approach to diagnosing the root cause.
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- 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
- Which segment would you cut first, and what would that rule out?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How would you quantify the trade-off between ad load frequency and use…
How would you quantify the trade-off between ad load frequency and user retention for live video streams?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- 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?
What are the primary experimentation pitfalls you watch out for when t…
What are the primary experimentation pitfalls you watch out for when testing changes that affect live-streaming latency?
Approach
- State the primary metric and the minimum effect worth shipping, then size the test.
- Decide the analysis before seeing data, including how long it runs and when you look.
- Name the randomisation unit first; it decides the variance and what the test can detect.
Follow-up
- What would you do if you could not randomise at all?
- How would you handle interference between treated and control units?
How do you evaluate the validity of an observational study when a true…
How do you evaluate the validity of an observational study when a true A/B test is impossible to run?
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.
- Name the randomisation unit first; it decides the variance and what the test can detect.
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?
What framework would you use to decide whether to launch a new discove…
What framework would you use to decide whether to launch a new discovery surface on the mobile app?
Approach
- Say what you would check first and why it is the highest-information step.
- Work from the decision backwards to the evidence you would need.
- State your assumptions explicitly before working the problem.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Build a surrogate index for six-month paid retention
The engagement org runs experiments that read out in three weeks, but the outcome it is judged on is month-6 paid retention. You are asked for a single surrogate index that experiments can ship on. Using the spine's account-level metrics (first-week habit rate, qualified hours per active account-week, duration-normalised completion rate) and fct_subscription_period (account_id, period_end_ts, renewal_outcome, is_promotional), propose the index, specify exactly how you would validate it, and state the condition under which shipping on it is unsafe.
Approach
- State the estimand and the binding constraint together: the decision outcome is the month-6 paid retention effect of a treatment, and the constraint is a three-week readout, so the index is standing in for an effect that will not be observed until long after the ship decision. Say what surrogacy requires, namely that the treatment effect on retention must flow entirely through the index, and say that this is an assumption about the treatment, not a property of the index.
- Construct the candidate from metrics that are already defined and already measurable in three weeks: an account-level index combining first-week habit rate (qualified streams on three or more distinct UTC dates in the first 168 hours) with qualified hours per active account-week over weeks two and three, weights estimated rather than chosen, with duration-normalised completion rate as a third term only if it earns its place in the fit.
- Specify the validation at the right level of analysis, because this is where the answer is won or lost: regress the observed month-6 retention effect on the observed index effect across the historical corpus of completed experiments, one point per experiment, and report the slope with its confidence interval and the residual spread. A correlation between engagement and retention across accounts is not evidence of surrogacy at all, because it is driven by account quality rather than by transmission of a treatment effect.
- Quantify what the validation buys: the usable output is the residual standard deviation of the retention effect given the index effect, which converts an index reading into a retention interval. If that interval routinely spans zero at the index effect sizes teams actually ship, the index does not support the decision it is being built for and the honest answer is to say so.
- Name the invalidation condition concretely rather than as a caveat: the extrapolation fails for any treatment whose mechanism is absent from the validation corpus, and the clearest examples are those that raise the index through a channel that does not carry: autoplay and push notifications raise hours without raising intent, and an ad-load reduction raises hours while removing the revenue the retention is worth.
- Close the loop with governance: a pre-registered fraction of index-shipped changes is held out for a confirmatory 180-day readout, the corpus is refreshed with those results, and the slope is re-estimated on a schedule, because a surrogate validated once and never revisited is a surrogate that drifts silently.
Worked solution 45 min
- Write the surrogacy condition in one sentence and state explicitly that it is untestable from any single experiment, which is why the validation has to pool evidence across many completed experiments.
- Define the index at the account level from the three named component metrics, and state that the weights come from the cross-experiment fit rather than from judgement.
- Set up the validation regression with one row per completed experiment: the month-6 retention effect on the three-week index effect, and report slope, confidence interval and residual standard deviation.
- Convert a worked index reading into a retention interval using the slope and residual spread, and check whether that interval excludes zero at the effect sizes teams typically ship.
- Write the invalidation rule as a named list of mechanisms absent from the corpus, and the governance rule for confirmatory holdouts and periodic re-estimation.
Follow-up
- Your corpus has 40 completed experiments and the slope confidence interval is wide. What do you ship on in the meantime, and what do you tell the teams?
- A team's treatment raises the index by exactly the amount your slope says is worth one retention point, but the mechanism is push notifications. What is your recommendation?
- How would you detect that the surrogate has drifted, using only the confirmatory holdouts you have been collecting?
Revenue per engaged account slid with no price change
Net revenue per active account-month fell 7% across two closed months. No list price changed and no discount campaign ran. You have fct_subscription_period (account_id, period_start_ts, period_end_ts, plan_tier, billing_interval, net_amount_usd, currency_code, is_promotional, payment_status), dim_account (signup_country, plan_tier, billing_provider, first_paid_ts) and the qualified-stream denominator from fct_stream. Decide whether revenue per paying account fell or the denominator changed, and where. Deliverable: a decomposition across numerator and denominator naming the two largest contributing segments and whether each is reversible.
Approach
- Split the ratio before splitting any segment. Revenue per engaged account equals revenue per paying account multiplied by paying accounts over engaged accounts. A growing free_ad_supported tier moves only the second factor and looks identical to a pricing problem in the headline.
- Cut the numerator by signup_country and currency_code and recompute at both period-of-record and fixed exchange rates. If local list prices are unchanged, a simultaneous USD fall across many countries is FX, and the fixed-rate series says so in one line instead of a meeting.
- Decompose revenue per paying account into within-segment change and mix over (plan_tier x billing_interval x signup_country) cells. Annual periods recognise pro rata across months, so a monthly-to-annual shift changes recognised revenue per account-month without changing what anybody paid over a year — a real accounting move with no economic content.
- Treat the denominator's composition as its own problem. Engaged accounts are distinct accounts with a qualified stream, so an acquisition push into a low-price market or into the free tier adds denominator months before it adds revenue and dilutes the ratio mechanically for a knowable number of months.
- Report the two segments carrying most of the move with their weight change and within-segment change shown side by side, and label which reverse on their own and which do not. That distinction is the actionable part of the answer; the 7% by itself is not.
Follow-up
- The ratio dilutes for some months after an acquisition push. How many, and how do you present the metric so a marketing success is not read as a regression every time?
- If the shift into annual billing is permanent, is the 7% real? What does the promotional-share guardrail say about it?
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 ↗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 ↗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 ↗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 ↗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 ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Nearly every data role forces a trade between the analysis you want and the one that fits the decision window. Prepare a case where you deliberately shipped something less rigorous, named the weakness to the person relying on it, and said what would change your answer. The naming is the part interviewers listen for.
Tell me about a situation where you had to deliver an analysis under a…
Tell me about a situation where you had to deliver an analysis under an extremely tight deadline with incomplete data.
Approach
- Close with what you would do differently, concretely.
- State the situation in two sentences and spend the rest on your reasoning.
- Quantify the outcome, including what you would not claim credit for.
Follow-up
- How did you know the outcome was caused by your change?
- What would you do differently if you ran that project again?
Give an executive a number you are not sure of
An executive needs a figure for a board deck by end of day: the effect on month-6 paid retention of a dunning-schedule change that has been running nine weeks. Your estimate is +1.2 points with a 95 percent interval of [-0.3, +2.7], and the month-6 cohort has not matured — you are projecting from month-2 behaviour. They say "one number, no ranges, it's a board deck." Deliverable: the figure you supply, the single sentence that sits under it, and what you do if the sentence is deleted.
Approach
- The probe is whether you can be useful under a constraint you disagree with. Supply the number. A refusal gets replaced within the hour by someone else's number carrying no caveat at all, which is strictly worse than yours carrying a short one.
- Separate the two uncertainties, because they behave differently and only one shrinks with patience. Sampling error is the interval and narrows as weeks accumulate. Extrapolation error from month-2 to month-6 does not narrow at all and is bounded only by evidence.
- Bound the extrapolation empirically before the deck goes out: on the last several fully matured cohorts, check how closely month-2 retention predicted month-6, and report that spread. This converts "we are projecting" from a hedge into a number, which is the only form of caveat that survives a slide.
- Translate the interval into the decision rather than the statistic. The executive needs the range only where it flips an action, so say at which end of it the change stops paying for itself, and otherwise give the point estimate.
- Commit to the date the figure becomes an observation — the cohort reaching 180 days of age, with monthly and annual billing intervals reported as separate curves since an annual account has had no opportunity to churn before day 365 — and put that date in the footnote so the projection has an expiry.
Follow-up
- The deck ships with your number and the footnote removed. What do you do, and when?
- How does your answer change if the interval were [-1.5, +2.7] — wide and straddling zero more evenly?
- What is the difference between what you have produced here and a forecast, and does the executive need to know?
Scope a one-line request about home row performance
A director messages you: "Is the new home row working?" Nothing else. A new ranker_version has been serving a fraction of profiles for eleven days. You have fct_impression (surface, slate_position, ranker_version, is_exploration_slot, logging_propensity, experiment_assignment_id, was_clicked) and fct_stream (impression_id, start_source, is_qualified, played_seconds). You get a fifteen-minute call before they go into a rollout meeting. Deliverable: the three questions you ask before writing any SQL, the single primary metric you commit to with its guardrail, and the questions you tell them this data cannot answer.
Approach
- The probe is whether you convert a vague request into a decision before producing a number. Ask what happens at each answer — rollback, widen, iterate — because a question whose answer changes nothing is a report request and should be scoped as one.
- Pin the unit of analysis out loud. fct_impression is at (profile, slate, slot) grain and experiment_assignment_id is per assignment, so the comparison must be aggregated to the assignment unit first; comparing impression-level rates lets a change in slate length move the metric on its own.
- Commit to one primary metric from the tree — qualified hours per active account-week for assigned accounts — and name the guardrail pair explicitly: share of qualified streams with start_source = 'autoplay_continuation', and median completion_ratio within content_type. A ranker can lift qualified stream counts by queueing short items that clear the 30-second threshold, and the guardrail is the only thing that catches it.
- State the refusals with structural reasons, not time reasons: eleven days gives no matured cohort, so month-6 retention and net revenue per active account-month are unanswerable; and logging_propensity is populated only where is_exploration_slot = true, so the positivity condition for an off-policy estimate fails outside those slots.
- Write the scope back in one paragraph — decision, metric, guardrail, the date the read becomes valid — and get it agreed in the thread before querying, so the number that arrives is the number that was asked for.
Follow-up
- They reply "just give me click-through by slate position." What do you say, and what would that number actually tell them?
- The eleven days include a weekend and a large release landing on day six. Does that change the metric you commit to, or only the read date?
- What would have to be true for you to be willing to answer the retention question from this experiment?
- 01
Tell me about a situation where you had to deliver an analysis under an extremely tight deadline with incomplete data.
- 02
An executive needs a figure for a board deck by end of day: the effect on month-6 paid retention of a dunning-schedule change that has been running nine weeks. Your estimate is +1.2 points with a 95 percent interval of [-0.3, +2.7], and the month-6 cohort has not matured — you are projecting from month-2 behaviour. They say "one number, no ranges, it's a board deck." Deliverable: the figure you supply, the single sentence that sits under it, and what you do if the sentence is deleted.
- 03
A director messages you: "Is the new home row working?" Nothing else. A new ranker_version has been serving a fraction of profiles for eleven days. You have fct_impression (surface, slate_position, ranker_version, is_exploration_slot, logging_propensity, experiment_assignment_id, was_clicked) and fct_stream (impression_id, start_source, is_qualified, played_seconds). You get a fifteen-minute call before they go into a rollout meeting. Deliverable: the three questions you ask before writing any SQL, the single primary metric you commit to with its guardrail, and the questions you tell them this data cannot answer.
Is this an official Twitch interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Twitch. Rounds and questions reflect what candidates have reported, not a process Twitch has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the interview loop for a Data Scientist at Twitch?
The interview process is rigorous and demanding, particularly during the technical coding screens and deep-dive case rounds. While interviewers are generally supportive and conversational, they expect high standards of accuracy in SQL and deep conceptual clarity in experimentation and product metrics.
PracHub interview research ↗What is the typical timeline from the initial recruiter screen to a final offer?
The entire interview process generally spans two to four weeks from your first recruiter conversation to the final decision. This timeline can vary based on scheduling coordination for the onsite panel and the specific hiring urgency of the team you are interviewing with.
PracHub interview research ↗Are remote work options available for this role?
While the central analytics and finance teams are primarily based in hubs like San Francisco, Seattle, and New York, specific remote or hybrid flexibility depends on the exact team and current company workplace policies. Be sure to clarify location expectations with your recruiter early in the process.
PracHub interview research ↗What differentiates successful candidates from those who do not pass?
Successful candidates consistently bridge the gap between technical execution and business impact. They do not just write working SQL queries or run statistical tests; they proactively structure ambiguous product problems, explain their underlying assumptions, and tie their findings back to creator and viewer value.
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