twitch Data Scientist Interview: Questions & Prep (2026)

Twitch, Amazon's live-streaming platform, is one of the most data-rich consumer products in the world. Every viewer session, creator stream, subscription click, and ad impression generates signals that Data Scientists turn into product decisions. Work at Twitch spans recommendation systems, creator growth analytics, ad relevance, viewer retention, and trust-and-safety.

Candidates report a multi-stage process that typically includes a recruiter screen, one or two technical rounds covering SQL and statistics, a product-sense or case discussion, and a behavioral panel grounded in Amazon's Leadership Principles. Round names and order vary by team, so treat all of these as preparation areas rather than a fixed sequence.

As of July 2026, knok jobradar tracked 937 open Data Scientist roles across India, with Bangalore leading at 166 postings. Twitch had 70 open roles at that time. The salary landscape for Data Scientists in India looks like this:

These ranges reflect publicly reported figures from industry surveys and will vary by company, city, and total compensation structure.

Candidates who have interviewed at Twitch typically report a mix of product, SQL, statistics, and behavioral questions. Here are the types most commonly cited:

1. How would you define and measure the health of Twitch's content recommendation system?
2. A popular streamer's viewership drops suddenly overnight. How would you investigate the root cause?
3. Design a metric to track creator retention. What signals would you look at at one week, one month, and three months after a creator first goes live?
4. Write a SQL query to find the top streamers by average concurrent viewers over a recent time window, filtering out accounts with very low activity.
5. How would you set up an A/B test for a new stream discovery feature on Twitch's home page?
6. What is a p-value, and why is it not enough on its own to make a product decision?
7. Twitch viewer counts can be inflated by bots. How would you detect and handle this in your analysis?
8. The subscription rate for a creator cohort is declining. How would you build a model to predict which creators are at risk of losing subscribers?
9. Twitch runs many experiments simultaneously. How would you handle potential interaction effects between them?
10. How would you measure whether a redesign of the chat experience improved user engagement without confounding the results?
11. Walk me through how you would build a creator recommendation model from scratch, from data collection to production deployment.
12. If viewer count, subscription rate, and chat activity all move in opposite directions after a product change, how would you decide if the change was a success?

Use the STAR format (Situation, Task, Action, Result) for all behavioral and case-style questions. Here are three examples tailored to Twitch-style prompts.

Q: A key engagement metric dropped sharply over a weekend. How did you handle it?

*Situation:* At a prior company, our live-video product's daily active sessions metric fell sharply on a Saturday morning with no scheduled release that day.

*Task:* I was asked to diagnose whether this was a data pipeline issue, a product bug, or an external event, and report findings to the product team by end of day.

*Action:* I first checked pipeline freshness and confirmed data was landing on schedule, ruling out an ingestion issue. I then segmented the drop by device type, geography, and user cohort. The drop was concentrated on Android users in two states while iOS and desktop were unaffected. I pulled app crash logs and found a spike in crashes tied to a dependency update that had rolled out silently through a third-party SDK.

*Result:* I shared a short written summary with engineering, who identified and reverted the dependency within a day. Sessions recovered to baseline, and the team set up a regional crash-rate alert so similar issues would surface automatically.

---

Q: Describe a time you designed an experiment under imperfect conditions.

*Situation:* A growth team wanted to test a new 'recommended creators' panel, but our user base in the target segment was small enough that standard power calculations suggested a very long run time.

*Task:* I had to balance statistical rigor with the team's need for a decision within a reasonable window.

*Action:* I narrowed the primary metric to one high-signal outcome (first subscription within the session) instead of a broad engagement composite. I ran the experiment for two full weeks to cover two weekday-weekend cycles and used sequential testing to monitor results without inflating false-positive risk. I also flagged clearly that any result would be directional, not conclusive, given the sample size.

*Result:* The panel showed a positive directional signal on first-subscription rate. The team launched a limited rollout with a plan to re-evaluate after the user base grew, rather than a full launch based on inconclusive data. The product manager appreciated the transparency about uncertainty.

---

Q: Tell me about a time you had to explain a complex finding to a non-technical audience.

*Situation:* I had built a creator churn model that showed a counterintuitive result: creators who streamed more frequently in their first month were actually more likely to churn within three months.

*Task:* I needed to present this to a product team that included non-technical stakeholders who assumed more streaming always meant more engagement.

*Action:* Instead of leading with model outputs, I opened with a story: 'Imagine a new creator who goes live every day for a month, burns out, and disappears. That is the pattern we are seeing in the data.' I then showed a simple chart of churn rate by early streaming frequency, held the model details for a follow-up appendix, and focused the discussion on what actions the team could take, specifically lighter onboarding nudges and wellness check-ins for high-frequency new creators.

