What a Blank Stare During a SQL Question Really Means

SECOND-HIGHEST SALARY — READ AS AN
INTERVIEWER:

Interviewer: "Find the second-highest salary
in the employees table."

Candidate: [blank stare — 5s, 10s]

What the candidate is thinking:
- "It's MAX... with a subquery... WHERE
  salary < MAX(salary)..."
- "Or is it LIMIT 1 OFFSET 1 with ORDER BY
  DESC? But what about ties?"
- "The syntax isn't coming."
- "If I get this wrong, they'll think I
  don't know SQL."

What the interviewer thinks:
- "They've used SQL for 3 years and can't
  answer this?"
- "This is a reasoning question, not a
  syntax question."
- "I'll move on and score SQL low."

What the stare reveals:
❌ They memorized the query, not the
  reasoning
❌ They can't reason from the table
❌ The freeze is retrieval, not knowledge
❌ A blank stare is a lack of a fallback

The fix — reason from the table:
"First, I'd find the highest salary.
Then, I'd find the highest salary that's
strictly less than that. That's the
second-highest. In SQL:
SELECT MAX(salary) FROM employees
WHERE salary < (SELECT MAX(salary) FROM
employees);

Or, with a window function:
SELECT salary FROM (
  SELECT salary, DENSE_RANK() OVER (
    ORDER BY salary DESC) AS r
  FROM employees
) t WHERE r = 2;

The first handles ties by returning the
second distinct value. The second handles
ties explicitly. I'd ask which the team
wants."

Why it works:
✅ Reasoning from the table, not the
  memorized query
✅ Two approaches with a trade-off
✅ Handles ties explicitly
✅ The freeze is replaced by reasoning

TOP N PER GROUP — READ AS AN INTERVIEWER:

Interviewer: "Find the top 2 salaries per
department."

Candidate: [blank stare — 5s, 10s, 15s]

What the candidate is thinking:
- "It's ROW_NUMBER() OVER (PARTITION BY
  department ORDER BY salary DESC)..."
- "Or is it RANK? DENSE_RANK? I always mix
  those up."
- "I know the concept, but the syntax is
  fuzzy."

What the interviewer thinks:
- "They know the concept but can't write
  it."
- "This is a syntax question, not a
  reasoning question."
- "I'll guide them: 'what if you ranked
  the rows?'"

What the stare reveals:
❌ The concept is known, the syntax isn't
❌ The freeze is recall, not logic
❌ No fallback approach
❌ The candidate needs more practice

The fix — reason from the concept:
"I'd rank salaries within each department,
then filter to the top 2. In SQL:
SELECT department, salary FROM (
  SELECT department, salary,
    DENSE_RANK() OVER (
      PARTITION BY department
      ORDER BY salary DESC) AS r
  FROM employees
) t WHERE r <= 2;

DENSE_RANK handles ties: two people tied
for first both get r=1, and the next
distinct salary gets r=2. RANK would skip
to 3, which might drop a person. So
DENSE_RANK is the right choice for
'second-highest' semantics.

If the team wanted exactly 2 rows per
department regardless of ties, I'd use
ROW_NUMBER with a tiebreaker."

Why it works:
✅ Reasoning: rank → filter → top 2
✅ The syntax is explained, not memorized
✅ The difference between RANK, DENSE_RANK,
  and ROW_NUMBER is named
✅ The tie behavior is explained
✅ The freeze is replaced by reasoning

QUERY MEMORY — READ AS AN INTERVIEWER:

Candidate: "I know the second-highest salary
query. It's the MAX with a subquery."

Interviewer: "What if there are ties for
the highest salary?"

Candidate: [blank stare] "I'd have to
modify it. Maybe DISTINCT somewhere?"

What I notice:
- The candidate has the query memorized.
- They freeze on the tie variant, which is
  a small change.
- They can't reason about what the query
  returns when the data changes.

