How to explain your SQL out loud in an interview

What happens in a live SQL interview?

Many data analyst and data engineer interviews include a SQL round. It might be a shared editor with an interviewer watching, a screen share of your own editor, a whiteboard or paper, or a query you’re asked to read and explain. It usually lasts 20 to 45 minutes and covers a few problems of increasing difficulty: joins, grouping and filtering, then something like a ranking, a running total or a funnel. What each stage looks like, and how technical tests are set, is covered in Deeplink Coaching’s guide to data analyst technical tests and interviews.

In a live round, the interviewer can’t see your thinking unless you say it. Two candidates who write the same query can come out with very different marks: one talked through their reasoning, checked the result and spotted an edge case; the other typed in silence and said “done”.

What should you say before you write anything?

Spend the first minute or two on the question and the data. It feels slow, but it prevents the most common failure: a correct query for the wrong question.

1. Restate the question in your own words. “So you want the three customers who spent the most in the last quarter, counting only paid orders?”
2. Ask what one row means. “Is there one row per order, or one per item in an order?” This single question prevents most double counting.
3. Ask about the awkward cases. Missing values, cancelled or refunded rows, duplicates, time zones, and what to do with ties.
4. Say your plan in a sentence. “I’ll join orders to customers, keep paid orders in the quarter, total by customer and take the top three.”

If the interviewer says “make any reasonable assumption”, state the assumption out loud and move on. That’s what they want to hear.

How do you think aloud without rambling?

Narrate the why, not the keystrokes. “I’m typing SELECT” is noise. “I’m using a left join here because I want customers with no orders to appear with a zero” is evidence.

Useful phrases:

• “I’ll build this up in steps and check each one.”
• “I’m filtering before grouping, so cancelled orders don’t count.”
• “This needs HAVING rather than WHERE, because I’m filtering on the total.”
• “I’ll use a CTE so each step is readable.”
• “I’m not sure of the exact date function in this dialect. I want the first day of the month: I’ll write it like this and check.”

It’s fine to go quiet for a few seconds while you think. Say so: “Give me a moment to think about the join.”

A worked example

What earned the marks: the clarifying questions, choosing DENSE_RANK for a stated reason, predicting the row count, and investigating an odd result instead of hiding it. You can practise this exact task, with a real database in your browser, in the top two sellers challenge.

How do you check your query out loud?

Before you say you’re finished, run at least one check and say what you expected:

• Row counts before and after each join. A join that grows the count usually means a one-to-many you didn’t expect.
• A total you can predict. Does the sum of your groups equal the overall total?
• An edge case. A customer with no orders, a day with no sales, a null in the key.
• A sample by eye. Pick one row and follow it through.

Interviewers often have one trap built into the data, such as a duplicate or a null. Checking is how you find it before they point it out.

What if you get stuck or make a mistake?

Everyone does, and interviewers expect it. What they’re watching is how you respond.

• Say what’s wrong. “This count is too high. I think the join to order lines is multiplying rows.”
• Fix it one step at a time. Run the inner part on its own, then add pieces back.
• Ask for a hint if you’re truly stuck. “I’d normally look up the syntax for this. Is it all right if I describe what I want it to do?” Most interviewers will help, and asking well is a skill.
• Don’t go silent for minutes. Keep saying what you’re trying.

What about questions where you read or explain SQL?

Some rounds skip writing and ask you to explain a query, spot a bug or say why something is slow. Read it in the order the database runs it, not the order it’s written: FROM and joins first, then WHERE, GROUP BY, HAVING, SELECT, ORDER BY. Say what one row looks like after each stage. For slow queries, start with the obvious: how much data is being read, whether filters happen early, whether a join is exploding rows, and whether there’s an index or partition the query can use.

SQL ideas to explain without code

Interviewers often check understanding by asking you to explain an idea in words. Have a plain-English sentence and an everyday example ready for each of these:

Common mistakes

• Writing straight away. Two minutes of questions saves ten minutes of rewriting.
• Silent typing. The interviewer can’t mark reasoning they can’t hear.
• Narrating keystrokes. Say why, not what.
• Declaring victory without checking. “Done” with no check invites the trap.
• Hiding a mistake. Spotting and fixing your own error is a strength. Being caught is not.
• Arguing about dialect. If you know a different flavour of SQL, say so once and adapt.
• One enormous query. Build in steps with CTEs so both of you can follow it.

How should you practise?

Practise with the timer on and your voice on. Solve problems on realistic data, and say each step before you write it. Our SQL challenges run in your browser against a real database, with hidden tests that check the edge cases interviewers love, and each one comes with the follow-up questions an interviewer would ask. Then practise the spoken technical questions below, which ask you to explain SQL ideas without writing any.

Practice checklist

Work through these before the real interview. Each one is something you can do, not just read about.

• Solve five SQL challenges out loud, saying every step before you type it. Record one and listen back.
• For each, say what one row of each table means before writing any SQL.
• Practise one query where you check the row count before and after a join, and say what you expected.
• Explain an inner join versus a left join to a non-technical friend in under a minute.
• Deliberately make a mistake in a practice query, then practise noticing and fixing it out loud.
• Learn to explain a window function (RANK, ROW_NUMBER, a running total) without code, using an everyday example.
• Have a line ready for when you can’t remember syntax: say what you want the function to do, then carry on.

Questions to practise

Each has its own page with what it’s really asking and an example outline. Then practise it out loud, with thinking time and a timed answer.

• Explain the difference between an inner join and a left join, as if you were talking to a manager who doesn’t use SQL.SQL · 2 minutes to answer
• A query you wrote is running very slowly. What would you check first?SQL · 1 minute 30 seconds to answer
• Here’s a query: SELECT customers.name, COUNT(*) AS orders FROM customers LEFT JOIN orders ON orders.customer_id = customers.id GROUP BY customers.name. Tell me in plain English what it returns, and one way it could give the wrong answer.SQL · 2 minutes to answer
• Explain what a window function does, using a football league table as your example and no code at all.SQL · 2 minutes to answer
• An AI assistant writes you a SQL query that runs without errors and returns a plausible number. How would you check it before you use the result?SQL · 2 minutes to answer
• How would you test a SQL transformation before it goes into production?Data quality · 2 minutes to answer

Go further

• Data analyst interview questionsQuestions by role
• Data engineer interview questionsQuestions by role
• Technical questionsQuestion type guide
• Two-week SQL interview planStudy plan · 10 days
• Advanced SQL interview planStudy plan · 10 days
• SQL interview questionsCoding challenges
• Top three customers by spendSQL challenge · Easy
• Seats sold for every performanceSQL challenge · Easy
• Fix the on-time returns querySQL challenge · Easy
• Top two sellers in each shopSQL challenge · Medium
• The booking funnelSQL challenge · Hard

Written by the Deeplink Interview team and last reviewed 29 September 2026. The examples are invented to show the shape of a good answer: yours should come from your own experience, in your own words. This is general practice advice, not linked to any employer, and not a prediction of any hiring decision. How we write these guides.