It doesn't. It returns the top salary again. And that small gap, the difference between writing SQL that runs and writing SQL that's right, is what most SQL interview rounds are actually testing. Nobody on the other side of the table cares whether you've memorised the syntax for LATERAL. They care whether you think about duplicates, NULLs, and what the query does on the 10-million-row table instead of the 12-row example.

Here are the nine questions I've seen come up most, plus what a strong answer sounds like.

1. Find the second-highest salary

The fix for the story above is to stop thinking in rows and start thinking in distinct values:

SELECT MAX(salary)
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

Or, more generally, with a window function:

SELECT salary
FROM (
  SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
  FROM employees
) t
WHERE rnk = 2
LIMIT 1;

What the interviewer wants to hear is why you picked DENSE_RANK and not ROW_NUMBER. Then say, unprompted, what happens if there's no second salary: the first query returns NULL, the second returns no rows. Mentioning that tells them you've been burned by an empty result set feeding a dashboard before.

2. ROW_NUMBER vs RANK vs DENSE_RANK

The weak answer lists definitions. The strong answer uses one dataset to show all three. Salaries of 100, 100, 90 give:

• ROW_NUMBER: 1, 2, 3 (arbitrary tie-break, so it's not deterministic unless you add a tiebreaker column)
• RANK: 1, 1, 3 (it skips)
• DENSE_RANK: 1, 1, 2 (no gaps)

The follow-up almost always goes: "When would you use ROW_NUMBER?" The answer that lands is deduplication. You keep the latest record per customer with ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY updated_at DESC) = 1. That's a real, everyday use, and it shows you've cleaned real data.

3. WHERE vs HAVING

Everyone knows HAVING filters after grouping. Fewer people can explain the order of logical evaluation: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT. That order is also why you can't use a SELECT alias inside WHERE in most databases.

Here's the practical point that separates people: push every filter you can into WHERE. Filtering 5 million rows down to 50,000 before aggregation is cheaper than aggregating everything and throwing groups away in HAVING. If you say that, you've shown you think about cost, not just correctness.

4. Explain the JOIN types, and the NULL trap in LEFT JOIN

Inner, left, right and full outer are table stakes. The question is really a setup for this bug:

SELECT c.id, o.id
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'paid';

That WHERE clause silently turns the left join into an inner join, because customers with no orders have o.status = NULL, and NULL = 'paid' isn't true. If you meant "all customers, plus their paid orders", the condition belongs in the ON clause. I've seen this exact bug under-report a churn metric for a month in production. Candidates who spot it without a hint almost always get a strong signal.

5. How does NULL behave in comparisons and aggregates?

Short version: NULL means unknown, so NULL = NULL is not true, and you need IS NULL. COUNT(*) counts rows, but COUNT(column) skips NULLs. AVG ignores NULLs too, which means the average of 10, NULL, 20 is 15, not 10.

The trap to mention is NOT IN with a subquery that contains a NULL. It returns no rows at all. NOT EXISTS doesn't have that problem, which is one reason many teams default to it. This is the kind of answer that shows you've debugged a query that "should" return data and didn't.

6. What's an index, and when does it not help?

Most candidates can say "a B-tree that speeds up lookups." The interesting half of the answer is when an index gets ignored:

• A function on the column: WHERE LOWER(email) = ... won't use a plain index on email (you'd need an expression index)
• A leading wildcard: LIKE '%gmail.com'
• Low-selectivity columns, where scanning the table is cheaper anyway
• Composite indexes queried without the leftmost column: an index on (country, city) helps WHERE country = 'IN' but not WHERE city = 'Pune'

Then add the cost side: every index slows down writes and takes storage. My one mild disagreement with common advice goes here. "Index every column you filter on" is bad advice for write-heavy tables. I've seen an insert-heavy events table get noticeably faster after we dropped four indexes nobody was reading from.

7. Read this query plan

More interviews now paste in an EXPLAIN ANALYZE output and ask what's wrong. You don't need to know every node type. Look for three things:

1. A Seq Scan on a big table where you expected an index scan
2. A big gap between estimated rows and actual rows, which usually means stale statistics (run ANALYZE)
3. A nested loop joining two large sets, where a hash join would be expected

Just say "I'd check whether the row estimates match the actuals first." That tells them you've read real plans, not just tutorials.

8. Transactions and isolation levels

Explain ACID briefly, then get concrete about isolation, because that's where the real questions live. Name the anomalies (dirty reads, non-repeatable reads, phantom reads) and which isolation level prevents which. Be ready for the PostgreSQL detail: its default is Read Committed, and its Repeatable Read is implemented with snapshots, so it also prevents phantoms in practice.

The follow-up is usually a scenario. Two requests withdraw from the same account at the same time: how do you stop the balance going negative? Good answers are SELECT ... FOR UPDATE, a conditional update like UPDATE accounts SET balance = balance - 50 WHERE id = 1 AND balance >= 50 (then check rows affected), or serializable isolation with a retry. Offering the conditional update first shows pragmatism.

9. Write a running total and a 7-day moving average

This one is the window-function capstone:

SELECT
  order_date,
  daily_revenue,
  SUM(daily_revenue) OVER (ORDER BY order_date) AS running_total,
  AVG(daily_revenue) OVER (
    ORDER BY order_date
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS moving_avg_7d
FROM daily_sales;

The detail that impresses is the gap problem. ROWS BETWEEN 6 PRECEDING means seven rows, not seven days. If there are missing dates, your "7-day" average quietly covers ten days. Mention generating a date series and left-joining onto it (or using RANGE with an interval where your database supports it). Almost nobody brings this up without being asked.

What actually goes wrong in the live round

The candidates I've watched struggle usually know this material. What happens is that they freeze when they're writing SQL in a shared editor while someone watches every keystroke, and the NULL edge case they'd catch at their desk just doesn't come to mind. Two things help. First, narrate your assumptions out loud ("I'm assuming salary can't be NULL. Should I handle that?"). Second, practise under the same pressure you'll face on the day. Some people now also keep a real-time assistant such as LastRound AI's interview copilot running as a safety net for the moments when a detail like DENSE_RANK vs RANK slips mid-sentence. Whether you use one or not, the fix is the same: rehearse the edge cases until you mention them without being asked.

One honest caveat. Everything above leans toward PostgreSQL behaviour. MySQL, SQL Server and Snowflake differ in the details (default isolation levels, LIMIT vs TOP, how NULLs sort), so ask which engine the team uses before you commit to syntax. That question alone scores points.