Most developers learn SQL on the job, often reactively: the ORM does the heavy lifting, a query runs slow, and suddenly you’re reading about indexes at 11pm before a production deploy. That kind of knowledge is real, but it has gaps that tend to show up badly in technical interviews, because interviews test structured fundamentals while production experience is often ad hoc and context-dependent.
This is a guide specifically for developers (backend engineers, full-stack engineers, software engineers who touch databases as part of a broader role) preparing for technical screens where SQL comes up. Not a guide for people interviewing for DBA or data engineering roles, where the depth expectation is higher.
What developer SQL interviews actually test
The expectation varies a lot by seniority. For junior and mid-level developers, SQL interview questions are mostly about correctness: can you write a working JOIN, do you understand aggregation, can you handle NULLs properly. The 2024 Stack Overflow Developer Survey found that around 51% of professional developers use SQL regularly, which means it’s fair game in almost any backend or full-stack screen regardless of whether the job description specifically calls it out.
For senior developers, the expectation shifts toward explanation and tradeoffs. Writing correct queries is assumed. The interesting questions become: why did you choose this approach over that one, how would you optimize this query that’s running in 3 seconds, what’s the execution plan telling you, and when would you move data out of the relational database entirely.
The JOIN questions that trip people up
JOINs are the first SQL thing most developers learn and the first place interviews probe for gaps. The syntax is easy. The confusion usually lives in OUTER JOIN behavior and NULL propagation.
A question I’ve seen come up in several developer screens: “Given tables A and B, write a query that returns all rows from A that have no matching row in B.” The correct pattern is a LEFT JOIN with WHERE B.id IS NULL. Getting there requires knowing that the NULL in the result set comes from the unmatched join, not from null values in the source data. These two sources of NULL confusion each other in practice.
CROSS JOIN is less commonly asked but still worth knowing: it produces the Cartesian product of two tables. Useful for generating test data or building calendar tables. Never accidentally triggered by a WHERE clause that fails to link two tables in older SQL syntax (some databases allow this and produce a Cartesian product silently).
Performance questions: what you’re actually being tested on
For senior developer interviews, the most common SQL question type isn’t “write a query” but “here’s a slow query, what’s wrong with it.” The diagnostic process matters more than whether you arrive at the right answer.
The correct sequence: look at the execution plan first (EXPLAIN or EXPLAIN ANALYZE in Postgres, EXPLAIN FORMAT=JSON in MySQL), identify whether the slow operation is a table scan that could be served by an index, check join order and whether the query planner is choosing a sensible strategy, and look for correlated subqueries that could be rewritten as joins.
Common patterns that make queries slow in ways that come up in interviews:
- Functions on indexed columns in WHERE clauses. WHERE YEAR(created_at) = 2024 prevents index use. WHERE created_at BETWEEN ‘2024-01-01’ AND ‘2024-12-31’ allows it.
- SELECT * in production code. Beyond the obvious data-volume issue, it prevents the query planner from using covering indexes. Interviewers ask this because it’s a proxy for whether you think about what the database actually does with your query.
- Correlated subqueries in SELECT or WHERE that execute once per row. This is the O(n) vs. O(1) distinction at the database layer. The fix is almost always a JOIN or a subquery moved to the FROM clause.
Transactions and ACID: the conceptual question you should expect
Not every developer interview asks about ACID, but enough do that it’s worth knowing concretely rather than abstractly. Atomicity, Consistency, Isolation, Durability. The one that causes real bugs is Isolation, specifically transaction isolation levels: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE.
READ COMMITTED is the default in many databases and prevents dirty reads but allows non-repeatable reads and phantom reads. REPEATABLE READ (Postgres’s default in practice) prevents those but can still have serialization anomalies depending on implementation. A common interview question: “What’s a dirty read and why does it matter?” A dirty read is when a transaction reads data that another transaction has written but not yet committed. If the writing transaction rolls back, you’ve acted on data that never existed.
According to the BLS Software Developer Occupational Handbook, data management and database integration skills are listed as core competencies for software developers broadly, not just specialists. The interview questions reflect that expectation.
Practical prep approach
Two weeks before a technical screen, if you know SQL will come up: spend 30 minutes per day on LeetCode database problems or StrataScratch. Focus on medium-difficulty problems that involve window functions and multi-table JOINs. Practice writing queries in a plain text editor, without autocomplete, and then running them to check. The constraint-only environment is closer to a whiteboard or shared-screen interview than your normal IDE.
Read through a few real EXPLAIN ANALYZE outputs from your own production databases if you have access. Being able to read an execution plan fluently is a senior-level signal, and it’s a skill most developers have partial exposure to but haven’t made explicit.
If you’re preparing for a full technical screen that includes SQL plus system design plus behavioral questions, Craqly’s AI interview copilot can walk you through a practice session that mixes question types the way real interviews do. The switch between “write a query” and “explain a tradeoff” is its own skill, and it helps to have practiced the transitions.
The developers who do worst in SQL interview rounds usually know the material well enough. They struggle with the explanation under pressure, not the query itself. That’s the specific thing to practice.