← Snapchat Interview Insights

Snapchat·Data Scientist·Technical Phone Screen·Senior

SeniorPrefer not to say
Apr 2026Remote

Summary

Snapchat data scientist interview that was basically one long pandas coding problem with a bunch of sub-tasks crammed in. The question covered click metrics, session analysis, and cohort breakdowns all at once, which felt like three interviews in one. I was not expecting the level of specificity around accidental click definitions.

Questions Asked (4)

Q1

Given two DataFrames for events and users, define 'accidental clicks' as banner clicks with dwell under 500ms or followed by a back navigation from the same user within 2 seconds. Then compute daily per-banner CTR over the last 7 days, excluding bots and accidental clicks. Output should include date, banner_id, impressions, valid_clicks, and CTR.

Product Analytics & MetricsData Modeling
Author's notes

This was the core of the whole thing and it took me a while to even parse what they wanted.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the definitions and assumptions, then outline a step-by-step plan: join events and users, filter bots, identify accidental clicks using dwell time and back navigation, aggregate daily per-banner impressions and valid clicks, and compute CTR. Emphasize the importance of handling edge cases like multiple back navigations and time windows.

Pro tip: When defining accidental clicks, consider that a back navigation within 2 seconds might occur after the dwell time threshold; ensure you capture both conditions without double-counting. Also, discuss how to handle users with multiple sessions and the potential need for sessionization.

1. Clarify Definitions and Assumptions

Confirm what constitutes an impression, a click, and a back navigation event. Clarify if 'dwell under 500ms' applies only to clicks and if back navigation is a separate event type.

2. Data Preparation and Bot Filtering

Join events and users DataFrames on user_id. Filter out bot users based on a bot flag or heuristic (e.g., user_agent, activity patterns).

3. Identify Accidental Clicks

For each click event, check if dwell time < 500ms. Also, check if there is a back navigation event from the same user within 2 seconds after the click. Mark clicks meeting either condition as accidental.

4. Aggregate Daily Metrics

Filter events to last 7 days. Group by date and banner_id, counting total impressions and valid clicks (clicks excluding accidental ones).

5. Compute CTR and Output

Calculate CTR as valid_clicks / impressions. Ensure output includes date, banner_id, impressions, valid_clicks, and CTR, sorted appropriately.

Key Points to Mention

  • Definition of accidental clicks: dwell time < 500ms OR back navigation within 2 seconds.
  • Bot filtering: use a bot flag or define heuristics (e.g., user agent, rapid activity).
  • Time windows: ensure back navigation is within 2 seconds after the click, and consider timezone consistency.
  • Handling multiple events: avoid double-counting clicks that meet both accidental conditions.
  • Edge cases: clicks without dwell time, back navigation without a preceding click, and users with multiple clicks.
  • CTR calculation: valid_clicks / impressions, and potential need to handle zero impressions.

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

Q2

Compute user-level 7-day CTR with the same bot and accidental click exclusions, then break down the distribution by signup cohort defined as the week of the user's signup date.

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

Felt more manageable after the first part.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the metric definition and exclusions (bot traffic, accidental clicks) and confirm the data sources and time window. Then compute user-level 7-day CTR by aggregating clicks and impressions per user over a 7-day period, applying the exclusions. Finally, assign each user to a signup cohort based on the week of their signup date and analyze the distribution of CTR across cohorts, looking for trends or anomalies.

Pro tip: When defining cohorts, ensure you use the user's signup date, not the date of first activity, to avoid misclassification. Also, consider that users in different cohorts may have different exposure to product changes, so interpret trends cautiously and check for confounding factors like seasonality or feature launches.

1. Clarify metric and exclusions

Define what constitutes a bot and an accidental click, and confirm the exclusion criteria with the interviewer. Specify the 7-day window (e.g., rolling 7 days per user) and the CTR formula: total clicks / total impressions per user.

2. Data extraction and cleaning

Identify the relevant tables (e.g., event logs for impressions and clicks, user metadata for signup date). Filter out bot traffic and accidental clicks using the agreed criteria, and ensure data quality (e.g., handle missing values, deduplicate events).

3. Compute user-level CTR

For each user, aggregate clicks and impressions over the 7-day period, then calculate CTR as clicks/impressions. Handle edge cases like zero impressions (exclude or set to null) and ensure the metric is computed per user, not per session.

4. Assign signup cohorts

Determine each user's signup week (e.g., week starting Monday) based on their signup date. Group users into cohorts accordingly, ensuring consistent week definitions across the dataset.

5. Analyze distribution by cohort

For each cohort, compute summary statistics (mean, median, percentiles) of user-level CTR and visualize the distribution (e.g., box plots, histograms). Compare cohorts over time to identify trends, and consider statistical tests if needed.

