SQL Interview Questions for Senior Engineers: 219 Reported (2026)

As of 2026-10-11, TrueInterview's bank holds 219 candidate-reported SQL questions from 25 big-tech companies, and the bank files every one under a single SQL tag, so it cannot rank topics for you. What repeats across employers is a short list of query shapes, such as the latest row per key, top N per group, streaks and sessions, rather than a company catalogue you can memorise. Our take: drill those shapes at phone-screen pace on recently reported questions, confirm whether your round is really SQL plus Python or a data-modelling exercise, and at senior level raise the bar on the same queries instead of hunting for harder ones.

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.

Which questions are candidates reporting at big tech this year?

Ten recent reports show the spread: single queries in phone screens at Stripe, Oracle, Meta, Snowflake and Netflix, timed sets in online assessments at ByteDance and OpenAI, and SQL wrapped in Python or data modelling at Lyft, Robinhood and DoorDash. The last column is our reading of what each title asks for, not a tag stored in the bank.

Read the table by shape, not by employer. Stripe's balance question and ByteDance's login streak come from different companies and different rounds, yet both are window-function problems you can rehearse in one evening. The three titles that mention Python or data modelling are the ones that should change how you split your hours.

Data Engineering Movie Success Pipeline (Netflix)

This is the most traceable question in the set: it is linked from 3 candidate write-ups, all from Netflix. The title points at a pipeline written in SQL, so stage each step in its own CTE, aggregate per title, and say aloud what one row represents after every join. That grain sentence is what stops a join from quietly multiplying a metric, and it is the habit an interviewer can hear.

Find the Latest Balance for a Bank Account (Stripe)

This is the latest-row-per-key shape, the same one DataDriven's FAANG guide reports as keeping only the latest record per user from a table that receives repeated updates. Number each account's rows by time with ROW_NUMBER, keep the first, and decide before you run it what breaks a timestamp tie. The senior section below explains why that last decision carries the level signal.

Longest Consecutive Login Days per User (ByteDance)

An assessment streak question, the shape DataDriven's FAANG guide lists as finding each user's longest streak of consecutive login days. The standard technique subtracts a ROW_NUMBER from the login date so consecutive days share one group value, then counts rows per group. Deduplicate same-day logins first, or two logins on one day will split a streak in two.

Analytics Engineer: SQL + Python Sessionization (Robinhood)

Sessionization is a LAG problem: compute the gap to the previous event, flag gaps above the threshold, and turn a running sum of the flags into a session id. The same logic then has to exist in Python, so practise it once in each language and compare the edge cases, especially the first event per user and events with identical timestamps.

Where do these questions show up: phone screen, onsite or online assessment?

Mostly in the phone screen. Reported rounds for the 219 questions run phone screen 132, onsite 61 and online assessment 30, and one question can count in more than one round. Spend your first two weeks on timed single-query reps at screener pace, because that is where most reported questions sit.

Because the bank uses one SQL tag for every question in every round, it cannot tell you whether topics shift between rounds. What other sources describe changing is pace and depth, so the table pairs our round counts with their format notes.

The DataExpert post lists the screener as a ladder: a WHERE condition with a GROUP BY, a JOIN plus aggregation, a CTE or subquery that reuses an earlier technique, and finally a self-join or a question that digs into optimisation. DataDriven's SQL guide describes the same round as a small schema, a business question phrased the way a product manager would ask it in Slack, and 15 to 30 minutes to write a working query.

Our take: generic prep lists treat the assessment as the main event because it is the easiest round to simulate. The reported mix points the other way. If your loop includes an online assessment, as reported for ByteDance's streak question and OpenAI's mixed set, schedule the timed sets for the week before it; otherwise they belong in the last few days.

Does your target company change what you should practise?

It changes how much evidence you have, not which shapes you drill. Meta has 62 reported SQL questions in our bank, Amazon 24, DoorDash and ByteDance 22 each, while Google has 8 and Netflix 6. If you are targeting Meta, work through its set; at Google or Netflix there is too little volume to memorise, so spend those hours on shapes.

