Is the Big Tech SQL Round Just a Syntax Quiz in 2026?

No. As of 2026-11-02, TrueInterview's bank holds 222 candidate-reported SQL questions from 25 big-tech companies, reported in phone screens 132 times and onsites 61 times against 33 online-assessment reports. Example 2026 titles in the bank point to grain and window reasoning on product data: login streaks, top-N per group, monthly growth, tree classification and SQL mixed with Python. Our take: treat the SQL round as a live conversation in which you frame the data, write window-function and CTE logic, and defend it on ties, duplicates and date boundaries. Memorised syntax covers none of those steps.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

What does the bank show about SQL rounds right now?

The reports are concentrated by company, which makes the target smaller than a generic SQL list suggests. Meta has 62 SQL questions in the bank, Amazon 24, DoorDash 22, ByteDance 22 and Pinterest 15, with Airbnb, Google, Stripe, Netflix and LinkedIn each below ten. Of these questions, 91 were last reported within the 12 months before 2026-11-02.

So most of the bank is older than a year, and the recent slice is the part to start with. If your loop is at one of those five companies, take that company's questions last reported in the past year first, because they are the closest thing to a current sample of what its candidates meet. If your loop is elsewhere, the shapes in the table further down still transfer: they are patterns, not company secrets.

Read the ranking with care. These counts are what candidates reported, not how often a company asks SQL. A company whose candidates write up more loops shows more questions, so the ranking tells you where the evidence is thick, not where the SQL is hardest.

Is SQL mostly an online-assessment filter?

No. The phone screen is the most reported SQL round in the bank, the onsite is second, and the online assessment is a distant third; a single question can carry reports from more than one round. Most SQL rounds therefore put you in front of a person who watches you reason, and that changes what you should practise.

StrataScratch's scenario guide describes the format the same way: "timed, live-coded, and closer to pair programming than a take-home worksheet". That is the guide's characterisation, not measured data, but our round counts point in the same direction. The same guide lists problem framing as a tested skill: "Can you restate the question in data terms (filters, grain, joins, output shape) before you write code?"

Our take: practise SQL out loud. Before typing, say what one output row means, which filters apply, which joins you need and what grain each table sits at. Then write the query, and then say why it is correct and what you would change if the interviewer added a constraint. If you write a correct query in silence, the interviewer has no evidence that you chose the grain and the join type on purpose.

The belief still holds for one group. ByteDance's Longest Consecutive Login Days per User and Pinterest's Top Two Categories by Engagement Rate per Country are both filed with OA reports, so an OA-only process can still include a streak or a top-N-per-group question. Our data does not break the OA reports down by pattern, but these two examples are reason enough to prepare both patterns even if you never expect a live SQL round.

Is a query that returns the right shape a finished answer?

No. A query can run, return the expected columns and still be wrong on duplicates, ties or date windows, and the interviewer is grading that difference. StrataScratch's guide says "You're expected to explain why your approach is correct, how it scales, and what you'd do differently if constraints changed". The traps the guide names are specific enough to turn into a checklist.

StrataScratch's guide says scenario prompts come with "duplicates, missing events, inconsistent timestamps" and rows that should be impossible but exist. In a question where a record must satisfy both of two conditions, the guide's trap is reading it as an OR and writing a single IN filter, which answers a different question. In latest-versus-baseline questions, the guide names including the latest row in the historical average as a common error. In time-window questions, the guide's trap is an off-by-one on inclusive dates or a filter that drops valid users. On duplicates, the guide is blunt: "DISTINCT is a band-aid; interviewers usually want the root cause fixed." The guide also says interviewers test whether you trust the data model rather than a shortcut that silently gives wrong answers on real data.

Our take: run a four-point check aloud before you say you are done.

