twitch Data Analyst Interview: Questions, Experience & Prep (2026)

Twitch is Amazon's live-streaming platform and hires Data Analysts to work on product analytics, creator monetisation, viewer engagement, and trust-and-safety. With 70 open roles currently listed, the team is actively building out its data function. Candidates report a process that typically spans 3-5 rounds, mixing a take-home SQL test or timed coding screen, a product case round, and behavioural interviews.

Across India, knok's job radar tracked 319 Data Analyst openings as of July 2026. The leading cities are Bangalore (41 roles), Delhi (22), Mumbai (19), Hyderabad (14), Pune (10), and Chennai (5). Salary ranges for the role in India:

If you are applying to Twitch, expect interviewers to care deeply about the streaming and gaming context. Familiarity with concepts like concurrent viewers, streamer retention, and subscription economics is a real advantage going in.

Twitch interviewers typically blend SQL, product metrics, and behavioural questions. Candidates report these coming up most often:

1. How would you define and measure 'streamer health' as a metric at Twitch?
2. Twitch launches a feature to encourage first-time donations during live streams. What metrics would you track to evaluate whether it is working?
3. A popular streamer's viewership drops sharply after a platform update. How would you investigate whether the platform caused the drop?
4. Write a SQL query to find the streamers with the highest average concurrent viewers over the past 30 days among those who went live at least 5 times. What functions would you use?
5. How would you design an A/B test to measure whether showing recommended channels in a sidebar increases a viewer's total session time?
6. You notice that subscription conversion differs significantly between mobile and desktop users. How do you decide if this is a product problem or a natural user-behaviour difference?
7. Twitch wants to reduce viewer drop-off. How would you identify which viewers are most at risk of leaving the platform?
8. How would you estimate the lifetime value of a Twitch subscriber, and what data would you need to do it properly?
9. A product manager asks: does sending a 'raid' (directing your live audience to another channel) improve the raided streamer's long-term viewer retention? How would you answer this with data?
10. Describe a time when your analysis changed a product or business decision. What did you find, and how did you present it?
11. How would you approach measuring the impact of Twitch's recommendation algorithm on new streamer discoverability?
12. If two metrics you track are moving in opposite directions at the same time, how do you decide which one to prioritise?

Use the STAR format (Situation, Task, Action, Result) for all behavioural and case questions. Here are three model answers.

Q: Twitch launches a feature to encourage first-time donations. What metrics would you track?

*Situation:* At my previous company, a similar 'first action' feature was launched for a social platform with no clear success metric in place.

*Task:* My job was to define a measurement framework before the feature went live so the team could make a clean call on whether to expand or roll back.

*Action:* I set a primary metric (first-donation conversion rate among eligible viewers), a guardrail metric (streamer session length, to catch any friction the new UI caused), and a secondary metric (repeat donation rate at 30 days, to check quality and not just volume). I also mapped the funnel from feature impression to donation completion so we could spot exactly where users dropped off.

*Result:* The team had clear decision criteria from day one. When the feature launched, we spotted a drop in the funnel at the payment confirmation step, fixed a UI issue within two days, and the conversion rate recovered. The feature was rolled out to all users after the test period.

---

Q: A streamer's viewership drops sharply after a platform update. How do you investigate?

*Situation:* During a product release cycle at a previous role, we saw a sudden dip in a key engagement metric the day after a backend change went live.

*Task:* I needed to confirm or rule out whether the release caused the drop before the team committed to a full rollback.

*Action:* I started by checking the timeline: did the drop align exactly with the deployment? Then I segmented by platform (iOS, Android, web) and by streamer category to see if the drop was universal or isolated. I compared the affected streamers with a matched control group of similar streamers who had not been exposed to the new code path.

*Result:* The analysis showed the drop was isolated to one streamer category on iOS, pointing to a rendering bug in the new player code. Engineering confirmed the cause within hours. A targeted fix went out the next day and metrics recovered, avoiding a full rollback that would have delayed other features.

---

Q: Describe a time your analysis changed a business decision.

*Situation:* The growth team at my last company planned to increase push notification frequency to boost daily active users.

*Task:* I was asked to model the expected impact before the change went out to production.

*Action:* I pulled cohort data on notification frequency versus unsubscribe rates and session starts. I built a model showing that beyond a certain frequency threshold, unsubscribes accelerated faster than new sessions were gained, producing a net negative on monthly active users over three months.

*Result:* The team paused the plan and ran a smaller test at a lower frequency, which confirmed the model's direction. The final notification strategy used a lower cap, which Glassdoor-reviewed teammates later cited as one of the stronger product calls that quarter.

