Meta Data Scientist Virtual Onsite Interview Experience (2025) - Offer

The first 15 minutes were light. My interviewer was a senior DS on the notifications team and she walked through her path to Meta, then asked me to do the same. She laid out the day's structure and made sure I understood the four-round format: product case, SQL, experimentation stats, and behavioral. Nothing to evaluate here except communication polish, but do not underestimate how much setting a confident, friendly tone early helps the later rounds.

Round 2: SQL - User Calls and Retention

Problem: Given a calls table with caller id , recipient id , ds , call id , and duration , plus a users table with user id , age bucket , country , primary os , dau flag , and ds , answer two questions. First, how many users have started a call with more than three distinct people in the last seven days. Second, what percentage of daily active users from France were on a video call yesterday.

For the first question I grouped the calls table by caller id over the seven-day window, counted distinct recipient id values, filtered where the distinct count exceeded three, then counted the resulting users. The trick is to be precise about what "last seven days" means relative to the current ds , and to make sure you are counting distinct callers at the outer query, not the raw rows. My interviewer pushed on what would change if a single call had multiple recipients in a group call (it would require a separate call participants table), which was a good signal that she wanted me to think about the schema and not just the syntax.

The second question needed a join between users and calls on user id = caller id , filtered to country = 'fr' and dau flag = 1 and the previous ds . The numerator was the count of distinct users who had any call yesterday, and the denominator was the count of DAUs from France. I wrote it as a single query with conditional aggregation, which she preferred over two separate CTEs. Takeaway: at Meta, "clean SQL" means fewer subqueries, more window functions and conditional aggregation.

is coding not SQL, but it is a reminder that Meta interviewers like the "stream through the data once and track state" pattern, which maps to window functions in SQL.

Round 3: Product Case - Notification Quality

Problem: Meta ships three broad categories of notifications. Time-critical ones (a friend just went live), feedback ones (asking for your opinion on content), and security ones (password change alerts). How would you define notification quality, what data would you need, and how would you evaluate whether a 35 percent click-through rate is actually good?

I opened by restating the goal in my own words: notification quality means the notification is worth the interruption it causes. That framing let me split the metric discussion into three layers. The top layer was the north-star metric, which for me was session engagement lift attributable to the notification, measured against a holdout. The middle layer was driver metrics, which I listed as CTR, post-click action completion (did they actually open the live stream or just tap and bounce), and time-to-open. The bottom layer was counter metrics, which included opt-out rate, notification-triggered uninstalls, and "mute this kind of notification" taps.

When she asked about the 35 percent CTR, I immediately said that a single benchmark across all three categories is meaningless. Security notifications should have near 100 percent open rate because they are transactional; if only 35 percent of users open a password-change alert, that is a red flag, not a success. Time-critical notifications should clock in high as well because they are built around scarcity. Feedback notifications are the one place where 35 percent CTR might genuinely be strong, and even there I would want to see the distribution by notification age, because feedback requests decay fast.

She kept pushing on experimentation. How would I actually A/B test a notification redesign. I walked through picking a randomization unit (user, not device, because a user with two devices would contaminate the treatment), picking a primary metric (post-click completion rate on feedback notifications), and then sizing the experiment. For sizing I walked through how I would estimate the minimum detectable effect, pick alpha and power (0.05 and 0.8 as defaults), estimate the baseline variance from the last two weeks of data, and compute the sample size needed per arm. The thing she wanted to hear, which I almost forgot to say, was that I would pre-register the analysis plan to avoid p-hacking on secondary metrics.

is unrelated to product work, but the product-case round is really about structured decomposition, the same muscle you use to peel layers off a string problem.

Round 4: Experimentation and Stats - Ranking Experiment

Problem: The Reels ranking team wants to ship a new ranker. They want you to design the experiment and tell them when they can declare a winner.

This was a 45-minute deep-dive. I set up the experiment with users as the unit, a 50/50 split, and Reels watch-time per DAU as the primary metric. The interviewer asked how I would detect novelty effects, which I explained as running the test at least two full weeks to let the initial engagement spike settle. She asked what I would do if on day three the new ranker looked 2 percent worse with a p-value of 0.01. I said I would not stop the test yet because early stopping inflates the false positive rate unless you apply a sequential testing correction like the O'Brien-Fleming spending function. She liked that answer and pushed further on what I would do if after two weeks the treatment was flat but the ratio of long-session users (watch time over 20 minutes per day) went up by 5 percent. I said I would be suspicious, because flat overall watch time with a shift in the tail often means the ranker is cannibalizing casual users while deepening engagement for power users, which is a negative trade for DAU growth.

We closed with a quick discussion about Bonferroni correction when she asked what I would do if I had five guardrail metrics and wanted to know if any of them had regressed. I gave the textbook answer (divide alpha by the number of comparisons) and then added that in practice Meta often uses a more targeted approach where you designate one primary guardrail and keep the others as directional checks, to avoid losing statistical power.

Round 5: Behavioral

The last round was a senior DS manager running standard behavioral probes. Tell me about a time you shipped something that did not move the metric you expected. Tell me about a time you pushed back on a PM. Tell me about the project you are most proud of. I had three stories ready and rotated them, making sure each one had a concrete metric in the punchline. The one she dug into was my "pushed back on a PM" story, where I had talked a PM out of launching a personalization feature because the pre-launch analysis showed the feature would help 10 percent of users but hurt retention for the other 90. She asked how the PM reacted, whether I had brought the data or the recommendation first, and what I would do differently. The good answer is always "lead with the data, let the recommendation follow, and keep the door open for a scoped relaunch."

Result

Offer came six days after the onsite. The numbers were strong and the team was a good match for what I wanted to work on next. I accepted within a week.

Tips

1. Treat the product case as the most important round. Meta DS candidates who are weak in SQL but strong in product thinking sometimes squeak through. The reverse almost never works. Drill two product cases a week from the day you start prepping.
2. Pre-register your experiment analysis plan out loud. Interviewers are listening for whether you know about p-hacking, multiple comparisons, and sequential testing. Naming these concepts unprompted signals seniority.
3. Count distinct, not rows. Most Meta SQL mistakes come from forgetting that a user can appear multiple times in a calls or events table. Start every query by asking yourself whether the grain of the base table matches the grain you want.
4. Know when flat-top, heavy-tail results are bad news. A ranker that keeps power users engaged but loses casuals is not a win at Meta scale. If you can articulate this unprompted, it lands well.
5. Behavioral answers need a number. Meta is a metric-driven culture. Every story should have a punchline that mentions a delta, a percentage, or a dollar figure. "We shipped it and users liked it" is a failing answer.
6. Do not over-explain in SQL. Write the query, narrate briefly, and stop. Interviewers docking you for chattiness is a real thing, and SQL is the round where it shows up most.