1. Did you read AND as AND? A prompt that needs both conditions usually needs GROUP BY with HAVING on conditional counts, or an INTERSECT, rather than one IN list.
2. Is the baseline clean? When you compare the latest value with a historical average, exclude the latest row from the average.
3. Are the date boundaries what the prompt said? State whether the window is inclusive and test the edge day.
4. Is the grain right? If duplicates appear, find the join that multiplied rows and fix it instead of wrapping the output in DISTINCT.

What do the reported SQL titles actually test?

Two skill families, judging from the example 2026 titles below: window functions for streaks, top-N per group and growth, and grouped aggregation with HAVING for rule-based and per-entity questions. Tree and hybrid prompts sit at the edges. These six titles are examples, not a tally of the bank, and our data holds titles, companies, rounds and dates rather than full prompts, so the pattern column is our reading of each title.

Our take: drill window functions hardest. Three of the six example titles need them, and their placement rules are where live answers break; the HAVING-based titles mostly test grain, which the pre-submit check above already covers. PostgreSQL's documentation states the rules plainly, and each one maps to a mistake you can avoid on purpose.

StrataScratch's guide adds the tie rule for top-per-group questions: avoid ROW_NUMBER unless the prompt says to pick one. PostgreSQL's documentation says the basic value of a WITH query is "to break down complicated queries into simpler parts". For you, that is also a narration tool: one CTE per grain gives the interviewer a step to check after each block.

Worked example: how would you solve the login streak question?

Frame it before you write it. Take the ByteDance streak title from the table: the output is one row per user with that user's longest run of consecutive login days. Our data holds the title, not the schema, so the table and column names below are assumed for illustration: a logins table with a user id and a login timestamp.

Framing, said aloud: the input grain is one row per login event, and the grain you need is one row per user per day, so reduce to user-day first. Ask whether a day means the UTC date or the user's local date, because that decides which logins fall on which day. With that settled, the query is three CTEs and an outer aggregate.

WITH login_days AS (            -- grain: one row per user per day
  SELECT user_id, CAST(login_at AS DATE) AS login_day
  FROM logins
  GROUP BY user_id, CAST(login_at AS DATE)
),
numbered AS (                   -- consecutive days share the same anchor
  SELECT user_id, login_day,
         login_day - CAST(ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_day) AS INT) AS anchor
  FROM login_days
),
streaks AS (
  SELECT user_id, anchor, COUNT(*) AS streak_len
  FROM numbered
  GROUP BY user_id, anchor
)
SELECT user_id, MAX(streak_len) AS longest_streak
FROM streaks
GROUP BY user_id;

Explain each step as you go. The first CTE fixes the grain at the source rather than patching duplicates at the end. Because each user now has at most one row per day, there are no ties inside a partition, so the unspecified tie order of row_number cannot change the result. For consecutive days, the day minus its row number stays constant, so that difference is the streak's group key. PostgreSQL forbids window functions in GROUP BY, which is why the numbering sits in a CTE and the grouping happens one level up. Close by naming the edge cases: a user with a single login has a streak of one day, and a date filter on the input must say whether its end date is inclusive.

The same frame carries to the other two OA and phone-screen shapes. For Pinterest's top two categories per country, aggregate to country and category first, compute the engagement rate, then rank within each country and keep ties as the prompt requires. For DoorDash's monthly growth, aggregate to month first, then use LAG over month order, and say what the first month returns and what happens to a month with no sales.

Are SQL rounds pure SELECT-and-JOIN work?

No. Some recent titles involve tree-shaped data, Python or a pipeline. Oracle's Classify Tree Nodes in SQL was last reported in a phone screen in 2026-09. Lyft's Query and transform marketplace data in SQL/Python came from an onsite in 2026-05, and Robinhood's Analytics Engineer: SQL + Python Sessionization from a phone screen in 2026-03. Each needs one pattern beyond window functions.

Tree-shaped data. If the Oracle prompt follows the textbook form, labelling each node as root, inner or leaf from a parent-id column, a CASE expression with an EXISTS check on children is enough. If it asks for depth or a path, you need recursion. PostgreSQL's documentation says that with RECURSIVE, "a WITH query can refer to its own output", and that recursive queries "are typically used to deal with hierarchical or tree-structured data". The same documentation warns that the recursive part must eventually return no rows, "or else the query will loop indefinitely". It also says row order within each level is undefined, and recommends adding data columns as secondary sort keys for a stable sort.

