← Twitch Interview Insights

Twitch·Data Scientist·Technical Phone Screen·Senior

Senior
Jul 2026Remote

Summary

Twitch data scientist interview with a heavy SQL focus. Four problems, all streaming analytics, all nastier than they look on paper. The schema is clean but the edge cases are where they actually test you.

Questions Asked (4)

Q1

Given a streaming platform schema with view start/stop events, write a SQL query to find peak concurrent viewers per stream and the time window where that peak occurs. Events may arrive out of order and exact duplicate rows must be deduplicated.

Product Analytics & MetricsData Modeling
Author's notes

This one wrecked me more than I expected.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, deduplicate the event table using SELECT DISTINCT or a window function to remove exact duplicate rows. Then, convert each event into a +1 (start) or -1 (stop) delta, and compute a running sum ordered by event timestamp to get concurrent viewer counts. Finally, identify the peak concurrency per stream and the time window by finding the maximum running sum and the timestamps where that peak occurs.

Pro tip: Mention that you would validate the event stream for missing stop events (e.g., sessions that never end) and handle them by capping at stream end or using a default timeout, as this is a common data quality issue in streaming platforms.

1. Deduplicate events

Remove exact duplicate rows using SELECT DISTINCT or ROW_NUMBER() over all columns to ensure each event is counted once.

2. Convert events to deltas

Assign +1 for view start and -1 for view stop, then union all events into a single stream with their timestamps.

3. Compute running concurrency

Use a window function SUM(delta) OVER (PARTITION BY stream_id ORDER BY event_time) to calculate concurrent viewers at each event time.

4. Find peak and time window

For each stream, find the maximum concurrency and the earliest and latest timestamps where that maximum occurs to define the peak window.

5. Handle out-of-order and edge cases

Ensure ordering by event_time (not ingestion time) and consider ties, missing stops, or overlapping sessions when defining the window.

Key Points to Mention

  • Deduplication strategy: exact duplicate rows removed via DISTINCT or ROW_NUMBER().
  • Event ordering: use event timestamp, not ingestion time, to handle out-of-order arrival.
  • Running sum with window function to compute concurrent viewers.
  • Peak detection: use MAX() and filter for rows where concurrency equals the peak.
  • Time window definition: earliest and latest timestamps at peak concurrency.
  • Data quality: handle missing stop events (e.g., sessions without end) by capping or imputing.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

For users who watched multiple different streams simultaneously on a given date, compute the total minutes each user spent watching two streams concurrently, but only count overlap windows of at least 5 minutes.

Data ModelingAlgorithms & Data Structures
Author's notes

Probably the hardest of the four.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the data schema and define what constitutes a 'stream' and 'concurrent watching'. Then, for each user and date, generate all pairs of streams they watched, compute the overlap duration between each pair, filter overlaps >= 5 minutes, and sum these durations per user.

Pro tip: Mention that you would validate the logic with edge cases like back-to-back streams with no overlap or exactly 5-minute overlaps, and discuss how to handle time zones and session boundaries.

1. Clarify requirements and data schema

Ask questions to understand the data: what fields are available (user_id, stream_id, start_time, end_time), whether streams can be watched on multiple devices, and how to handle time zones. Confirm that 'concurrently' means the user was actively watching both streams at the same time.

2. Identify user-date-stream sessions

For each user and date, extract all stream watching sessions. Ensure each session has a clear start and end time. If a user watched the same stream multiple times, treat each session separately or merge if contiguous.

3. Generate stream pairs and compute overlaps

For each user-date, generate all unique pairs of streams. For each pair, compute the overlap duration between their watching intervals. If a stream has multiple sessions, consider all combinations of sessions from the two streams.

4. Filter and sum overlaps

Filter out overlaps shorter than 5 minutes. Sum the remaining overlap durations for each user. Be careful not to double-count if a user watched three streams simultaneously; decide whether to count pairwise overlaps or distinct concurrent watching time.

5. Validate and handle edge cases

Test with edge cases: no overlap, exactly 5-minute overlap, multiple overlapping streams, and streams spanning midnight. Discuss how to handle time zone conversions and whether to consider only the given date or allow overlaps that cross date boundaries.

Key Points to Mention

  • Definition of concurrency: user must be actively watching both streams at the same time, not just having them open.
  • Handling multiple sessions per stream: a user might watch a stream, leave, and return; each session should be considered separately for overlap calculation.
  • Overlap calculation: use interval intersection logic (max(start1, start2) to min(end1, end2)) and compute duration in minutes.
  • Threshold of 5 minutes: only count overlaps where the intersection duration is >= 5 minutes.
  • Avoiding double-counting: if a user watches three streams simultaneously, clarify whether to count all pairwise overlaps or the total time with at least two streams.
  • Scalability: discuss efficient algorithms (e.g., sweep line) for large datasets, and whether to process per user-date to reduce complexity.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

