← Meta Interview Insights

Meta·Data Scientist·Technical Phone Screen·Senior

Senior
Apr 2026

Summary

Meta DS technical screen, one SQL question that looked manageable until I actually started writing it. Two separate metrics in one query, timezone conversion, and a 7-day rolling window all at once.

Questions Asked (1)

Q1

Given a users table and a calls table for a voice-calling product, write SQL to compute two metrics per report date: (1) the percentage of callers who made at least 20 calls in the past 7 days out of all callers active in that window, and (2) the percentage of Great Britain daily active users who had 50 or more total call participations (as caller or recipient) on that date. Return one row per report date with both percentages.

Product Analytics & MetricsData Modeling
Author's notes

The timezone piece got me first.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Break the problem into two independent metrics, each requiring a different aggregation window and population definition. For metric 1, compute a rolling 7-day window per report date and identify callers with at least 20 calls in that window, then divide by all active callers in the same window. For metric 2, filter to Great Britain users, compute daily call participations per user (as caller or recipient), and calculate the percentage with 50 or more participations on each date.

Pro tip: Clarify ambiguous terms like 'active caller' and 'call participation' before writing SQL—interviewers often expect you to ask about edge cases such as time zones, duplicate calls, or whether recipients are counted once per call. Also, consider using window functions or self-joins efficiently to avoid performance pitfalls.

1. Clarify definitions and assumptions

Confirm what 'active caller' means (e.g., made at least one call in the window), how to handle time zones, and whether 'call participation' counts each call once per user even if they are both caller and recipient. State any assumptions clearly.

2. Compute metric 1: rolling 7-day heavy caller percentage

For each report date, aggregate calls over the past 7 days per caller, count callers with >=20 calls, and divide by the total distinct callers active in that same 7-day window. Use a self-join or window function to handle the rolling window.

3. Compute metric 2: GB daily active users with >=50 participations

Filter users to Great Britain, then for each date count participations per user (as caller or recipient). Identify users with >=50 participations on that date and divide by all GB daily active users (those with at least one participation that day).

4. Combine results into one row per report date

Full outer join the two metric results on report date, ensuring all dates from either metric are included. Format percentages as decimals or percentages as required.

5. Validate and optimize

Check for edge cases like missing dates, zero denominators, and duplicate calls. Consider indexing or partitioning strategies for large datasets, and verify results with sample calculations.

Key Points to Mention

  • Define 'active caller' and 'call participation' explicitly, including whether recipients are counted and how to handle multiple participations in one call.
  • Use a rolling 7-day window for metric 1, which may require a self-join or window function to aggregate calls per caller per report date.
  • For metric 2, filter users by country = 'GB' and compute daily participations per user, ensuring both caller and recipient roles are counted.
  • Handle denominators carefully: metric 1 denominator is all distinct callers in the 7-day window; metric 2 denominator is all GB daily active users (those with at least one participation that day).
  • Consider performance: use efficient joins, avoid cross joins, and leverage date partitioning or indexing.
  • Validate results by checking edge cases such as dates with no calls, users with exactly 20 or 50 calls, and time zone consistency.

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