SQL plus Python. Sessionization is the standard version: take the gap between each event and the previous one for the same user, start a new session when the gap exceeds a threshold, and number sessions with a running sum of those flags. You can do it in SQL with LAG and SUM OVER, or in Python after sorting by user and time. In our view, the decisions worth preparing are where the session boundary goes and on which work belongs in the database: push filtering and aggregation into SQL so less data crosses into Python, and keep in Python only the logic that is awkward to express as a query.

Pipeline-shaped prompts. Netflix's Data Engineering Movie Success Pipeline was last reported in a phone screen in 2026-03 and is linked from 3 candidate write-ups. The title points to a pipeline rather than a single query. Our data gives only the title, round, date and link count, so this is our view, from standard pipeline engineering: prepare idempotent reruns, so that reprocessing a day does not double-count, and a plan for late-arriving data that changes a result already published.

Our take: learn one recursive CTE pattern with an explicit termination condition, and practise one task that queries in SQL and transforms in Python. Sessionization covers both the window logic and the hand-off.

What changes at senior and staff level?

SQL rounds are reported at senior level too, but our level data is thin. Candidate write-ups link these SQL questions 4 times from candidates who reported a senior, staff-plus or manager level, and 17 times from candidates who reported a junior, new-grad or intern level. Levels are self-reported, and the split reflects who wrote up their loops.

Do not read that split as evidence that seniors rarely get SQL. The sample is too small to say how often seniors meet a SQL round or how it differs. On role, two of the titles name a data role directly, Analytics Engineer and Data Engineering, but this data does not split SQL questions by the candidate's role. If your loop lists a SQL or data round, prepare it whatever your title is.

Where the data runs out, this is our view of what a senior answer adds. State the data definition before coding: what counts as a login, an active user or a sale. Name trade-offs; StrataScratch's guide says interviews increasingly reward candidates who can discuss readability versus performance. Raise data problems before you are asked. The guide gives an example of that senior signal: "If timestamps are stored in UTC but the business definition is local day, I'd clarify timezone before I commit to DATE(timestamp)". At staff level, name who owns the metric definition and propose one production check, such as reconciling the output's row count against the source table, so the number cannot drift silently.

Where the level signal sits

Our view: a SQL round mostly answers whether you can get a correct result and explain it. The level decision rides more on system design depth, the project deep dive and the scope of your behavioral stories. A clean SQL round will not lift you a level, but a silent or sloppy one can feed a down-level, because framing and unprompted edge cases are the senior-shaped signals the round does carry.

How should you prioritise SQL prep by company and round?

Ask your recruiter which round holds the SQL, then match your drills to that round with the rule below. The phone screen carries the most SQL reports in the bank, and the company ranking above tells you whether your target has enough reports to form its own practice set.

Use this decision rule:

• SQL phone screen: spend most of your SQL time on timed, talk-aloud window-function and CTE problems: streaks, top-N per group and growth.
• Onsite data round: add one hybrid SQL plus Python task and one rule-based filtering problem that needs HAVING.
• OA only: still drill streak and top-N-per-group patterns, which appear among the OA-reported example titles discussed above.
• Target company outside the top five: use the pattern table, not a company list, and add the tree and sessionization shapes.

Practise on an engine that shows you the failing input rather than a bare wrong-answer flag. TrueInterview says SQL runs on Postgres on its site, and that coding and SQL are "judged on hidden tests that show you the case you failed". A failing case usually points straight at the grain or tie decision you got wrong, which is the habit the live round rewards.

How we counted