What it reveals:
❌ The knowledge is a block, not a model
❌ Small changes break the answer
❌ They can't debug a query that returns
  unexpected rows
❌ This is query memory, not SQL reasoning

The fix — reason about the data:
"With ties, 'second-highest' is ambiguous.
It could mean the second-highest distinct
value, or the second row in order. If it's
distinct, I'd use DENSE_RANK and filter
r = 2. If it's the second row, I'd use
ROW_NUMBER with a tiebreaker. The right
answer depends on what the business means
by 'second-highest.'"

Why it works:
✅ The ambiguity is named
✅ Two semantics, two solutions
✅ The business question is asked
✅ The freeze is replaced by reasoning

SYNTAX OVER SEMANTICS — READ AS AN
INTERVIEWER:

Candidate: "Is it RANK or ROW_NUMBER? I
always mix those up."

Interviewer: "What's the difference?"

Candidate: [blank stare] "One of them
skips numbers when there are ties?"

What I notice:
- The candidate is focused on which
  function to pick.
- They can't explain the difference in
  semantics.
- They're guessing at the syntax instead
  of reasoning about the result.

What it reveals:
❌ The focus is syntax, not semantics
❌ They can't reason about tie behavior
❌ They'd ship a query that returns the
  wrong rows
❌ This is a lookup gap, not a reasoning
  gap

The fix — reason about the rows:
"RANK skips numbers on ties: two people
tied for 1st both get 1, and the next gets
3. DENSE_RANK doesn't skip: the next gets
2. ROW_NUMBER gives each row a unique
number, even on ties, so the order among
ties is arbitrary unless you add a
tiebreaker.

So for 'second-highest distinct salary', I'd
use DENSE_RANK. For 'exactly two rows per
department', I'd use ROW_NUMBER. The
semantics decide, not the syntax."

Why it works:
✅ The semantics of each function is
  explained
✅ The tie behavior is named
✅ The choice depends on the requirement
✅ The freeze is replaced by semantics

FULL RECOVERY — THREE STEPS IN 30 SECONDS:

Interviewer: "Find the second-highest
salary."

WHAT YOU SAY:
"Sure. Let me restate the question: I need
the second-highest distinct salary, and I
should handle ties.

I'll reason about the rows first. I'd rank
salaries from highest to lowest, then pick
the rank that equals 2. In SQL, that's
DENSE_RANK() OVER (ORDER BY salary DESC),
then filter r = 2.

The tie behavior matters. DENSE_RANK doesn't
skip numbers on ties — two people tied for
1st both get 1, and the next distinct salary
gets 2. If the team meant the second row
regardless of ties, I'd use ROW_NUMBER with
a tiebreaker.

I'd also consider an alternative: SELECT MAX
(salary) WHERE salary < (SELECT MAX(salary)).
That's simpler but doesn't generalize to
'third-highest.' The window function
generalizes.

Let me write the DENSE_RANK version — does
that match what you meant?"

What the interviewer thinks:
- "They restated the question." ✅
- "They reasoned about the rows." ✅
- "They named the tie behavior." ✅
- "They offered two approaches." ✅
- "They asked for clarification." ✅
Signal: recovered. Strong hire.

Why it works:
✅ Restate: second-highest distinct, handle
  ties
✅ Reason: rank → filter
✅ Trade-off: DENSE_RANK vs. ROW_NUMBER,
  window vs. MAX subquery
✅ Collaboration: "does that match what you
  meant?"

WHEN YOU FORGET SYNTAX — STILL RECOVER:

Interviewer: "Write a query to find
customers who never ordered."

Candidate: "I know the pattern is a LEFT
JOIN with a NULL check, or a NOT EXISTS.
Let me reason through it and I'll write the
JOIN version — I might need to check the
exact syntax.

The result set I need: customers with no
matching rows in orders. So I'd start from
customers, LEFT JOIN orders on customer_id,
and keep rows where the order's id is NULL.
That's the LEFT JOIN pattern.

