Every question on this page comes from a candidate's own account of a Meta interview. Aced members have written up 15 Meta interviews that involved SQL, 12 of them from interviews since January 2025, and have tagged questions in our question bank with the role and month they were asked. In November 2026 we also read more than 40 first-person reports posted since January 2025 on Glassdoor, Blind, 1point3acres, and LeetCode Discuss.
Each question says where the report came from and when. Table and column names are as the candidates remembered them, where they gave them. For questions 1, 2, 6, and 14 the candidates named the tables but not the columns, so those columns are ours or come from our question pages. Where a candidate gave no schema at all, we say so and supply one. The sample data and the answers are ours, and every query was run in PostgreSQL.
How Meta's SQL rounds work
Data engineer: a timed SQL and Python screen
The technical screen is one hour, split between SQL and Python. A Glassdoor review of an April 2026 interview gives the fullest breakdown: 5 minutes of introductions, 30 minutes of SQL, 30 minutes of Python, 5 minutes for questions, and the candidate chooses which half goes first. An Aced member who interviewed in November 2025 described the same 30 and 30 split and said 30 minutes goes quickly.
- Up to five questions per section, and three is the reported pass line. Two Glassdoor reviews from spring 2026 put it at five SQL and five Python questions with at least three solved in each. That would explain why other candidates, including three Aced members, describe the screen as 3 SQL and 3 Python questions.
- Your code runs against test cases. Two Glassdoor reviewers in 2026 said you cannot move to the next question until the current one returns the expected result. A LeetCode Discuss commenter who took the screen in 2025 described CoderPad with the test cases already written. The October 2026 1point3acres poster cited below said only the Python questions had test cases.
- The three-question line has exceptions. One Glassdoor reviewer finished five in each half and was rejected the next day. A Blind commenter in March 2025 said they advanced with fewer than three SQL questions solved.
- The schema is a library or a bookstore. An Aced member got a library schema in April 2026. A Glassdoor reviewer (May 2025 interview), a Blind commenter (December 2025), and a 1point3acres poster (October 2026) all describe a library or bookstore. The October 2026 poster believed the SQL questions had just been replaced, but a commenter replied that they had circulated since early 2025.
- The SQL is easy to medium, and time is short. Aced members described the SQL as easy to medium, and five of our Meta data engineer write-ups stressed speed or time pressure.
The onsite repeats one pattern across three rounds: design a data model for a product, write several SQL queries against your own model to compute its metrics, then do a Python task. A Glassdoor reviewer and an Aced member who both interviewed in April 2026 were given a ride-hailing product to model.
Data scientist: SQL attached to a product case
The technical screen is 45 minutes and usually pairs a product case with SQL, often on the same scenario. A 1point3acres poster in August 2025 spent about 35 minutes on the product discussion and had roughly 10 minutes for two SQL questions.
- You often define the metric before you write it. An Aced member (May 2025) described the SQL round as defining the metrics first and then coding them. The reported questions below ask for a prevalence and a "most used" app without saying how to measure either.
- The SQL may not run. A Blind poster in December 2025 described a non-executable SQL interview of three questions, where the interviewer asked for comments describing how the last query would be finished when time ran short.
- The onsite has a dedicated SQL round. Glassdoor reviews from 2026 list four onsite rounds: analytical reasoning, analytical execution, SQL, and behavioral. A September 2025 candidate got four SQL questions on one schema in that round, each followed by discussion.
- Known questions get reworded. A 1point3acres poster in November 2025 had memorized a circulated question set, met slightly different wording in the onsite, and could not finish.
- LeetCode medium is about the ceiling, according to an Aced member who interviewed in June 2025.
- One 2026 loop had an AI-assisted SQL round. A Glassdoor reviewer who interviewed in May 2026 listed an onsite round titled AI-Native DS Technical Skills and said it was a SQL question, mostly solved by an AI assistant.
An Aced member who interviewed for a data analyst role in June 2025 had a screen that combined SQL with product sense and a standalone SQL round in the onsite, with questions framed around engagement, ads, and product measurement.
Data engineer questions
Questions 1 and 2 use a library schema, and 3 to 5 use a bookstore. A Blind post from April 2025 lists SQL questions its author collected from Glassdoor reviews to prepare for this screen. Questions 4 and 5 are on that list, 18 months before the October 2026 report below.
1. Count each user's overdue library books
Reported to Aced: Meta data engineer technical screen, April 2026. The candidate had one hour on CoderPad for 3 SQL and 3 Python questions.
You have users, books, and checkouts (with checkout_date, due_date, and return_date). For each user, count the books they checked out and did not return before the due date. Return the username and the count.
SELECT
u.username,
COUNT(*) AS overdue_books
FROM checkouts c
JOIN users u ON u.user_id = c.user_id
WHERE c.return_date > c.due_date
OR (c.return_date IS NULL AND c.due_date < CURRENT_DATE)
GROUP BY u.username
ORDER BY overdue_books DESC;The wording hides two cases: books returned late, and books that are still out past their due date. A return_date > due_date filter alone drops the second group, because comparing NULL to anything is never true. Ask whether users with no overdue books should appear with a zero; if so, start from users with a LEFT JOIN and move the conditions into a CASE.
2. Count users who checked out geography books, by age
Reported to Aced: Meta data engineer technical screen, April 2026 (same screen as the question above).
Using the same library tables, find the number of users who checked out a book in the Geography category, grouped by age.
SELECT
u.age,
COUNT(DISTINCT u.user_id) AS users
FROM users u
JOIN checkouts c ON c.user_id = u.user_id
JOIN books b ON b.book_id = c.book_id
WHERE b.category = 'Geography'
GROUP BY u.age
ORDER BY u.age;The join produces one row per checkout, so a user who borrowed two geography books appears twice. COUNT(DISTINCT u.user_id) counts people; COUNT(*) would count checkouts.
3. Total sales for each member
Reported on 1point3acres: Meta data engineer phone screen, posted October 2026, login needed to read it. The first of three SQL questions.
The poster recalled four tables: books (book_id, author_id, title, category, price), authors (author_id, first_name, last_name, birthday, website_url), transactions (transaction_id, book_id, member_id, payment_amount, payment_type, tax, discount, quantity), and members (member_id, first_name, last_name, birthday, invited_by_member_id). Return the total sales value for each member.
SELECT
member_id,
SUM(payment_amount) AS total_sales
FROM transactions
GROUP BY member_id;The poster first joined transactions to members. The interviewer asked for a simpler version: everything needed is already in transactions, so no join is required. With four tables on screen, check which columns the output needs before joining.
A member with no transactions does not appear in this result. If the interviewer wants them listed with zero, start from members and LEFT JOIN.
4. Author statistics in one row
Reported on 1point3acres: Meta data engineer phone screen, October 2026 (same post). The second of three SQL questions.
On the same tables, return one row with three numbers: how many authors there are, the percentage whose website URL contains ".com", and the percentage who have never sold a book.
WITH author_sales AS (
SELECT DISTINCT b.author_id
FROM books b
JOIN transactions t ON t.book_id = b.book_id
)
SELECT
COUNT(*) AS unique_authors,
100.0 * SUM(CASE WHEN a.website_url LIKE '%.com%' THEN 1 ELSE 0 END) / COUNT(*) AS pct_dot_com,
100.0 * SUM(CASE WHEN s.author_id IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS pct_never_sold
FROM authors a
LEFT JOIN author_sales s ON s.author_id = a.author_id;An inner join from authors to sales drops the authors who never sold, which are the ones you need to count. Joining authors straight to transactions gives one row per sale, so every count is inflated; reducing sales to one row per author first keeps the outer query at one row per author. An author with a NULL URL fails the LIKE test. That is the intended result, and you should mention it.
Ask whether ".com" means anywhere in the URL or at the end of the domain. LIKE '%.com%' also matches "https://example.community.org".
5. Average payment per book for invited members
Reported on 1point3acres: Meta data engineer phone screen, October 2026 (same post). The poster remembered this one only roughly.
For members who were invited by another member, return the average payment per book.
SELECT
m.member_id,
SUM(t.payment_amount) * 1.0 / SUM(t.quantity) AS payment_per_book
FROM members m
JOIN transactions t ON t.member_id = m.member_id
WHERE m.invited_by_member_id IS NOT NULL
GROUP BY m.member_id;A transaction can cover several copies, so "per book" divides by SUM(quantity), not by the number of transactions.
The poster could not recall afterwards whether the join was on member_id or invited_by_member_id. Those are two different questions. This query reports on the invited members themselves. The version on the April 2025 Blind list groups by the inviter and asks what the people each member invited paid per book. If the wording does not settle it, ask before writing the join.
6. Top earner in each department
Reported to Aced: Meta data engineer technical round, spring 2026.
Given employees (id, first_name, last_name, salary, department_id) and departments (id, name), return the highest-paid employee in each department, ordered by department name.
SELECT department_name, employee_id, first_name, last_name, salary
FROM (
SELECT
d.name AS department_name,
e.id AS employee_id,
e.first_name,
e.last_name,
e.salary,
RANK() OVER (PARTITION BY d.id ORDER BY e.salary DESC) AS rnk
FROM employees e
JOIN departments d ON d.id = e.department_id
) ranked
WHERE rnk = 1
ORDER BY department_name;RANK returns both people when two tie for the top salary. ROW_NUMBER would pick one of them arbitrarily.
Data scientist questions
Most of these are rates. The SQL is short once you have decided what goes in the numerator and what goes in the denominator.
7. Overall click-through rate for the last week
Reported on 1point3acres: Meta data scientist technical screen, posted August 2025, login needed. The candidate had about 10 minutes for this and the next question.
Table ad_events has ad_id, date (stored as a string), event ('impression' or 'click'), and campaign_id. Table campaigns has campaign_id, advertiser_id, and campaign_type ('direct' or 'brand'). What is the click-through rate across all ads for the last week?
SELECT
SUM(CASE WHEN event = 'click' THEN 1 ELSE 0 END) * 1.0
/ NULLIF(SUM(CASE WHEN event = 'impression' THEN 1 ELSE 0 END), 0) AS ctr
FROM ad_events
WHERE CAST(date AS DATE) >= CURRENT_DATE - 7
AND CAST(date AS DATE) < CURRENT_DATE;Clicks and impressions live in one column, so count each with a CASE. NULLIF returns NULL in place of a divide-by-zero error if there were no impressions.
The date is a string, so cast it before comparing. "Last week" could mean the trailing seven days or the previous calendar week; this query uses the seven full days before today.
8. Click-through rate for brand and direct campaigns
Reported on 1point3acres: Meta data scientist technical screen, August 2025 (same post).
Using the same tables, compare the click-through rate of brand campaigns with that of direct campaigns.
SELECT
c.campaign_type,
SUM(CASE WHEN e.event = 'click' THEN 1 ELSE 0 END) * 1.0
/ NULLIF(SUM(CASE WHEN e.event = 'impression' THEN 1 ELSE 0 END), 0) AS ctr
FROM ad_events e
JOIN campaigns c ON c.campaign_id = e.campaign_id
GROUP BY c.campaign_type;This is the previous query with a join and a GROUP BY. Each event has one campaign, so the join does not duplicate events.
This version pools every event of a type, so a large campaign dominates its group. If the interviewer wants the typical campaign, compute the rate per campaign first and average those.
9. Most used app in the last 7 days
Reported on 1point3acres: Meta data scientist onsite SQL round, September 2025 (posted October 2025, login needed). The first of four questions on one schema.
For a VR headset, table user_activity has user_id, date, app_id, session_id, and duration. Table apps has app_id, app_name, and app_category. What is the most used app?
SELECT
a.app_name,
COUNT(DISTINCT ua.user_id) AS users,
COUNT(DISTINCT ua.session_id) AS sessions,
SUM(ua.duration) AS total_duration
FROM user_activity ua
JOIN apps a ON a.app_id = ua.app_id
WHERE ua.date >= CURRENT_DATE - 7
GROUP BY a.app_name
ORDER BY sessions DESC
LIMIT 1;"Most used" could mean the most users, the most sessions, or the most time. The candidate was expected to name them and discuss the trade-offs before picking one. The interviewer then set the window to the last seven days and did not ask for tie-breaking.
The query ranks by sessions and shows the other two measures next to it, so you can see whether they agree. On our sample data they do not: one app leads on sessions and another on time.
10. Share of total time spent in each app category
Reported on 1point3acres: Meta data scientist onsite SQL round, September 2025 (same post).
What percentage of total time spent goes to each app category?
SELECT
a.app_category,
ROUND(100.0 * SUM(ua.duration) / SUM(SUM(ua.duration)) OVER (), 1) AS pct_of_time
FROM user_activity ua
LEFT JOIN apps a ON a.app_id = ua.app_id
GROUP BY a.app_category
ORDER BY pct_of_time DESC;SUM(SUM(ua.duration)) OVER () is the grand total: the inner sum is per category and the window sum adds the categories up. A subquery for the total works just as well.
The follow-up asked how many rows come back if there are five categories. The answer is fewer than five if a category had no activity, and more than five if user_activity holds an app_id that is missing from apps, because the LEFT JOIN puts that time in a NULL category. Our sample data has one such row, and it shows up as its own line.
11. Are users of social apps more regularly engaged than users of game apps?
Reported on 1point3acres: Meta data scientist onsite SQL round, September 2025 (same post).
Test the hypothesis that people who use social apps are more regularly engaged than people who use game apps. The question defines neither the groups nor "engaged".
WITH user_mix AS (
SELECT
ua.user_id,
SUM(CASE WHEN a.app_category = 'social' THEN ua.duration ELSE 0 END) * 1.0 / SUM(ua.duration) AS social_share,
SUM(CASE WHEN a.app_category = 'game' THEN ua.duration ELSE 0 END) * 1.0 / SUM(ua.duration) AS game_share,
COUNT(DISTINCT ua.session_id) * 1.0 / COUNT(DISTINCT ua.date) AS sessions_per_active_day
FROM user_activity ua
JOIN apps a ON a.app_id = ua.app_id
GROUP BY ua.user_id
)
SELECT
CASE
WHEN social_share >= 0.8 THEN 'mostly social'
WHEN game_share >= 0.8 THEN 'mostly game'
ELSE 'mixed'
END AS user_group,
COUNT(*) AS users,
AVG(sessions_per_active_day) AS avg_sessions_per_active_day
FROM user_mix
GROUP BY 1;The candidate started with users who only use social apps and users who only use game apps. The interviewer pointed out that those pure groups would be tiny next to the group that uses both. The candidate suggested a threshold, such as 80% of a user's time in one category, and in the end compared three groups: social only, game only, and both. The query above uses the threshold.
The candidate measured engagement as average sessions per day. For "regularly" engaged, the number of distinct active days in a fixed window is closer to the wording.
12. How common are "unhealthy" users?
Reported on 1point3acres: Meta data scientist onsite SQL round, September 2025 (same post). The last of the four questions.
How common are unhealthy users? The candidate proposed a definition: more than 8 hours of use in a day, on more than 10 days in the past 30.
WITH daily AS (
SELECT user_id, date, SUM(duration) AS minutes
FROM user_activity
WHERE date >= CURRENT_DATE - 30
GROUP BY user_id, date
),
heavy_users AS (
SELECT user_id
FROM daily
WHERE minutes > 480
GROUP BY user_id
HAVING COUNT(*) > 10
)
SELECT
(SELECT COUNT(*) FROM heavy_users) * 1.0 / COUNT(DISTINCT user_id) AS share_unhealthy
FROM user_activity
WHERE date >= CURRENT_DATE - 30;Total each user's time per day, then count the days over the limit in a second step. Attempting both in one GROUP BY is the common mistake.
We assumed duration is in minutes; the post did not give the unit, so ask. The denominator here is users active in the last 30 days. Dividing by all registered users would give a smaller number, and you would need a users table for it.
13. Posts with 10 or more views, and the prevalence of spam
Reported on 1point3acres and Glassdoor: Meta data scientist phone screen, posted October 2026, login needed. A Glassdoor reviewer described a SQL screen about catching spam posts from an April 2026 interview. Neither gave a schema, so the tables here are ours.
Assume posts (post_id, author_id, created_date, is_spam) and post_views (post_id, viewer_id, view_date). Part 1: how many posts have 10 or more views? Part 2: what is the prevalence of spam, as a percentage?
SELECT COUNT(*) AS posts_with_10_views
FROM (
SELECT post_id
FROM post_views
GROUP BY post_id
HAVING COUNT(*) >= 10
) v;Part 1 is a count of groups, so it needs the grouped query wrapped in an outer count. Posts with no views at all never appear in post_views, which is fine for "10 or more".
SELECT
100.0 * SUM(CASE WHEN p.is_spam THEN 1 ELSE 0 END) / COUNT(*) AS pct_of_views_on_spam
FROM post_views v
JOIN posts p ON p.post_id = v.post_id;For Part 2, prevalence has two possible definitions. The share of posts that are spam and the share of views that land on spam are different numbers: on our sample data, one post in four is spam, but it takes a third of the views. Meta defines prevalence as the share of views that land on violating content, so that is the version above. In the reported interview, the case study that followed built on the same scenario.
14. Users who called three or more people in the last week
Reported to Aced: Meta data scientist interviews. Aced members tagged this question four times between August 2024 and May 2025.
Given a calls table (caller_id, recipient_id, call_time), find the number of users who called three or more different people in the last 7 days.
SELECT COUNT(*) AS users
FROM (
SELECT caller_id
FROM calls
WHERE call_time >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY caller_id
HAVING COUNT(DISTINCT recipient_id) >= 3
) frequent_callers;First find the callers who qualify, then count them. "Three or more people" means distinct recipients, not three calls. Ask whether "called" includes calls the user received, and whether "the last week" means the last 7 days or the last calendar week. Meta candidates in 2025 described SQL rounds framed around product metrics.
What to practice
- Rates with conditional aggregation. Five of the eight data scientist questions above come down to a ratio of two counts or sums. The grouping and conditional aggregation lesson covers the pattern.
- Joins that keep the right rows. Never-sold authors, unmatched app ids, and members with no transactions all depend on choosing between an inner and a left join. See joins and duplicate control.
- Speed on easy questions. For the data engineer screen, time yourself on five short questions on one schema in 25 to 30 minutes. The Meta questions in our question bank have a built-in SQL editor.
- Saying the definition first. For data scientist rounds, practice stating the metric in one sentence before you type. In question 11 above, the interviewer pushed back on the candidate's first definition.
For the wider set of questions reported across companies, see our SQL interview questions and answers. The SQL interview course has lessons and practice problems for each topic above.
Frequently asked questions
How many SQL questions do you need to solve in the Meta data engineer screen?
Candidates report up to five SQL and five Python questions in an hour, with three solved in each as the pass line. Meta does not publish this, and the reports disagree. One reviewer solved five of each and was rejected, and one Blind commenter advanced with fewer than three SQL questions.
Which SQL dialect does Meta use in interviews?
A Glassdoor reviewer who interviewed in March 2026, with an interviewer from the Messenger data engineering team, said the screen was in Python and PostgreSQL. For data scientist rounds the SQL may not run at all; a Blind poster in December 2025 described a non-executable SQL interview.
Is the SQL in Meta data scientist interviews hard?
The queries are short. An Aced member put the ceiling at LeetCode medium. Candidates have to decide what to measure when the question says "prevalence" or "most used" without a definition, and the SQL portion of a 45-minute screen can be as short as 10 minutes.
Do Meta interviewers reuse SQL questions?
Reports describe the same schemas repeatedly (a library or bookstore for data engineers, and ads and app activity for data scientists). Questions also stay in use for a long time. Two of the three SQL questions an October 2026 data engineer candidate reported are on a prep list posted to Blind in April 2025. The wording changes, though. A November 2025 data scientist candidate who had memorized a known set was thrown by reworded versions.
Learn everything you need to ace your data science interviews.
Aced is the fastest-growing tech interview prep platform. Get free interview guides, insider tips, and courses.
Create your free accountRelated Courses
Data Science Interview Prep Course
Python Coding Questions for Data Scientists
Related Blog Posts
Data Science Interview Prep (2026 Guide)
Top AI/ML Companies Hiring Now
What is a Data Scientist? Role And Career Insights