The counts come from TrueInterview's question bank as of 2026-11-02: 222 SQL questions filed from candidate reports at 25 big-tech companies. They are candidate-reported questions reconstructed for practice and are not any company's official question list. Round counts overlap because one question can be reported in more than one round, levels are what candidates reported about themselves, and every count measures what candidates wrote up, not how often a company asks SQL.

FAQ

Do big tech SQL interviews happen in the online assessment?

Some do, but in TrueInterview's bank the online assessment is the least reported of the three SQL rounds, behind phone screens and onsites, as the counts above show. The OA titles we list still test real patterns, a login streak at ByteDance and top two categories per country at Pinterest, so an OA is not a reason to skip window functions. Prepare for a live phone screen first, because that is where most reports sit, and treat the OA as the same patterns without an interviewer to talk to.

Which SQL functions should I learn first for a big tech interview?

Learn ROW_NUMBER, RANK, DENSE_RANK, LAG and SUM with OVER, and learn when each one fits: ROW_NUMBER for picking exactly one row, RANK or DENSE_RANK when ties must stay, LAG for period-over-period growth, and a running SUM for sessions and cumulative totals. Pair them with CTEs: in PostgreSQL, window results can only be filtered one query level up, and while some warehouses add a QUALIFY clause, a CTE works in every engine. Add one recursive CTE pattern last. That set covers every shape in the pattern table above.

What are the most common mistakes in SQL interview answers?

Besides the four-point check above, the most expensive mistake in window problems is filtering on a window result directly, which PostgreSQL rejects in WHERE, GROUP BY and HAVING. The next is using ROW_NUMBER in a top-N question that must keep ties, which silently drops rows. Write both on your rules card as one line each: in PostgreSQL, WHERE cannot see a window result, and ROW_NUMBER breaks ties arbitrarily. Read the card before each practice session.

Do I need Python for a SQL interview?

Sometimes. Two of the titles in the hybrid section above combine SQL and Python, at Lyft and Robinhood, so a data round can ask you to query in SQL and transform the result in Python. You do not need deep Python for it. You need to sort, group, compare each row with the previous one and compute a running value, and to explain why each step sits in SQL or in Python. Practise one sessionization task both ways.

How should a senior engineer answer SQL questions differently?

Before you touch the editor, say what one output row means, which definitions are ambiguous and what you assume for each, then write the query in named CTEs so each step can be checked. After the query runs, raise duplicates, ties, time zones and date boundaries yourself instead of waiting to be asked. When a follow-up adds a constraint, say what you would change and why, including the readability or performance cost.

Your practice plan

This plan fits three weeks of evenings alongside a full-time job.

1. Pick your target company and list its SQL questions last reported in the past year from the question bank; that list is your first practice set.
2. Write the streak query for Longest Consecutive Login Days per User from a blank editor, narrating grain and the time zone question aloud, then write it again from memory later in the week.
3. Solve Top Two Categories by Engagement Rate per Country once with RANK and once with DENSE_RANK, and explain which one the prompt's tie rule requires.
4. Solve Monthly Sales Growth with LAG, then say what the first month returns and how you would handle a month with no sales.
5. In the second week, run the four-point check on Find Hosts Meeting Listing, Rating, and Review-Coverage Rules and Write SQL with HAVING and efficient joins before you submit.
6. Write a one-page window-function rules card from the PostgreSQL table above and read it before each session.
7. In the third week, cover one edge shape: Classify Tree Nodes in SQL for tree data, or Analytics Engineer: SQL + Python Sessionization if your loop includes an onsite data round.
8. End with a timed run of a question you have not seen, and ask a friend to add a constraint after your first answer so you practise the follow-up.

Sources

• TrueInterview question bank — SQL at big-tech companies — counted 2026-11-02
• SQL Scenario Based Interview Questions and Answers - StrataScratch — checked 2026-11-02
• PostgreSQL: Documentation: 18: 3.5. Window Functions — checked 2026-11-02
• PostgreSQL: Documentation: 18: 7.8. WITH Queries (Common Table Expressions) — checked 2026-11-02
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-11-02

Last reviewed: 2026-11-02.