← Meta Interview Insights

Meta·Data Scientist·Technical Phone Screen·Senior

SeniorPrefer not to say
May 2026Remote

Summary

Brutal SQL gauntlet at Meta for a DS role. Four parts, all in one question, covering conversion rates, churn, cancellation CIs, and rolling window comparisons with timezone-aware logic throughout. Felt like a take-home disguised as a live session.

Questions Asked (4)

Q1

Given a schema with users (including timezone), app sessions, and orders, write SQL to compute daily conversion rate by city and platform for the last 7 days using user-local dates, where conversion rate is distinct users with at least one completed order that day divided by distinct users with at least one session that day. Days with no data should emit zeroes.

Product Analytics & MetricsData Modeling
Author's notes

The timezone conversion part is what gets you.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the schema and metric definitions, then build a date spine of the last 7 days to ensure zero-fill. Compute daily distinct session users and daily distinct completed-order users per city, platform, and user-local date, then join and divide, handling division by zero.

Pro tip: Explicitly state that you are converting timestamps to user-local dates using the users.timezone before aggregating, and that you will use a date spine to emit zeroes for days with no data—this shows you understand the nuance of timezone-aware daily metrics and complete reporting.

1. Clarify schema and metric definitions

Confirm table structures, join keys, and definitions: conversion rate = distinct users with ≥1 completed order that day / distinct users with ≥1 session that day, using user-local dates.

2. Build a date spine for the last 7 days

Generate a series of the last 7 user-local dates (or a global date range) to left join against, ensuring days with no data produce zeroes.

3. Compute daily session users per city/platform

Join sessions to users, convert session timestamps to user-local dates using users.timezone, filter to last 7 days, and count distinct users per city, platform, and date.

4. Compute daily converted users per city/platform

Join completed orders to users, convert order timestamps to user-local dates, filter to last 7 days, and count distinct users with at least one completed order per city, platform, and date.

5. Join, divide, and zero-fill

Left join the session and conversion aggregates to the date spine, compute conversion rate as converted_users / session_users with safe division (e.g., NULLIF or CASE), and replace NULLs with 0.

Key Points to Mention

  • Use users.timezone to convert timestamps to user-local dates before aggregating.
  • Count distinct users for both numerator and denominator, not orders or sessions.
  • Filter to completed orders only (status = 'completed' or equivalent).
  • Use a date spine (e.g., GENERATE_DATE_ARRAY or recursive CTE) to ensure all 7 days appear, even with no data.
  • Handle division by zero with NULLIF or CASE to avoid errors and emit 0 when denominator is 0.
  • Group by city, platform, and user-local date; consider whether city/platform should come from users or sessions/orders.

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

Q2

Flag city-platform pairs where the 7-day average conversion rate dropped by more than 30% compared to the preceding 7-day window, using user-local dates and without double-counting users across platforms.

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

This is where I got turned around.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the metric definition and data model, then outline a SQL-based approach that uses user-local dates and deduplicates users across platforms. Finally, discuss how to validate results and handle edge cases like low-volume city-platform pairs.

Pro tip: Always check for data completeness and time zone consistency before flagging drops; a 30% drop could be due to missing data or a logging issue rather than a real trend. Also, consider using a Bayesian or confidence interval approach to avoid false positives from small sample sizes.

1. Clarify requirements and assumptions

Confirm the definition of conversion rate, the 7-day windows (e.g., rolling or fixed), and how to handle users active on multiple platforms. Ask about data availability and time zone handling.

2. Design the data extraction and deduplication logic

Write a query that assigns each user to a single platform (e.g., by first activity or primary platform) to avoid double-counting, and converts timestamps to user-local dates using a time zone offset table.

3. Compute 7-day averages and compare windows

Calculate the 7-day average conversion rate for each city-platform pair for the current and preceding windows, ensuring the windows are non-overlapping and aligned with user-local dates.

4. Flag significant drops and validate

Identify pairs where the drop exceeds 30%, then validate by checking sample sizes, data completeness, and potential confounders (e.g., seasonality, platform changes).

5. Communicate findings and next steps

Present the flagged pairs with context, suggest follow-up analyses (e.g., root cause, statistical significance), and discuss potential actions.

Key Points to Mention

  • User-local dates: use time zone offsets to convert UTC timestamps to local dates for accurate daily aggregation.
  • Deduplication: assign each user to a single platform per day (e.g., by first touch or primary platform) to avoid double-counting across platforms.
  • Window definition: ensure the 7-day windows are non-overlapping and correctly ordered (preceding window before current window).
  • Conversion rate calculation: define numerator (e.g., conversions) and denominator (e.g., active users) clearly, and handle zero denominators.
  • Statistical significance: consider confidence intervals or hypothesis testing to avoid flagging noise, especially for low-volume pairs.
  • Data quality checks: verify data completeness, time zone accuracy, and potential logging issues before concluding a real drop.

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

