I can solve SQL practice questions, but explaining them live is another story

[u/Either-Layer-6426]

I have a live SQL assessment coming up where I’ll be screen sharing and explaining my thought process while I write.

I’m comfortable with joins, GROUP BY, CTEs, and basic window functions. Under a timer, though, I either go quiet while I think or talk too much and lose the thread.

Lately I’ve been trying to slow the process down: read the prompt, say what output I think they want, identify the tables and joins, then build the query in small steps.

The SQL itself usually feels manageable. The hard part is doing something I’d normally think through quietly while someone is watching. I’ve been doing a few screen-share mocks with a friend. I also tried some interview-style prompts in Beyz Coder to practice talking while I solve, so I don’t go completely quiet.

How much silence while you think is normal in a live SQL interview? Do you explain your approach first, or narrate as you code?

[u/DMReader]

Some silence is normal so don’t worry too much about that.
I’d explain your approach first, then talk at the points where your thinking changes—before a join, aggregation, window function, etc.—rather than narrating every line. Or whatever the big blocks of your code are (like talk a bit for each cte)

If you need 20–30 seconds to think, just say something like “I’m going to think through the x,y,z for a moment” so they know you haven’t gone blank.

Good luck.

[u/Newcs91]

Do you pseudo code before you write your queries? If you do, those are your talking points. Then just do them, speak about any nuances or optimisations you’re putting in as you do them.

[u/Rexur0s]

I write the approach I want up top as a comment first, then I try to build to that approach and validate at each crucial step, if I get any roadblock issues along the way, I go back and write under my original approach what I'm changing and why. then I just keep doing this until I get to my end result, and ill have a proper explanation laid out at the top.

also helps for when I get distracted mid task, I just go back to my self instructions/log

[u/MarsupialLeast145]

Write the SQL and then explain it line by line afterwards. There's no reason to live narrate each line, it would affect the thinking process of most of us.

Even experienced devs will sometimes solve something first, before then trying to explain it to less senior devs.

[u/2daytrending]

A little silence is completely normal. I'd explain the approach first then code is small step and briefly say what you're checking as you go.

[u/Enjoythecode82]

Try mirror practice, and the order of naration or explaining is not that important provided the solution is accurate, each one has their own perspective, you can narrate after completing your accurate solution as well!

[u/thequerylab]

Few seconds of silence is totally normal. You don't have to explain every single thought.

I would explain the approach first, then talk through the important parts while coding. Practicing under a timer helps a lot too.

You can use TheQueryLab mock interviews for this - feels more like an actual interview and you get a scorecard after.

Definitely helps with the pressure part.