In SQL:
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

The alternative is NOT EXISTS:
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
);

Both return the same rows. NOT EXISTS is
often faster on large tables because it
stops at the first match. LEFT JOIN is
often clearer to read.

I'll write the LEFT JOIN version. Let me
know if you'd prefer NOT EXISTS."

What the interviewer thinks:
- "They named the pattern." ✅
- "They reasoned about the result set." ✅
- "They offered two valid solutions." ✅
- "They named the performance trade-off." ✅
- "They wrote the query." ✅
Signal: recovered. Strong hire.

Why it works:
✅ Pattern: LEFT JOIN vs. NOT EXISTS
✅ Result set: customers with no matching
  orders
✅ Two solutions, same result
✅ Performance trade-off
✅ The syntax follows the reasoning

SQL Reasoning Checklist:

FOR EVERY QUERY:
☐ Result set: describe the rows in plain
  English
☐ Rows needed: what columns, what filters
☐ Grouping: what am I grouping by?
☐ Ranking: do I need a window function?
☐ Edge cases: ties, nulls, duplicates
☐ Trade-offs: which approach is faster
  or clearer?

FUNCTIONS TO EXPLAIN:
☐ RANK: skips numbers on ties
☐ DENSE_RANK: doesn't skip on ties
☐ ROW_NUMBER: unique per row, arbitrary
  on ties
☐ INNER JOIN: matching rows only
☐ LEFT JOIN: all left rows, NULLs for
  no match
☐ EXISTS: stops at first match
☐ IN: can be slower on large lists

PATTERNS TO WRITE TWO WAYS:
☐ Second-highest salary: MAX subquery
  vs. DENSE_RANK
☐ Top-N per group: DENSE_RANK vs. ROW_NUMBER
  with tiebreaker
☐ Never ordered: LEFT JOIN vs. NOT EXISTS
☐ Duplicate rows: GROUP BY HAVING COUNT > 1
  vs. window function

RED FLAGS IN YOUR OWN ANSWERS:
❌ "I memorized the query" with no reasoning
❌ "I think it's RANK" with no semantics
❌ No edge case named
❌ No trade-off
❌ The syntax comes before the result set

THE REASONING TEST:
For each question, ask yourself:
1. "What rows do I need?" — can you describe
   them in plain English?
2. "What's the edge case?" — ties, nulls,
   duplicates?
3. "What's the trade-off?" — which approach
   is faster or clearer?

If any answer is no, that's the pattern to
practice before the interview.

30-DAY SQL REASONING PLAN:

Week 1 — Result sets
☐ For 10 classic queries, write the result
  set in plain English first
☐ Then write the SQL
☐ Practice out loud: "I need rows where..."
☐ Record and listen for syntax-first
  answers

Week 2 — Functions and semantics
☐ Write the difference between RANK,
  DENSE_RANK, ROW_NUMBER
☐ Write the difference between INNER,
  LEFT, FULL JOIN
☐ Write the difference between EXISTS, IN,
  JOIN
☐ Practice each with a sample table

Week 3 — Patterns, two ways
☐ Second-highest salary: MAX subquery and
  DENSE_RANK
☐ Top-N per group: DENSE_RANK and
  ROW_NUMBER
☐ Never ordered: LEFT JOIN and NOT EXISTS
☐ Duplicates: GROUP BY HAVING and window
  function
☐ Practice each in under 60 seconds

Week 4 — Mock interviews
☐ Have a peer ask 5 SQL questions
☐ Use the recovery framework: restate,
  reason, trade-off
☐ If you pause, that's the pattern to
  practice
☐ Re-run the mock until no pauses

Signs it's working:
✅ You describe the result set before the
  syntax
✅ You name the edge case without being
  asked
✅ You offer two approaches with a
  trade-off
✅ You never say "I memorized the query"
✅ The interviewer asks "tell me more"
  instead of "let's move on"