← Meta Interview Insights

Meta·Data Scientist·Technical Phone Screen·Senior

Senior
Jun 2026

Summary

SQL-heavy Data Scientist screen at Meta, three questions all built around the same four-table bookstore schema. The problems escalated pretty quickly from aggregation basics to some genuinely tricky referral chain logic.

Questions Asked (3)

Q1

Using a four-table bookstore schema (books, authors, transactions, customers), write a query to return the top 5 payment methods ranked by total sales amount.

Product Analytics & MetricsData Modeling
Author's notes

Straightforward aggregation, sum the amount column from transactions, group by pay_method, order descending, limit 5.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the schema and the definition of 'total sales amount' (e.g., sum of transaction amounts). Then write a SQL query that joins the transactions table with the payment methods (likely a column in transactions), groups by payment method, sums the sales, orders descending, and limits to 5. Consider any necessary filters (e.g., completed transactions) and handle potential NULLs.

Pro tip: Mention that you would validate the results by checking for data quality issues (e.g., negative amounts, refunds) and consider if payment methods need to be normalized or if there are multiple payment methods per transaction. Also, discuss how you might handle ties in ranking.

1. Clarify the schema and requirements

Ask questions to confirm the table structures, especially which table contains payment method and sales amount. Clarify if 'total sales amount' means sum of transaction amounts or quantity sold, and if there are any filters (e.g., only completed transactions).

2. Identify the necessary tables and joins

Determine that the transactions table likely contains payment_method and amount. If payment method is in another table, identify the join key. Usually, only the transactions table is needed, but if payment method is in a separate table, join accordingly.

3. Write the aggregation query

Use GROUP BY on payment_method, SUM(amount) as total_sales, ORDER BY total_sales DESC, and LIMIT 5. Ensure proper handling of NULLs and consider using COALESCE if needed.

4. Consider edge cases and validation

Discuss potential data issues: refunds (negative amounts), multiple currencies, or payment methods with no sales. Also, consider if ties should be handled (e.g., using RANK() window function).

5. Present and explain the query

Walk through the query step by step, explaining each clause and why it's necessary. Mention any assumptions made and how you would test the query.

Key Points to Mention

  • Use of GROUP BY and SUM aggregation
  • Ordering by total sales descending and limiting to top 5
  • Handling of NULL values in payment method or amount
  • Consideration of refunds or negative amounts
  • Potential need for window functions if ties exist
  • Validation of results and data quality checks

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

Q2

Calculate two proportions: (a) what fraction of authors have zero sales, and (b) what fraction of authors have a personal URL containing a specific keyword string.

Product Analytics & MetricsData Modeling
Author's notes

Part (b) was easy, just a LIKE filter with COUNT.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the data schema and definitions (e.g., what constitutes an author, zero sales, and a personal URL) before writing any queries. Then use SQL to compute each proportion separately, ensuring you handle NULLs and edge cases appropriately. Finally, validate results with sanity checks and consider segmenting by relevant dimensions.

Pro tip: Always state your assumptions explicitly and confirm them with the interviewer—this shows you think like a data scientist who cares about data quality and business context. Also, mention that you would check for data completeness and potential biases in the dataset.

1. Clarify Definitions and Assumptions

Ask clarifying questions to define 'author', 'zero sales', 'personal URL', and the specific keyword. Confirm the time frame and whether sales include all formats.

2. Explore Data Schema

Identify relevant tables (e.g., authors, sales, profiles) and columns. Check for NULLs, duplicates, and data types.

3. Compute Proportions

Write SQL queries: (a) count authors with zero sales divided by total authors; (b) count authors with personal URL containing keyword divided by total authors. Use LEFT JOINs and careful filtering.

4. Validate and Sanity Check

Verify results by checking totals, sampling records, and ensuring no double-counting. Consider if proportions make sense given domain knowledge.

5. Present and Interpret

Report the proportions clearly, mention any caveats, and suggest potential next steps or segmentations if relevant.

Key Points to Mention

  • Handling NULLs and missing data in sales and URL fields
  • Defining 'zero sales'—does it mean no sales records or sales amount = 0?
  • Case sensitivity and pattern matching for the keyword in URLs (e.g., LIKE vs. regex)
  • Using DISTINCT author IDs to avoid duplicates
  • Considering time windows for sales (e.g., all-time vs. last year)
  • Potential data quality issues like authors with multiple profiles

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

Q3

Using the customers table where some customers have a referring customer ID, find the 5 referrers whose referred customers bought books at the highest average price. Exclude customers who weren't referred by anyone.

Data ModelingAlgorithms & Data Structures
Author's notes

This one took me a minute to untangle.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the schema and assumptions (e.g., how referring_customer_id links to customer_id, and that book purchases are in a separate table with price). Then, write a SQL query that joins customers to purchases, groups by referrer, computes the average price of books bought by referred customers, and orders descending to get the top 5.

Pro tip: Mention that you would handle ties carefully—if multiple referrers have the same average price, you might need to decide whether to include all or use a tiebreaker. Also, explicitly exclude rows where referring_customer_id is NULL to avoid counting non-referred customers.

1. Clarify schema and assumptions

Confirm the table structures: customers table has customer_id and referring_customer_id; purchases table has customer_id, book_id, and price. Assume each purchase is a book bought by that customer.

2. Identify referred customers

Filter customers where referring_customer_id IS NOT NULL to focus only on customers who were referred by someone.

3. Join with purchases and aggregate

Join the referred customers to the purchases table on customer_id, then group by the referrer (referring_customer_id) and compute AVG(price) for each referrer.

4. Rank and select top 5

Order the grouped results by average price descending and limit to 5 referrers. Consider using a window function like RANK() or DENSE_RANK() if ties are a concern.

5. Validate and discuss edge cases

Check for referrers with no purchases (should be excluded), handle NULLs, and discuss how ties or missing data might affect the result.

Key Points to Mention

  • Self-join or join between customers and purchases to link referrers to their referred customers' purchases.
  • Use of AVG() aggregate function and GROUP BY on the referrer ID.
  • Filtering with WHERE referring_customer_id IS NOT NULL to exclude non-referred customers.
  • Ordering by average price DESC and LIMIT 5 (or using window functions for ties).
  • Consideration of data quality: duplicate purchases, missing prices, or customers with no purchases.
  • Potential need for indexing on referring_customer_id and customer_id for performance.

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