The bank cannot compare company topics either, because every question filed under Meta, Amazon, DoorDash and ByteDance carries the same single SQL tag. What other sources do describe differing is format, and DataVidhya's SQL-round module gives a format note for four of them.

Our take: the common advice is to collect a company-tagged list and memorise it. In our bank the company label carries volume, and other sources add format; neither gives a topic profile, and the gap between Meta and Google measures what candidates reported rather than how much SQL either company asks. For a low-volume target, other sites' examples help with flavour: AI2SQL's FAANG guide reports a Google question computing Day-7 retention for each weekly signup cohort. Treat it as one more instance of a shape, not as a forecast.

Which query shapes cover most of what gets asked?

A short list. DataDriven's SQL guide says 8 patterns cover roughly 90% of the SQL data engineers see in interviews, and AI2SQL's FAANG guide says the same six patterns show up in 80% of phone screens. Those are other sites' counts over their own banks, but they agree with the titles in ours: the questions resolve to a handful of shapes.

Read the percentages as a ranking, not a budget. Aggregation and joins decide whether you pass a phone screen, and window functions decide how well. AI2SQL's guide adds two traps worth a drill each: using LIMIT instead of ROW_NUMBER for top N per group, which breaks when groups differ in size, and writing a WHERE COUNT(*) condition that can never be valid.

What we'd skip: DBMS-syllabus material such as the GeeksforGeeks question on the difference between CHAR and VARCHAR2. AI2SQL's guide says "FAANG SQL rounds rarely test trivia", and DataVidhya's module says its question set uses no recursive CTEs and no dynamic pivots. Spend those hours on timing and edge cases instead.

How recent are the questions, and what about the older ones?

Recent enough to schedule against: 90 of the 219 questions were last reported within the 12 months before 2026-10-11. Practise those first, in weeks one and two, and treat the rest as pattern reps rather than a forecast of what you will be asked.

TrueInterview says each report is dated wherever the report gave a month and checked against other reports of the same round. That is why the first table can show a month for every question. By contrast, the GeeksforGeeks SQL interview page carries a page-level last-updated date of 30 June 2026, which tells you when the page was edited, not when any question was last asked. Before trusting any list labelled current, look for a date on each question rather than on the page.

Is your SQL round really a SQL-only round?

Not always, and the round label usually tells you. Three titles in our bank wrap SQL in something else: Robinhood's phone screen is an analytics-engineer SQL and Python sessionization, Lyft's onsite asks you to query and transform marketplace data in SQL or Python, and DoorDash's onsite is a data-modelling exercise. If your invitation reads like one of these, move about a third of your hours to Python and schema design.

The Python half stays close to the data. DataDriven's FAANG guide says the Python round involves parsing records and grouping them with dictionaries before sorting, rather than graph algorithms, and Exponent's Microsoft data-engineer guide lists a technical screen that tests Python and SQL together. Our take: for data and analytics-engineering loops, an evening rewriting your SQL answers as plain Python beats an evening of algorithm puzzles.

For a modelling round like DoorDash's, the deciding questions are standard engineering ones. Name the grain of each fact table before drawing it. Then say how a user who changes plan or device is represented, because that answer decides whether the next query is a simple join or a history lookup.

What changes at senior and staff level?

The question mostly stays the same; the bar on your answer moves. Candidate write-ups link these SQL questions 7 times from candidates who reported a senior, staff-plus or manager level and 7 times from candidates who reported junior, new-grad or intern. Levels are self-reported and these are link counts on a small set, so read the split as parity, not proof.

The one question we can trace, Data Engineering Movie Success Pipeline, draws 2 write-ups from senior-or-above candidates and 1 from a junior, new-grad or intern candidate. One account of a Didi data-science loop on sirjohnnymai.com reports that junior candidates wrote nested SELECTs that failed on null handling, that senior candidates used CTEs with ROW_NUMBER(), and that the panel judged "thinking in relational models" over syntax. It is one person's report, but it matches what the shape table predicts: the difference is technique on the same prompt.

