For a technology that turned fifty, SQL is remarkably hard to kill. New databases, query engines, and AI tools arrive constantly, and yet almost every data-heavy role — backend, data engineering, analytics, ML — still puts a SQL round in the loop. The reason is simple: SQL is where correctness meets performance on real data, and that skill hasn’t been automated away. Here are the questions these roles still ask, and the concepts that separate strong candidates.
Joins — and knowing exactly which one
Joins are the heart of SQL interviews, and the mistake is treating them as memorised keywords. You will be expected to know the difference between an inner join (only matching rows), a left join (all rows from the left table, with nulls where the right has no match), and the rest — and, more importantly, to choose the right one for a question and reason about what happens to unmatched rows. A classic trap is a query that silently drops records because someone reached for an inner join where a left join was needed. Interviewers watch whether you think about the nulls, not just the syntax.
GROUP BY, aggregation, and the WHERE vs HAVING distinction
Aggregation questions (“total revenue per customer,” “average order value per month”) test whether you understand how rows collapse into groups. The concept that trips people up is filtering: WHERE filters individual rows before grouping, while HAVING filters after aggregation. Asking for “customers whose total spend exceeds 1,000” requires HAVING on the aggregate, and candidates who reach for WHERE reveal a shaky mental model of the order operations execute in.
Window functions
If there is one topic that separates intermediate from strong SQL candidates in 2026, it is window functions. Being able to compute a running total, rank rows within a group, or compare each row to the previous one — using ROW_NUMBER(), RANK(), LAG(), or a windowed SUM() with OVER (PARTITION BY … ORDER BY …) — is now expected for serious data roles. These questions are common precisely because they distinguish people who can express complex analytical logic in SQL from those who would export the data and loop over it elsewhere.
Finding duplicates, second-highest values, and the “clever” queries
Certain puzzle-style questions recur endlessly: find duplicate rows, return the second-highest salary, get the most recent record per group, remove duplicates while keeping one. They aren’t asked because the exact query is important; they’re asked because solving them cleanly requires combining grouping, subqueries or window functions, and clear thinking. Being able to talk through why your query works — and handle the edge cases like ties — matters more than recalling a one-liner.
Indexing and query performance
The moment a role touches real data volume, performance questions appear. You should be able to explain what an index actually is (a structure that trades write cost and storage for faster reads), why a query might do a full table scan, and how to reason about making a slow query fast. You don’t need to have memorised every database’s internals, but “add an index” as a reflex — without understanding what it costs or when it won’t help — is a weak answer. Strong candidates reason about access patterns first.
The N+1 problem and query efficiency
Especially for backend roles, expect questions about how many queries your code issues, not just whether they’re correct. The N+1 problem — running one query to fetch a list, then one more query per item — is a pervasive performance killer that a single well-constructed join or batched query eliminates. Recognising it, and knowing how to collapse many round-trips into one, is a marker of someone who has debugged real database performance.
How to prepare efficiently
SQL rewards focused practice because the surface area is bounded and the same concepts recur. Prioritise joins, aggregation with the WHERE/HAVING distinction, and window functions — that trio covers a large share of what gets asked — then layer in indexing and query-efficiency reasoning. Working through a structured set of SQL interview questions builds the pattern recognition that makes these feel routine, and keeping quick-reference cheatsheets nearby helps the exact syntax stick while you focus on the reasoning.
The bottom line
SQL interviews persist in 2026 because SQL is still where data correctness and performance are decided, and no tool has removed the need to get both right. Master joins, aggregation, and window functions, understand indexing and the N+1 trap, and you’ll clear the round that nearly every data-heavy role still, quietly, relies on.