DEV Community: Simran Singh

SQL Interview Rounds: What to Expect and How to Prepare

Simran Singh — Thu, 22 Oct 2026 05:53:43 +0000

SQL rounds appear in data analyst, data engineer, backend and product analyst interviews. They are usually more predictable than candidates expect.

Common question types

Joins across two or three tables, including LEFT JOIN edge cases with NULLs
GROUP BY with HAVING
Window functions: ROW_NUMBER, RANK, running totals, LAG/LEAD
Finding duplicates or the Nth highest value
Date handling: month-over-month, retention and cohort queries

How to prepare

Practise writing queries in a plain editor, without autocomplete.
Say your approach out loud before you write: which tables, which join, which grain.
Always check edge cases: empty tables, NULLs, ties.
Review your practice sessions. A recap of what you were asked and how you answered (for example from ClapAssist, which has a technical/SQL mode) shows you which patterns you keep getting wrong.

On the day

Clarify the schema first, state your assumptions and write readable SQL with clear aliases. Interviewers value clarity over clever one-liners.

Meeting Notes That Actually Lead to Action

Simran Singh — Thu, 22 Oct 2026 05:47:53 +0000

Most teams take meeting notes. Few teams use them. The difference is structure.

Capture three things only

Decisions: what was agreed, in one sentence each.
Actions: who does what by when.
Open questions: what still needs an answer and who owns it.

Skip the play-by-play of who said what. Nobody rereads it.

Send the recap within an hour

A recap sent the same day gets read. A recap sent two days later is ignored. Keep it short enough to read on a phone.

Review actions at the start of the next meeting

Spend the first three minutes checking last meeting's actions. This one habit makes people take action items seriously.

Let tools do the typing

AI note-takers and assistants such as ClapAssist can produce a session recap automatically, which frees you to listen and contribute. Just make sure a human checks the decisions and owners before it goes out.

Good notes are not about recording everything. They are about making sure the meeting changes something.

Why I Practice Coding Interviews Out Loud

Simran Singh — Thu, 22 Oct 2026 05:25:16 +0000

For a long time I prepared for coding interviews by solving problems silently. I could solve medium problems on my own, then froze in real interviews. The problem was not the algorithms. It was talking while thinking.

Silent practice hides the real skill

In a live coding round, the interviewer is grading your communication as much as your code. They want to hear you clarify the problem, propose a brute-force approach, explain why it is slow and then improve it. If you have never practised narrating, the first time you do it is under pressure.

My routine now

Read the problem aloud and restate it in my own words.
Ask two clarifying questions, even if I think I know the answer (input size, edge cases, duplicates).
Say the brute force first and its complexity.
Talk through the optimisation before writing a line of code.
Code while narrating what each block does.
Test with one normal case and one edge case out loud.

I set a 35-minute timer for each problem.

Reviewing the session

After each run I review what I actually said. I started using ClapAssist for this, since it has a coding mode and gives a recap of the session, but a simple screen recording works too. The goal is to catch habits like going silent for two minutes or skipping complexity analysis.

What changed

Within three weeks my mock interview feedback shifted from "good solution, hard to follow" to "clear communicator." Same algorithms, very different result.

If you are grinding problems but struggling in real rounds, try practising out loud for a week. It is uncomfortable at first and then it becomes your biggest advantage.

5 Interview Mistakes You Only Notice When You Review the Recap

Simran Singh — Mon, 19 Oct 2026 09:26:20 +0000

Most of us prepare for interviews the same way: read a list of common questions, write a few answers, and hope they come out right on the day.

The problem is that you never find out how they actually came out. The call ends, you feel "okay-ish", and a week later you get a rejection with no feedback.

A simple habit fixes this. After every interview and mock interview, write down three things:

What was I asked?
What did I actually say?
What should I have said?

Do this a few times and the same mistakes start showing up. Here are the five most common ones, plus fixes that work.

1. Giving the result last

Behavioral questions like "Tell me about a time you missed a deadline" have a natural story order: situation, what I did, what happened. The trouble is that interviewers stop listening halfway through the setup.

Fix: say the result first, in one line. "We shipped two days late, but the client renewed, and here's how." Then tell the story. The interviewer now knows where you're going and listens for the how.

2. Drawing boxes before saying numbers

In system design rounds ("Design a URL shortener"), many candidates jump straight to drawing a load balancer, app servers and a database.

Interviewers want to hear the scale first: how many reads, how many writes, how much storage per year. Without numbers, every box looks like a guess.

Fix: spend the first two minutes on scale and say the numbers out loud. Reads per second, writes per second, storage. Then design.

3. Answering the question you prepared, not the one asked

When a question sounds like one you've practiced, it's tempting to play back the prepared answer, even when the follow-up is slightly different. "Why do you want to leave your job?" is not the same as "What would make you stay?"

Fix: repeat the question back in your own words before answering. It buys you three seconds and forces you to listen.

4. A "Tell me about yourself" that runs for three minutes

More detail feels more impressive. In reality the interviewer wants a 60-second map: who you are now, the one or two things you're best at, and why this role.

Fix: write it, time it, cut it to under a minute. Present, past highlight, why this job.

5. No good question at the end

"Do you have any questions for us?" Answering "No, I think you covered everything" is a missed chance.

Fix: keep two real questions ready. "What does the first 90 days look like for this role?" and "How does the team handle on-call / deadlines?" both work.

How to build this habit without a lot of effort

Writing these notes by hand after every call is tiring, and you forget half of what was said within an hour. A few ways to make it easier:

Record your mock interviews (with permission) and listen back at 1.5x speed.
Use a simple template: three columns, asked / said / should have said.
Use a tool that does the recap for you. Disclosure: I work on ClapAssist, a desktop app for Mac and Windows built for exactly this. It has a practice mode, and after each session it gives a recap: what you were asked, how you answered, and what to fix before the next round. It also works for regular work meetings and client calls, which is handy when you want notes without typing during the call.

Whatever method you pick, the important part is closing the loop. An interview you don't review is practice you threw away.

A simple pre-interview checklist

[ ] 60-second "tell me about yourself", timed
[ ] 3 behavioral stories, each with the result in the first line
[ ] For system design: say scale numbers before drawing
[ ] Repeat each question before answering
[ ] 2 questions ready for the end
[ ] After the call: asked / said / should have said

Try this for your next three interviews and see which mistake shows up most for you. Share it in the comments.