This table is our view, built on three cited points. DataDriven's FAANG guide says "The second ORDER BY key is the part interviewers listen for" because two updates at the same timestamp otherwise make the result change between runs. The same guide advises explaining a DENSE_RANK choice against ROW_NUMBER, which would drop a tied product arbitrarily, and RANK, which would skip ranks after a tie. DataDriven's SQL guide calls window functions "The tier that decides senior rounds."

Our take: stop looking for a separate list of staff-level SQL questions. Take the questions in the first table and answer each at the senior bar: name the tiebreaker, justify the ranking function, state the grain, and answer the skew question from the company table before it is asked. AI2SQL's guide notes that COUNT(column) skips NULLs while COUNT(*) does not, and says "Senior interviewers test this."

Which rounds decide whether you are down-leveled?

Our take: in a data loop, the SQL screen mostly decides whether you continue, and the level is set elsewhere: in the data-modelling or pipeline round, in the depth questions of the onsite SQL session, and in the scope of your behavioral stories. A clean query proves the floor; the follow-ups and the model prove the level.

DataDriven's FAANG guide says data-engineer loops at Meta, Amazon, Apple, Netflix and Google follow the same plan of SQL and Python, data modelling and pipeline design, and behavior. Exponent's Microsoft guide says "Interviewers will often down-level a candidate for not knowing the right view or distribution for the prompt." The Didi account on sirjohnnymai.com reports that candidates who could not articulate a clear relational data model were rejected despite solving algorithmic puzzles.

If you are interviewing at senior or staff level, ask the recruiter which round carries the modelling or pipeline discussion and treat it as the level round. For pipeline design, prepare to defend idempotent reruns and backfills; our system design questions by company and round covers that family. For behavioral scope, see our behavioral questions by company and round.

How is the round scored once your query runs?

Correctness first. DataVidhya's SQL-round module gives the rubric in strict priority order: correctness, then speed, then edge-case discipline, then communication. The Twitch engineering blog agrees that correctness beats efficiency and elegance. Write the plain correct query first, and optimise only when asked or when the interviewer raises data size.

AI2SQL's guide says optimising prematurely without a correct baseline is a common red flag interviewers report. Once the baseline runs, Exponent's Microsoft guide says discussing complexity in your answer is a huge green flag for Microsoft interviewers, so the order matters more than the content: correct, then costed.

Two habits separate a pass from a strong pass. DataVidhya's module lists saying "done" with no self-review as a mistake, because the pause-and-scan is scored whether or not you check. DataDriven's SQL guide recommends mixed problems on a 25-minute timer while narrating trade-offs, and adds: "The silent stretches are what an interviewer remembers."

How we counted

Counts come from TrueInterview's question bank as of 2026-10-11 and cover SQL questions filed under 25 big-tech companies. They are candidate-reported questions reconstructed for practice, not any company's official question list, and TrueInterview says each was asked at the company it is filed under. A question can be reported in more than one round, so round tallies overlap, and the shape column is our reading of each title rather than a stored tag. Level splits count write-up links by the level candidates reported for themselves, which is not a count of distinct write-ups.

FAQ

Are these the SQL questions big tech companies officially ask?

No. They are candidate-reported questions reconstructed for practice, filed under the company where the candidate met them, and no employer published them. Use them to choose what to drill first and to see the shape and round a company favours, not to predict your exact prompt. A shape you can solve cold transfers to a question you have never seen, while a memorised answer fails on the first changed column.

Do new grads get easier SQL questions than senior candidates?

Our data cannot show that. The senior and junior link totals above are equal, and the bank carries no difficulty field, so nothing in it marks an easier tier for new grads. What the sources describe differing is the expected answer. A new grad who returns correct rows with NULLs handled and explains each join is meeting the bar. DataVidhya's module describes typical data-engineering interview SQL as LeetCode-easy to easy-medium, covering conditional aggregation, top N per group, retention with LAG and dedup, so a new grad should drill those until they are fast.

Is LeetCode SQL practice enough for a big tech SQL round?