Key Points to Mention

  • Definition of bot traffic and accidental clicks, and how to operationalize exclusions (e.g., using heuristics like click frequency, time between impression and click, or device signals).
  • Importance of user-level aggregation: CTR should be computed per user to avoid skew from heavy users, and then aggregated for cohort analysis.
  • Handling of users with zero impressions: whether to exclude them or include as zero CTR, and the impact on distribution.
  • Cohort definition: using signup week (e.g., ISO week) and ensuring alignment with business weeks (e.g., starting Sunday or Monday).
  • Potential confounders: product changes, seasonality, or marketing campaigns that could affect cohorts differently, and how to account for them.
  • Visualization and statistical testing: using distributions rather than just averages, and testing for significant differences between cohorts.

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

Q3

For a Group Story feature, compute the per-user change in average session duration between a pre-period and a post-period. Sessions are defined by gaps of more than 30 minutes between consecutive events from the same user. Also track the change in stories posted per user across the two periods.

Product Analytics & MetricsA/B Testing & ExperimentationRoot Cause Analysis
Author's notes

Session definition questions always sound clean until you actually try to implement them without loops.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the business context and define the pre- and post-periods, the sessionization logic, and the target metrics. Then outline a SQL-based approach to compute per-user average session duration and stories posted in each period, and calculate the change. Finally, discuss how to validate the results and interpret the changes in light of the Group Story feature.

Pro tip: Always check for data quality issues like missing events or users with no sessions in one period, and consider using a robust aggregation method (e.g., median) if the distribution is skewed. Also, segment the analysis by user activity level to avoid Simpson's paradox.

1. Clarify Requirements and Define Metrics

Confirm the exact definitions of pre- and post-periods, sessionization rule (30-minute gap), and the metrics: average session duration per user and stories posted per user. Ensure alignment with stakeholders on edge cases (e.g., users with no sessions).

2. Design Data Extraction and Sessionization Logic

Write SQL to assign session IDs by flagging gaps >30 minutes between consecutive events per user, then aggregate events into sessions. Compute session duration as the time between first and last event in each session.

3. Compute Per-User Metrics for Each Period

For each user, calculate average session duration (mean of session durations) and total stories posted in the pre-period and post-period separately. Handle users with no sessions by excluding them or imputing zero based on business rules.

4. Calculate Change and Validate Results

Compute the per-user change (post - pre) for both metrics. Validate by checking distributions, outliers, and ensuring no data leakage. Consider statistical significance if comparing groups.

5. Interpret and Communicate Findings

Summarize the average change across users, segment by relevant dimensions (e.g., user tenure, engagement level), and relate to the Group Story feature launch. Discuss potential confounders and next steps.

Key Points to Mention

  • Sessionization logic: gaps >30 minutes define new sessions; use window functions like LAG to compute time differences.
  • Per-user aggregation: average session duration is computed per user, then change is calculated; avoid mixing users with different session counts.
  • Handling missing data: users with no sessions in one period should be treated consistently (e.g., excluded or assigned zero) and documented.
  • Stories posted metric: count distinct stories posted per user in each period, ensuring no double-counting.
  • Statistical significance: consider paired t-test or bootstrap to test if the mean change is significant, especially with skewed data.
  • Segmentation: analyze changes by user cohorts (e.g., new vs. existing, high vs. low activity) to uncover heterogeneous effects.

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

Q4

How would you ensure the pandas code is fully vectorized, avoiding Python loops, and what indices would you set on these DataFrames? How would you test correctness using the provided sample data?

Technical Trade-offsData Modeling
Author's notes

Honestly the part I was least prepared to articulate under pressure.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by explaining how you'd refactor the code to use vectorized pandas operations like merge, groupby, and apply with axis=1 only when necessary, and set appropriate indices for efficient lookups. Then describe a testing strategy that validates both correctness and performance using the provided sample data, including edge cases.

Pro tip: Emphasize that vectorization isn't just about avoiding loops—it's about leveraging pandas' optimized C implementations and minimizing memory overhead. Also, mention that setting the right index can turn O(n) lookups into O(1) hash-based operations.

1. Identify and eliminate Python loops

Scan the code for for-loops, iterrows, and apply with axis=1, and replace them with vectorized alternatives like merge, join, groupby, and boolean indexing.

2. Optimize DataFrame indices

Set indices on columns frequently used for filtering, joining, or grouping to enable fast hash-based lookups and reduce computational overhead.

3. Validate correctness with sample data

Use the provided sample data to compare outputs from the original and vectorized versions, ensuring identical results and checking edge cases like missing values.

4. Benchmark performance

Measure execution time and memory usage before and after vectorization to demonstrate the efficiency gains, using tools like %timeit or pandas profiling.

5. Document and communicate trade-offs

Explain any trade-offs such as increased memory usage or reduced readability, and justify why vectorization is still preferable for scalability.

Key Points to Mention

  • Use of vectorized operations: merge, join, groupby, pivot, and boolean indexing instead of loops.
  • Setting indices on key columns (e.g., user_id, timestamp) to speed up joins and lookups.
  • Avoiding iterrows and apply with axis=1; using apply only for complex row-wise operations when no vectorized alternative exists.
  • Testing strategy: unit tests with sample data, comparing outputs, and checking for NaN handling and data type consistency.
  • Performance metrics: time and memory benchmarks to quantify improvements.
  • Scalability considerations: how vectorization handles larger datasets and reduces computational complexity.

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