Q3

Return a list of churned users as of today, defined as users who had at least one completed order in a specified historical window but zero completed orders in a more recent window, using their local timezone. Include their last order local date and days since last order.

Product Analytics & MetricsData Modeling
Author's notes

Easiest of the four parts.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the definition of churn: users with at least one completed order in a historical window (e.g., 90-180 days ago) but zero completed orders in a recent window (e.g., last 90 days). Then, write a SQL query that joins user orders with a timezone conversion, aggregates order counts per user per window, and filters for churned users, finally calculating last order local date and days since last order.

Pro tip: Always confirm the exact windows and timezone handling with the interviewer, as different definitions can drastically change the churn list. Also, consider using a calendar table or date spine to ensure all dates are covered, especially for users with no orders in the recent window.

1. Clarify definitions and windows

Confirm the historical and recent windows (e.g., 90-180 days ago vs. last 90 days) and the definition of 'completed order'. Ensure you understand how to handle users' local timezones.

2. Convert timestamps to local time

Use the users' timezone information to convert order timestamps to local dates. This is crucial for accurate window filtering and for reporting last order local date.

3. Aggregate orders per user per window

For each user, count completed orders in the historical window and in the recent window. Use conditional aggregation or separate subqueries.

4. Filter churned users

Select users who have at least one order in the historical window and zero orders in the recent window.

5. Compute last order date and days since

For each churned user, find the maximum order local date (which will be in the historical window) and calculate days since last order as the difference between today's date and that date.

Key Points to Mention

  • Timezone conversion: use the user's local timezone to determine the correct local date for each order, especially for defining window boundaries.
  • Window definitions: clearly specify the historical and recent windows (e.g., 90-180 days ago and last 90 days) and ensure they are non-overlapping.
  • Completed orders: filter only orders with status 'completed' or equivalent.
  • Handling users with no orders in recent window: ensure they are included even if they have no recent orders, which may require a left join or careful filtering.
  • Calculation of days since last order: use date difference functions (e.g., DATEDIFF) between today and the last order local date.
  • Edge cases: consider users with multiple timezones (if they moved), and ensure the query is efficient for large datasets.

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

Q4

For the last 14 local days, compute cancellation rate by city (cancelled orders divided by all orders) and return the top 3 cities by largest absolute increase versus the prior 14 days. Include 95% Wilson confidence intervals for each period.

A/B Testing & ExperimentationProduct Analytics & MetricsData Modeling
Author's notes

The Wilson CI formula in SQL is genuinely painful to write from memory.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the definitions of 'local days', 'city', and 'cancelled orders', and confirm the time windows. Then, write a SQL query that aggregates orders into two 14-day periods per city, computes cancellation rates and Wilson confidence intervals, and calculates the absolute increase. Finally, rank cities by the increase and return the top 3 with their intervals.

Pro tip: When comparing periods, ensure you're using the same set of cities in both periods to avoid bias from cities with no prior data; consider filtering to cities with sufficient order volume in both periods to make the comparison meaningful.

1. Clarify requirements and definitions

Ask clarifying questions about 'local days' (e.g., timezone handling), 'city' (e.g., shipping city vs. billing city), and 'cancelled orders' (e.g., status definitions). Confirm the exact date ranges for the current and prior 14-day periods.

2. Aggregate orders by city and period

Write a SQL query to count total orders and cancelled orders per city for each 14-day window. Use conditional aggregation or separate subqueries, ensuring proper date filtering and grouping.

3. Compute cancellation rates and Wilson intervals

Calculate the cancellation rate for each city and period. Implement the Wilson score interval formula (or use a built-in function) to compute 95% confidence intervals for each rate.

4. Calculate absolute increase and rank

Compute the absolute difference in cancellation rates between the current and prior periods for each city. Rank cities by this difference in descending order and select the top 3.

5. Present results with intervals

Return the top 3 cities along with their cancellation rates and Wilson confidence intervals for both periods, and the absolute increase. Optionally, include a brief interpretation of the intervals.

Key Points to Mention

  • Definition of 'local days' and timezone considerations (e.g., using the city's local timezone for date boundaries).
  • Handling of cities with zero orders in either period (e.g., exclude or treat as zero rate with caution).
  • The Wilson score interval formula and why it's preferred over normal approximation for proportions, especially with small sample sizes.
  • The importance of comparing the same set of cities across periods to avoid selection bias.
  • Potential need for statistical significance testing (e.g., overlapping confidence intervals) to assess if the increase is meaningful.
  • Efficient SQL implementation using window functions or CTEs to avoid repeated scans.

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