Home › Blog › FAANG SQL Interview Guide

The Complete FAANG SQL Interview Guide (2026)

SQL interviews at Meta, Google, Amazon, Apple, and Netflix follow recognisable patterns. This guide covers every topic you need, what each company favours, and a 30-day plan to go from rusty to ready.

1. How SQL is tested at FAANG

SQL interviews at large tech companies take one of three forms:

Online assessment (OA)

A timed take-home screen — 60–90 minutes with 2–4 SQL problems. Common at Amazon for data analyst and business analyst roles. Speed and accuracy both matter. There is no partial credit.

Live technical screen

A 45–60 minute call where you write SQL in a shared editor (CoderPad, HackerRank) while thinking aloud. Common at Meta and Google. The interviewer cares as much about your reasoning as your final answer.

Onsite SQL round

One or two dedicated SQL sessions during a full-day onsite. Questions are harder — you may be asked to optimise a query, propose an index, or explain a query plan. Common for senior data engineer and data scientist roles.

2. The 6 core SQL topics

Across all FAANG companies, six topics account for the vast majority of interview questions.

1. Window functions

The single most-tested advanced SQL concept — appearing in roughly 70% of hard interview questions.

• ROW_NUMBER(), RANK(), DENSE_RANK() — ranking within groups
• LAG(col, n), LEAD(col, n) — comparing to previous/future rows
• SUM() OVER, AVG() OVER — running totals and moving averages
• PARTITION BY — defining the group each function operates within
• Frame clauses: ROWS BETWEEN ... AND ...

2. JOINs

You need to be completely fluent with all join types. Interviewers use joins to test whether you understand the data model, not just the syntax.

• INNER JOIN — rows that match in both tables
• LEFT JOIN — all rows from left, NULLs where right doesn't match
• FULL OUTER JOIN — all rows from both tables
• SELF JOIN — joining a table to itself (friend graphs, hierarchies)
• Anti-join — LEFT JOIN ... WHERE right.id IS NULL

3. Aggregation and GROUP BY

• COUNT(*) vs COUNT(col) — the NULL difference matters
• COUNT(DISTINCT col) — for unique user counts
• SUM(CASE WHEN ... THEN 1 ELSE 0 END) — conditional counts
• HAVING vs WHERE — filtering after vs before aggregation

4. Common Table Expressions (CTEs)

CTEs make complex queries readable and maintainable. At FAANG, writing a deeply nested subquery is a red flag — experienced candidates use CTEs to break problems into logical steps.

WITH
monthly_active AS (
    SELECT user_id, DATE_TRUNC('month', event_date) AS month
    FROM events
    GROUP BY 1, 2
),
user_months AS (
    SELECT user_id, COUNT(DISTINCT month) AS active_months
    FROM monthly_active
    GROUP BY 1
)
SELECT active_months, COUNT(*) AS user_count
FROM user_months
GROUP BY 1 ORDER BY 1;

5. Subqueries

• Correlated subquery — references a column from the outer query
• Scalar subquery — returns exactly one value
• EXISTS / NOT EXISTS — efficient for existence checks
• IN / NOT IN — watch NULL behaviour with NOT IN

6. Date and time manipulation

• DATE_TRUNC('month', date) — truncate to time boundaries
• DATEDIFF(end, start) — days between two dates
• DATE_ADD(date, INTERVAL n DAY) — add time intervals
• EXTRACT(YEAR FROM date) — pull out year, month, day, hour

3. SQL patterns by company

4. 30-day study plan

Assuming 1–2 hours per day.

5. Interview day tips

Start with clarifying questions

Before writing anything, ask: Do we count NULL values? Should ties use RANK or DENSE_RANK? Is this PostgreSQL or BigQuery? These questions signal experience and prevent you from building the wrong solution.

Break the problem into steps, then combine

Never try to write a complex query in one pass. Narrate: "First I'll get the monthly aggregates, then join to find users who appear in consecutive months." Write each step as a CTE, then combine them.

Test with edge cases before declaring done

After writing your query, mention edge cases: "What if a user has no orders? This LEFT JOIN handles that — they'd appear with NULL on the right side."

Clean syntax signals experience

Use consistent indentation, uppercase keywords, and meaningful aliases. e.name, d.dept_name is clearer than a.name, b.name. Small things matter in live interviews.