← Meta Interview Insights

Meta·Data Scientist·Technical Phone Screen·Intermediate

Intermediate
May 2026

Summary

SQL-heavy technical screen for a Data Scientist role at Meta, focused on messaging platform analytics. Two questions, both involving joins and aggregations on user behavior data. Nothing too wild but the spammer read-rate one had a subtle denominator definition that I almost got wrong.

Questions Asked (2)

Q1

Given a messages table with sent and read dates, how would you find the number of users who received more than 10 messages in a single day during the past 7 days?

Product Analytics & MetricsData Modeling
Author's notes

Pretty standard aggregation question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the schema and definitions (e.g., what 'received' means, how to handle multiple messages per day), then write a SQL query that filters messages from the past 7 days, groups by user and date, counts messages, and finally counts distinct users with more than 10 messages on any day. Walk through the logic step by step, considering edge cases like time zones and date boundaries.

Pro tip: Mention that you would validate the query with a small sample or by checking edge cases (e.g., users with exactly 10 messages) to ensure correctness, and discuss how the metric might be used to inform product decisions.

1. Clarify requirements and schema

Ask clarifying questions about the table structure (e.g., columns for user_id, message_id, sent_date, read_date) and define what 'received' means (e.g., sent_date or read_date). Confirm the time window (past 7 days from today) and whether to consider calendar days or rolling 24-hour periods.

2. Filter messages for the past 7 days

Write a subquery or CTE to select only messages where the relevant date (e.g., sent_date) falls within the last 7 days. Use appropriate date functions (e.g., DATE_SUB(CURRENT_DATE, INTERVAL 7 DAY)) and consider time zone adjustments if necessary.

3. Aggregate messages per user per day

Group the filtered messages by user_id and date (truncated to day) and count the number of messages. This yields a table with columns: user_id, date, message_count.

4. Identify users with >10 messages on any day

From the aggregated table, filter for rows where message_count > 10. Then count the distinct user_ids that appear in this filtered set.

5. Write final SQL and discuss edge cases

Combine the steps into a single SQL query (using CTEs for readability). Discuss potential edge cases: users with multiple messages on the same day but different timestamps, handling of NULLs, and whether to include users with exactly 10 messages (no, since 'more than 10').

Key Points to Mention

  • Definition of 'received': typically based on sent_date, but could be read_date if the question implies read messages.
  • Time window: past 7 days from current date, using date functions and considering inclusive/exclusive boundaries.
  • Grouping by user and day: use DATE(sent_date) to truncate timestamps to day level.
  • Counting distinct users: use COUNT(DISTINCT user_id) after filtering for >10 messages per day.
  • Edge cases: time zones, users with exactly 10 messages, and messages sent on the boundary of the 7-day window.
  • Performance considerations: indexing on date and user_id, and using CTEs for clarity.

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

Q2

Using the messages and violating_scores tables, calculate the average read-rate for spammers over the last week, where read-rate is the number of messages sent by spammers that were read divided by all messages sent by spammers.

Product Analytics & MetricsData Modeling
Author's notes

This is where I almost tripped.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the definitions of 'spammer', 'read', and 'last week' to ensure alignment with the interviewer. Then, outline the SQL query structure: filter messages from spammers in the last week, compute read-rate per spammer, and average those rates. Finally, discuss potential edge cases and validation.

Pro tip: When defining 'spammer', consider using a threshold on the violating_scores table (e.g., score > 0.8) and mention that you would confirm this with the interviewer. Also, specify that you would use a LEFT JOIN to include messages with no read events, treating them as unread.

1. Clarify definitions and assumptions

Define 'spammer' (e.g., users with violating_score above a threshold), 'read' (e.g., read_at is not null), and 'last week' (e.g., last 7 days from today). Confirm these with the interviewer.

2. Identify spammers and their messages

Use the violating_scores table to select spammer user IDs, then filter the messages table to include only messages sent by these users in the last week.

3. Compute read-rate per spammer

For each spammer, calculate the number of read messages divided by total messages sent. Use a LEFT JOIN to messages_read or check read_at to count reads.

4. Calculate average read-rate

Average the per-spammer read-rates to get the overall average read-rate for spammers. Be clear whether to weight by message volume or not.

5. Validate and discuss edge cases

Consider spammers with zero messages, messages with multiple read events, and time zone issues. Suggest sanity checks like comparing to overall read-rate.

Key Points to Mention

  • Definition of spammer: likely based on violating_scores threshold, but confirm with interviewer.
  • Time window: last week could mean last 7 days or previous calendar week; clarify.
  • Read-rate calculation: per-spammer read-rate then average, vs. overall read-rate (weighted average).
  • Handling of messages with no read events: treat as unread (0 reads).
  • Use of LEFT JOIN to ensure all messages are counted, even if not read.
  • Edge cases: spammers with no messages, duplicate read events, and time zone considerations.

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