*Result:* The team changed their new-creator onboarding flow to avoid pushing high-frequency streaming in the first month. A follow-up analysis showed improved three-month retention in the next creator cohort.

For product-sense and metrics questions: start by restating the goal in your own words, then name your north-star metric, two or three supporting metrics, and at least one guardrail metric that must not regress. Twitch interviewers care that you separate 'what we want to move' from 'what we cannot break.' For a streaming platform, guardrails often include stream quality and latency signals alongside engagement metrics.

For SQL questions: think out loud before writing. State which tables you would need, describe your join logic, and call out edge cases like null viewer counts or duplicate session rows before you start coding. Interviewers typically care as much about your reasoning process as the final query.

For statistics and experimentation questions: tie your answer to a business decision. Interviewers typically want to see that you understand when not to run an experiment (for example, when the segment is too small for meaningful power) and how you would handle inconclusive results. On a social platform like Twitch, always mention network interference as a potential threat to experiment validity.

For behavioral questions (Amazon Leadership Principles): use STAR format and say 'I' not 'we' to show your individual contribution. Candidates report that Twitch interviews weight 'Dive Deep' and 'Customer Obsession' most heavily. Prepare specific examples where you went beyond surface-level analysis or directly improved an outcome for creators or viewers.

Twitch interviewers typically look for candidates who connect data work to product outcomes. Raw technical skill matters, but the most common feedback candidates report is that interviewers want to see 'the so what,' not just the analysis.

Product intuition. Can you think like a product manager about what success looks like for Twitch creators and viewers? Candidates who frame every analysis in terms of a user experience tend to perform better than those who focus purely on model accuracy.

SQL fluency. Twitch interviews typically include at least one live SQL question. Interviewers want readable, correct queries and the ability to explain trade-offs in query design.

Statistical rigor. Streaming platforms have unusual experiment design challenges: network effects (one user's experience affects another's), novelty effects, and high variance in user behavior. Candidates who proactively name these challenges stand out.

Clear communication. Can you explain a finding to a product manager without dumbing it down or burying the insight in caveats? Interviewers often ask follow-up questions to test how you adjust your explanation for a non-technical audience.

Amazon Leadership Principles. Twitch is an Amazon company, so behavioral signals are weighted heavily. 'Dive Deep' means going below surface metrics to understand root causes. 'Customer Obsession' means anchoring every analysis to creator or viewer impact.

A structured four-week approach that candidates typically report works well:

Week 1: SQL and data fundamentals. Practice window functions, time-series aggregations, and join-heavy queries. Focus on streaming-data scenarios: per-user session metrics, ranking streamers by engagement, and detecting anomalies in time-series data.

Week 2: Product sense and metrics. Read Twitch's creator blog and advertiser resources to understand how the platform thinks about its business. Practice defining north-star metrics and guardrails for hypothetical features. Study the difference between engagement metrics (watch time, chat rate) and monetization metrics (subscription rate, bits per viewer).

Week 3: Statistics and experimentation. Review A/B test design, power analysis, and common pitfalls: novelty effects, network interference, and the multiple-testing problem. Practice explaining these concepts out loud as if talking to a product manager, not a statistician.

Week 4: Behavioral prep and mock interviews. Map two or three personal stories to Amazon Leadership Principles. Practice STAR answers and focus on 'I' language. Candidates report that Twitch interviews sometimes run back-to-back, so practice maintaining clarity and energy across multiple conversations in a single day.

For job discovery alongside your prep, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so you are not losing ground on applications while you study.

1. Jumping straight into SQL without restating the problem. Interviewers want to see your thinking, not just the query. Briefly confirming what the question is asking before writing a single line of code signals strong analytical instinct.

1. Picking metrics without naming guardrails. Always identify at least one metric that must not get worse. Forgetting guardrails is one of the most commonly cited gaps in product-sense interviews.

1. Treating every question as a pure technical puzzle. Twitch interviewers care about the 'so what.' Connect your analysis to a product decision or a user outcome.

1. Saying 'we' instead of 'I' in behavioral answers. Interviewers need to understand your individual contribution. Describe what you did, not what the team did.

1. Ignoring network effects in experimentation questions. Twitch is a social platform where one user's behavior affects others. Not mentioning the risk of experiment interference is a common miss.

1. Over-engineering model answers. A well-explained logistic regression with thoughtful feature engineering beats a complex deep learning model you cannot justify. Interviewers want to understand your reasoning, not your framework count.

1. Diving in without any clarifying questions. Taking a brief moment to restate the goal and the intended audience at the start of a question shows strong communication skills. Candidates who skip this step often end up solving the wrong problem.