SQL Debugging Interview Questions (With a Real Database)

Most SQL interview questions ask you to write a query. A SQL debugging question hands you one that already exists and says it is wrong: the totals don't match the bank, a list comes back empty, or a page takes seconds. Your job is to find out why, fix it, and show the fix is safe on a real table. It is the database version of the debugging round in an AI coding round, and Google's reported AI-assisted pilot asks candidates to "read, debug and optimize" existing code (Moneywise, citing Business Insider). For the AI rules different companies set, see our AI coding interview overview.

Practice on a real database. Every question below links a problem on AICodingRound that runs on a real PostgreSQL database. Start with The win-back email list came back empty (easy, about 15 min). The beta is free and places are limited: get a place.

A method that works on any query

Wrong-result bugs and slow-query bugs need slightly different tools, but the start is the same.

1. Pin one wrong row. Turn "the numbers are off" into one specific row: "Dana should have 95 minutes, the report says 350." You can check one row by hand. You cannot check a whole report.
2. Run the query in pieces. Take the query apart one join or one CTE at a time and count the rows after each step. The step where the count or the value changes unexpectedly is where the bug is.
3. Check types and NULLs. Look at the column types in every comparison and every calculation. Ask what happens to each expression when a value is NULL.
4. For speed, read the plan. PostgreSQL's EXPLAIN shows "what query plan the planner creates for any query." With ANALYZE, it "actually executes the query" and shows true row counts and timings, and the BUFFERS option helps "identify which parts of the query are the most I/O-intensive" (PostgreSQL docs). On a small sample database, timings tell you little; the plan shape and the rows read tell you a lot.
5. Check what your fix touches. An index, a constraint or a data migration changes the live table. Ask what it locks, how long it runs, and what happens if it fails halfway.

One safety habit: EXPLAIN ANALYZE on an UPDATE or DELETE really changes data. The PostgreSQL docs suggest wrapping it in BEGIN and ROLLBACK (PostgreSQL docs). Saying that out loud in an interview is a good sign.

Ten SQL debugging questions, with a database to run them on

Each item below is a question in the form an interviewer might ask it, a checklist of common suspects, and one of our practice problems with that symptom. The checklists are general; they are not the answers to the problems. Finding out which suspect, if any, is guilty is the exercise.

1. "The month-end total is missing the last day"

Suspects: how the date range ends (inclusive or exclusive, a date or a timestamp); the time zone the values are stored and compared in; a status or join filter that drops late rows; how the month itself is computed. The PostgreSQL wiki's list of common mistakes has an entry on dates and timestamps worth reading (PostgreSQL wiki). Practice: The October close is missing the last day of the month (easy, about 15 min).

2. "The list came back empty, but I can see rows that belong in it"

Suspects: a NULL somewhere in a comparison (NULL is neither equal nor unequal to anything); an inner join that drops rows with no match; a filter on the outer side of a left join; a date or status filter that no row passes. Practice: The win-back email list came back empty (easy, about 15 min).

3. "The percentages are always a little low"

Suspects: the type of every value in the expression; rounding at the wrong step; a different denominator from the one the business uses; rows missing from the numerator. Practice: Return rates on the weekly report are always rounded down (easy, about 15 min).

4. "We counted fewer buyers than the shop admin shows"

Suspects: what exactly is being counted as one buyer; a join that drops buyers; a filter on the wrong date; orders the admin page counts differently, such as cancelled or test orders. Practice: The unique-buyers report undercounts campaigns (easy, about 15 min).

5. "The totals are too high for some people, and one person is missing"

Suspects: a join that repeats rows (pin one parent row and count what it becomes after each join); an inner join that drops a person with no activity; the key you group by; a filter on the wrong week. Practice: Weekly agent workload shows inflated comments and minutes (medium, about 35 min).

6. "The ranking is per region, but it ranks the whole company"

Suspects: how the window is defined (what it partitions by and what it orders by); what a NULL does to arithmetic and to SUM; ties in the ranking; whether a filter runs before or after the rank. Practice: 'Top products by region' shows three rows for the whole company (medium, about 35 min).

7. "The running balance resets each month, and same-time entries show the same balance"

Suspects: which rows the window can see; the window's frame and its sort order; rows that share a timestamp; the opening balance; the order in which filters and the window are applied. Practice: Account statements show wrong running balances (medium, about 40 min).

8. "This page reads the whole table to find one day's orders"

Suspects: no index on the filtered column; an index that exists but that the query cannot use as written; stale statistics; a query that returns far more rows than the page shows. PostgreSQL can index an expression, such as lower(col1), but the docs note that "index expressions are relatively expensive to maintain" (PostgreSQL docs), so it is not always the best answer. Practice: The 'orders of the day' query reads the whole table (easy, about 20 min).

9. "This lookup is slow, and we cannot stop writes to fix it"

Suspects: which index the plan actually uses, if any; whether one index can serve both the filter and the sort; how many rows are read to return one page. Then the second half of the question: how do you add the fix to a busy table? The docs say a normal CREATE INDEX lets reads continue, but inserts, updates and deletes "will block until the index build is finished," and they describe a slower way to build an index without blocking writes, with its own caveats (PostgreSQL docs). Practice: Support page for failed payments takes seconds (medium, about 40 min).

10. "Merge the duplicate accounts without losing anything"

This one is a data fix, not a query fix. Things to check: how the duplicates differ; every table that points at a customer, and what happens to those rows; conflicts between rows the accounts both own; a constraint so the duplicate cannot come back; and what happens if the migration fails halfway or runs twice. Practice: Merge duplicate customer accounts without losing anything (medium, about 45 min).

Questions interviewers ask after the fix

Have short answers ready for these:

• "How do you know it is right?" Name the one row you checked by hand, and the test that would fail without your fix.
• "What happens on a table 1,000 times bigger?" Say which part of the plan grows with the table.
• "What does your change lock, and for how long?" Especially for indexes, constraints and data migrations.
• "What about the rows that are already wrong?" A fixed query does not repair bad data that was written before.

Practice all ten on AICodingRound

You can read about NULLs and query plans, but these bugs only become familiar when you run the query, see the wrong row, and watch it change. That is what AICodingRound gives you. Each of the ten problems above runs on PostgreSQL 17 inside the workspace, with seed data and a test suite. You get psql in the terminal and a Database tab to run queries and view plans. The sample data is small, so the speed problems ask you to judge the work a query does through its plan, not its time on your machine.

Work each one with the method above: pin one wrong row, run the query in pieces, then fix. When you submit, tests run in a clean environment with its own database. They check the result, and a separate group checks that nothing else broke. Then a short debrief asks you to explain the cause and how you checked your fix, which is the part of a SQL interview most people never practice. The report gives a level per skill (Strong, Solid or Developing).

Bring your own Claude or Codex as a coach: it can read the code and explain a query, but it does not write the fix. Start with the five easy ones, then the medium ones. The beta is free and places are limited: get a place.

If the bug is in application code rather than the query, our guide to debugging interview practice has a general method.