← Back to Directory

Meta interview notes, page 1 of 238

FAANG / Big Tech

Most of these Meta write-ups come from Software Engineers (1,194), then Data Scientists (489) and Product Managers (453). The most reported rounds are the technical phone screen (1,190), the product sense round (466), the system design round (255) and the behavioral / leadership round (205).

2377 interview notes · updated Jul 2026

Meta·Data Scientist·Technical Phone Screen

Feb 2023
Meta DS interview with a heavy SQL focus, three questions all built around the same Calls and Users schema. The cycle detection one was genuinely tricky and I don't think I nailed it.
  • Write a SQL query that returns the number of distinct users who initiated calls to more than three unique recipients in the past seven days.
  • Calculate the percentage of yesterday's daily active users from France who participated in at least one video call.
  • Using only the Calls table, write SQL to detect three-person call cycles where A called B, B called C, and C called A.

“Pretty standard GROUP BY/HAVING setup.”

View Post

Meta·Data Scientist·Technical Phone Screen

Apr 2023
Meta Data Scientist technical screen focused entirely on a SQL problem around a messaging platform. Four related sub-questions built on each other, which felt manageable until the A/B testing piece at the end where I had to think on my feet about what 'active' even means.
  • Given a messages table with sender, receiver, reaction flag, and timestamp, write SQL to count the number of unique conversation threads that had at least one message in a given week. A thread is an unordered sender-receiver pair.
  • Extend the previous query to count how many of those weekly threads contain at least one message where has_reaction = 1.
  • For threads that eventually receive at least one reaction, compute the average time in minutes from the first message in the thread to the first reacted message.
  • How would you use the presence or absence of reactions on messages to define an 'active' thread for an A/B test?

“The unordered pair thing tripped me up for a second.”

View Post

Meta·Data Scientist·Technical Phone Screen

May 2023
Meta data scientist interview with a SQL-heavy technical screen. The question was practical, commerce-flavored, and felt like something you'd actually write on the job.
  • Given a table of shop view events with user IDs, shop IDs, and timestamps, write a SQL query that returns the number of unique users who viewed each shop for each calendar day over the past 7 days.

“Pretty applied question, not a brain teaser.”

View Post

Meta·Data Scientist·Technical Phone Screen

Jun 2023
Meta DS interview with a pretty gnarly SQL plus streaming Python question built around a newsfeed impression log. The scenario was realistic enough that it felt less like a leetcode grind and more like something you'd actually debug at work, which I appreciated but also found stressful.
  • Given a table of post impression events with watch duration and screen coverage columns, write a SQL query that returns every post whose total watch duration across all views exceeds some threshold X and whose maximum screen coverage across those views exceeds threshold Y.
  • Using the same event data consumed as a stream, write Python code that groups events into sessions (where a session ends if no new event arrives within 30 seconds), then emits for each completed session the posts that meet the same effective-read criteria along with their total watch time and max screen coverage.

“The GROUP BY part was fine, I got that out fast.”

View Post

Meta·Data Scientist·Technical Phone Screen

Jun 2023
SQL-heavy data science screen at Meta built around an e-commerce shop visibility dataset. The questions escalated fast from basic GROUP BY stuff to window functions and metric design, which I did not fully anticipate going in.
  • Write a SQL query that returns total visible days per shop, ordered from highest to lowest, using GROUP BY, HAVING, and ORDER BY.
  • Extend the previous query to JOIN in a shop category table and use CASE logic to bucket shops into visibility tiers.
  • Using window functions, rank shops by their average daily visibility within each category.
  • Define a metric to compare activity rates between new and older users by bucketing them into tenure groups based on their signup date, then implement it in SQL using today's snapshot.

“Straightforward enough that I almost overthought it.”

View Post

Meta·Data Scientist·Technical Phone Screen

Jul 2023
Meta data scientist interview with a SQL and product analytics question centered on ad performance. The setup was two tables, impressions and clicks/conversions, and you had to design a KPI and write the query yourself rather than just answer a predefined one. Pretty open-ended for a technical screen.
  • Given two tables tracking ad impressions and clicks/conversions, propose a single metric that captures both click-through rate and conversion quality, then write a SQL query that joins the tables and returns the metric broken down by ad_id for the last 7 days.

“The open-ended part tripped me up more than the SQL itself.”

View Post

Meta·Data Scientist·Technical Phone Screen

Jul 2023
Meta data scientist interview with a meaty SQL and metrics design question around cross-app session data. The scenario felt very on-brand for Meta given their multi-app ecosystem, which was either helpful context or a pressure multiplier depending on how you look at it.
  • Given a table of user session logs across multiple apps, calculate the average session length per app for a given day, then propose and justify a metric for comparing daily app performance, and finally compute a 'bounce rate' defined as users who switch to a different app and then return to the original app within the same day.

“Three parts crammed into one question, which I did not fully clock until I was already halfway through the first part.”

View Post

Meta·Data Scientist·Technical Phone Screen

Jul 2023
Meta DS interview with a SQL-heavy visibility metrics question. The setup was straightforward but the real test was whether you'd define your metric before writing a single line of code.
  • Given a shop events table with view and purchase events, write SQL to compute each shop's daily visibility rate, defined as total views divided by unique visiting users.
  • Before writing any code, propose a clear definition for a shop visibility metric and confirm it with the interviewer.

“I jumped straight into writing the query and skipped defining what 'visibility rate' actually meant.”

View Post

Meta·Data Scientist·Technical Phone Screen

Jul 2023
Meta DS interview with a SQL question that sounds straightforward until you actually have to define what you're measuring. The open-ended metric design part is where it gets interesting.
  • Given a table of historical shop visibility actions, write a SQL query that computes a metric comparing how likely older users versus newer users are to set their shop profile to invisible. Justify your metric choice.

“The SQL itself isn't the hard part.”

View Post

Meta·Data Scientist·Technical Phone Screen

Jul 2023
Meta Data Scientist interview with a meaty SQL and stats question built around three ad performance tables. The whole thing was one big multi-part problem and it went deeper than I expected.
  • Given three tables (ads, ads_impressions, ads_conversions), write a query to compute the overall click-through rate per ad for the last 7 days, then return the top 3 advertisers ranked by conversion rate in that same period.
  • For each hour of the day, compare CTR during peak hours (18:00 to 22:00) versus non-peak hours, and output the p-value for a difference-in-proportions test.
  • What additional data or tests would you suggest to confirm the hypothesis that ads shown during peak hours perform better than those shown at non-peak hours?

“The joins themselves weren't the hard part.”

View Post