For metrics and measurement questions: Start with the goal ('What behaviour are we trying to change?'), name a primary metric, add one or two guardrail metrics to protect against side effects, then describe the data you would need. Twitch interviewers want to see you distinguish between activity metrics (concurrent viewers, session time) and quality metrics (subscription conversion, creator retention).

For SQL questions: Talk through your logic out loud before writing. Name the tables you expect to exist (events, users, streams), the join keys, and any window functions you plan to use. Twitch data is likely event-based and time-series heavy, so show comfort with aggregations over rolling windows and sessionisation queries.

For investigation or 'something broke' questions: Use a structured funnel: confirm the data is real (not a tracking bug), check timing alignment with any recent changes, segment by platform and user type, then compare against a control group. Avoid jumping to a single cause before you have ruled out the others.

For A/B testing questions: Cover the randomisation unit (viewer-level vs streamer-level), sample size reasoning, the minimum detectable effect you care about, and how long you would run the test. Twitch has high variance in viewership data, so mention that you would account for this when sizing the experiment.

For 'tell me about a time' questions: STAR is the standard structure. Keep the Situation brief (one or two sentences), make the Action specific and personal ('I did X' not 'we did X'), and quantify the Result when you can. If your numbers are confidential, describe the scale of impact instead of inventing a figure.

Domain fluency: Twitch interviewers expect you to understand the streaming ecosystem. Know what concurrent viewers, peak vs average viewership, subscriber churn, raid mechanics, and Bits (Twitch's virtual currency) are. You do not need to be a gamer, but you should have used the product before the interview.

Strong SQL: Candidates report that SQL is tested in almost every process, typically via a take-home problem or a live coding screen. Practise window functions, CTEs, and time-series aggregations. Twitch data is event-heavy, so expect questions involving timestamps and session stitching.

Product instinct: Twitch analysts are expected to push back, ask 'why', and suggest what to measure, not just answer the question as given. Show that you think about the downstream decisions your analysis will inform.

Clear communication: Interviewers at Twitch typically want to see you structure your thinking before diving into code or numbers. A candidate who says 'let me make sure I understand the goal before I answer' scores better than one who rushes straight to a solution.

Amazon Leadership Principles: As an Amazon subsidiary, Twitch often incorporates Leadership Principle behavioural questions. 'Dive Deep', 'Customer Obsession', and 'Invent and Simplify' come up most in data roles. Prepare two or three strong stories mapped to each of these before your first round.

Week 1: SQL and domain foundation
Do at least one complex SQL problem per day, focusing on window functions (ROW_NUMBER, LAG, LEAD, SUM OVER), CTEs, and self-joins. Separately, spend a few hours using Twitch as a viewer and a curious analyst: note what metrics the platform might care about and why certain features exist where they do.

Week 2: Product and metrics practice
Practise product analytics frameworks. For any Twitch feature you can think of (Clips, Channel Points, Predictions, Hype Train), define a success metric, a guardrail metric, and a way to measure both. This maps directly to what interviewers test in the product round.

Week 3: Behavioural and Amazon Leadership Principles
Write out five stories from your past work using the STAR format. Map each story to the Leadership Principles most relevant to data roles: Dive Deep, Are Right A Lot, and Customer Obsession. Practice saying them out loud so they feel natural rather than rehearsed under pressure.

Week 4: Mock rounds and gap fixing
Do at least two full mock interviews: one SQL-focused, one product case. Ask a peer or mentor to play interviewer. After each mock, write down what you skipped or assumed without explaining, then go back and fix those gaps. Candidates report that structured practice in the final week makes a noticeable difference in composure on the day.

Jumping straight to code in SQL rounds. Interviewers want to see your reasoning, not just the query. State your assumptions, name the tables, then write. A query with clear thinking and a small bug scores better than a correct query with no explanation at all.

Defining only one metric for a product question. Always pair your primary metric with at least one guardrail. A feature that boosts donations but hurts streamer session length is not a clean win.

Treating Twitch like a generic tech company. Candidates who reference streaming-specific context (streamer-viewer dynamics, subscription vs ad revenue, creator dependency on the platform) stand out from those who give generic e-commerce-style answers.

Giving vague STAR answers. 'We improved the metric' is not a result. Use specific numbers from your own work where possible. If your data is confidential, describe the scale of the decision rather than inventing a figure.

Ignoring Amazon Leadership Principles. Twitch is an Amazon company. Candidates who do not prepare for ALP questions are often caught off guard in the behavioural round. Map your stories to the principles before your first technical round, not just before the final one.

Not asking clarifying questions. In product and investigation rounds, jumping to an answer without first asking 'what is the goal here?' or 'what does the data currently look like?' signals weak problem-solving instincts to the interviewer.