Compute D+7 retention for users whose first-ever view was in a specified date range. A user is retained if they watch any stream for at least 2 continuous minutes on exactly their 7th day after first view.

Product Analytics & MetricsA/B Testing & Experimentation
Author's notes

Retention queries are familiar territory but the '2 continuous minutes' condition adds a layer.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the exact definitions of 'first-ever view', 'D+7', and '2 continuous minutes' to ensure alignment. Then, outline a SQL-based approach: identify the cohort of users with first view in the date range, compute their 7th day after first view, and check if they have a qualifying watch session on that day. Finally, calculate the retention rate as the proportion of retained users in the cohort.

Pro tip: Mention that you would validate the retention metric by checking edge cases, such as users with multiple sessions on D+7 or sessions that span midnight, and consider time zone handling.

1. Clarify Definitions

Confirm what constitutes a 'view' (e.g., any stream watch), how to determine 'first-ever view', and the exact meaning of 'exactly their 7th day after first view' (e.g., calendar day vs. 24-hour periods). Also clarify if '2 continuous minutes' means a single uninterrupted session or can be aggregated.

2. Identify Cohort

Write a query to select users whose first-ever view timestamp falls within the specified date range. This involves finding the minimum view timestamp per user and filtering.

3. Compute D+7 Date

For each user in the cohort, calculate the date that is exactly 7 days after their first view date (e.g., using DATE_ADD or equivalent). Ensure consistent date truncation.

4. Check Retention Condition

For each user, determine if they have any watch session on their D+7 date that lasts at least 2 continuous minutes. This may require sessionization logic to identify continuous watch periods.

5. Calculate Retention Rate

Count the number of retained users and divide by the total cohort size to get the D+7 retention rate. Consider breaking down by dimensions if needed.

Key Points to Mention

  • Cohort definition: users with first-ever view in the date range, ensuring no prior views.
  • D+7 calculation: use date functions to add 7 days to the first view date, handling time zones appropriately.
  • Sessionization: define continuous watch time, possibly using gaps-and-islands technique to identify sessions of at least 2 minutes.
  • Retention condition: user must have a qualifying session on exactly D+7, not before or after.
  • Edge cases: sessions crossing midnight, multiple sessions on D+7, and time zone consistency.
  • SQL implementation: use window functions (e.g., ROW_NUMBER, LAG) to find first view and sessionization.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

Rank creators by average per-viewer watch time over a 7-day window, restricted to US viewers. Only include creators with at least 100 unique US viewers. Break ties using peak concurrency from the earlier query.

Product Analytics & MetricsData Modeling
Author's notes

Tying this back to the peak concurrency result from the first question is a nice touch.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the metric definition: average per-viewer watch time = total watch time / unique viewers, computed over a 7-day window and filtered to US viewers. Then outline a SQL query that aggregates watch time and unique viewers per creator, applies a HAVING clause for at least 100 unique US viewers, and orders by average watch time descending, using peak concurrency as a tiebreaker. Finally, discuss how to handle edge cases like ties in peak concurrency and ensure the window is correctly applied.

Pro tip: Mention that you would validate the 7-day window by checking if it's a rolling window or a fixed calendar week, and confirm with stakeholders whether 'unique viewers' should be deduplicated across the entire window or daily. This shows attention to metric definition and business context.

1. Clarify metric definitions and constraints

Confirm what 'average per-viewer watch time' means (total watch time / unique viewers), the exact 7-day window (rolling vs. fixed), and that 'US viewers' is based on viewer location. Also confirm that 'unique US viewers' counts distinct viewers over the window.

2. Design the aggregation query

Write a SQL query that joins watch time data with viewer location, filters to US viewers, groups by creator, and computes total watch time and unique viewers. Apply a HAVING clause to include only creators with at least 100 unique US viewers.

3. Compute average watch time and rank

Calculate average per-viewer watch time as total watch time / unique viewers. Order creators by this metric descending. For ties, incorporate peak concurrency from the earlier query as a secondary sort key.

4. Handle ties and finalize ranking

If peak concurrency also ties, decide on a deterministic tiebreaker (e.g., creator ID) or report ties. Ensure the final output includes creator, average watch time, unique viewers, and peak concurrency for transparency.

5. Validate and discuss edge cases

Check for data quality issues (e.g., nulls, bot traffic), consider time zone handling for the 7-day window, and discuss how the metric might be gamed. Also mention performance considerations for large-scale data.

Key Points to Mention

  • Definition of average per-viewer watch time: total watch time divided by unique viewers.
  • Importance of filtering to US viewers and ensuring unique viewer count is distinct over the 7-day window.
  • Use of HAVING clause to enforce the minimum 100 unique US viewers threshold.
  • Tie-breaking logic using peak concurrency from a previous query, and fallback if needed.
  • Potential data quality issues: bot traffic, null locations, time zone alignment.
  • Scalability: using efficient aggregation and indexing for large datasets.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.