Meta Data Scientist Interview Experience (2026) - SQL Rolling Window & Notifications Product Case, Pending

Neither was hard but the interviewer was strict about column names matching the schema exactly and about whether to use DISTINCT versus GROUP BY. I talked through both options for question one before committing.

Virtual Onsite (3 rounds)

The onsite for Meta DS Analytics is three 45-minute sessions: one SQL, one product case, one behavioral. The SWE-style coding round does not appear in the DS loop for this level.

Round 1: Technical Mutual Introduction and SQL

Problem: Extended version of the phone-screen schema, three SQL problems in increasing difficulty.

I will not restate all three. The pattern was: first one was a direct aggregation with a date filter, second one was a funnel calculation requiring self-join across two event types, third one was a rolling seven-day window function. The rolling window was the one that tripped me: I reached for a subquery with BETWEEN, but the cleaner solution is SUM(...) OVER (PARTITION BY user id ORDER BY ds ROWS BETWEEN 6 PRECEDING AND CURRENT ROW). The interviewer did not penalize me for the slower version but noted the cleaner one in passing.

Hash-table and prefix aggregation intuition transfers into Meta DS SQL rounds more than people admit. [[problem/586?company=2|Subarray Sum Equals K - Longest Subarray]] is a useful parallel because the prefix-sum trick maps directly onto the rolling window question. The simpler starter [[problem/54?company=2|Subarray Sum Equals K]] is also worth drilling if you are newer to the prefix-sum-plus-hashmap pattern.

Round 2: Product Case — Notifications Quality

Problem: Meta runs three types of notifications: time-critical (a friend went live), feedback (asking your opinion on something), and security (password change). How do you define the quality of a notification and what data do you need to measure it.

I framed the answer in three tiers. The top-level goal is engagement that is not regretted. Success metrics: DAU, MAU, time spent, and app return rate after opening the notification. Driver metrics: CTR, completion rate of the action implied by the notification, dwell time on the landing surface. Counter metrics: notification opt-out rate, uninstall rate, and the rate at which users mute the category. I made sure to call out that these tiers have different benchmarks for different notification categories. A security notification should have much higher open and action rates than a feedback notification because the message is urgent and consequential.

Follow-up: how do you decide whether a 35% CTR is a good number. My answer: CTR alone means nothing without a benchmark, and the benchmark depends on the category. A security notification at 35% CTR is poor. A feedback notification at 35% is excellent. The right comparison is against the historical baseline for that category, holding the user cohort constant, and ideally through an A/B test rather than a pre-post comparison.

The interviewer pushed on what I would do if the A/B test showed a CTR improvement but an opt-out rate increase. I talked about a constrained optimization framing where opt-out is a guardrail and CTR improvements that cross the guardrail threshold get rolled back. Meta runs their experimentation platform with exactly that kind of guardrail system, which I think scored points.

Round 3: Behavioral

No surprises. Tell me about a time a project failed. Tell me about a time you disagreed with a partner team. How do you prioritize across competing asks from multiple PMs. Meta values "move fast" and "focus on long-term impact" in the interview rubric, so I framed stories around measurable business impact and speed of iteration. No coding this round.

Result

Onsite just wrapped and I have not heard back. I will update the post if the decision comes through. For now the signal I have is that the SQL rounds were the strongest and the product case was the one where I had to fight hardest to keep the framing tight.

Tips

1. Meta DS is SQL-first, not Python-first. The scraped forum chatter about DS coding often mixes in MLE-style questions. For analytics tracks at Meta specifically, SQL is the core technical skill and Python is rarely asked.
2. Memorize the window-function syntax for rolling aggregates. The seven-day active user question came up in both my phone screen and my onsite in different forms. A subquery with BETWEEN is acceptable; SUM over a windowed frame is better.
3. Product cases at Meta follow the tiered-metric framework. Success metric, driver metric, counter metric. Say those words out loud during the case and you signal fluency immediately.
4. Always bring up guardrails when talking about A/B tests. Meta's experimentation culture is built around them, and interviewers recognize the concept instantly.
5. Benchmark by segment, not globally. Any question of the form "is X a good number" has the implicit answer "compared to what." Saying that explicitly is the move.
6. Practice the schema-referenced SQL style. Meta's SQL interviews hand you a schema at the start and expect literal column names. Vague pseudocode SQL will not cut it.