It covers the syntax, not the round. The Twitch engineering blog says "medium/hard on Leetcode is a great bar to aim for", while DataVidhya's module says the questions are LeetCode-easy and you are scored on four things at once. We side with DataVidhya for phone screens: speed and edge-case discipline on easy-medium problems decide more rounds than one hard problem solved slowly. Use hard problems for onsite depth.

Which SQL dialect should I practise in?

Practise in a Postgres-style dialect and avoid engine-specific functions. The Twitch engineering blog says candidates may use any dialect they are comfortable with, and notes that Twitch's Redshift derives from Postgres. A big-tech interviewer's DataExpert post says Meta wants candidates to use only ANSI SQL. TrueInterview says its SQL runs on Postgres, so reps there transfer to most screens.

Are company-tagged lists like DataLemur's worth using?

As extra shape reps, yes; as a forecast, no. DataLemur's question page describes its bank as "the most common SQL, Statistics, ML, and Python questions asked in FAANG Data Science & Data Analyst interviews", and tags one medium question, Second Highest Salary, to FAANG as a whole rather than to a single company. Filter such lists to SQL, map each title to a shape, and skip anything you already solve on a timer.

Should I memorise answers to the reported questions?

No. The Didi account on sirjohnnymai.com lists memorising SQL syntax without understanding why a particular join is needed as a mistake to avoid. Memorise the shapes and the decisions instead: which ranking function, which tiebreaker, which join type and what grain. Then solve each reported question from a blank editor, because the interviewer will change a column or a constraint and a memorised answer will not survive it.

Your practice plan

The target is narrower than a generic top-N list: a handful of shapes, the recent questions, and your company's format. This plan assumes four or five evenings a week for three weeks while you work full time.

1. Week one, first two evenings: solve Find the Latest Balance for a Bank Account and Longest Consecutive Login Days per User on a timer, narrating aloud, and name the tiebreaker before you run either query.
2. Week one, remaining evenings: run aggregation and join reps back to back, as a screener would, on Project Duration & Budget per Employee, Event Friends Recommendation and Classify Tree Nodes in SQL.
3. Week two: in TrueInterview's question bank, filter to your target company and to questions reported in the past year. At Meta, work the company set; at a low-volume company, keep drilling shapes and use its questions as a final check.
4. Week two, if your round mentions Python or modelling: split the evenings between Analytics Engineer: SQL + Python Sessionization, Query and transform marketplace data in SQL/Python and DE / AE Onsite: Data Modeling (Fitness App), stating the grain before drawing any table.
5. Week two, if you are senior or staff: re-solve your week-one questions at the senior bar from the level table, and answer the skew follow-up for every aggregate.
6. Week three: run Data Engineering Movie Success Pipeline as a full mock and record yourself once. If your loop includes an assessment, add Basic SQL Querying (Filtering, Aggregation, Join, Window Functions) under a strict timer.
7. Last evening: before saying done on any query, scan it for NULLs, ties, duplicate rows and empty groups, the four failures that return a plausible wrong number.

Sources

• TrueInterview question bank — SQL at big-tech companies — counted 2026-10-11
• FAANG Data Engineer Interview Questions and Answers (2026) — checked 2026-10-11
• How to pass data engineering SQL interviews in big tech — checked 2026-10-11
• 928 SQL Interview Questions for Data Engineers in 2026 — checked 2026-10-11
• What They're Scoring · Data Engineering Interview Prep: The Complete Course | Data Vidhya — checked 2026-10-11
• SQL Interview Questions for FAANG (2026): Real Questions From Meta, Google, Amazon, Apple, Netflix | AI2SQL — checked 2026-10-11
• SQL Interview Questions - GeeksforGeeks — checked 2026-10-11
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-10-11
• Microsoft Data Engineer Interview Guide | Sample Questions (2026) - Aced (formerly Exponent) — checked 2026-10-11
• Didi data scientist SQL and coding interview 2026 | Johnny Mai — checked 2026-10-11
• Acing Twitch's SQL screen — checked 2026-10-11
• Real FAANG Interview Questions by Company · TrueInterview — checked 2026-10-11
• SQL Interview Questions | DataLemur — checked 2026-10-11

Last reviewed: 2026-10-11.