Hey - Tom here.

Sooner or later, if you want to work in data, you'll need to take part in a SQL technical interview.

Weirdly, most candidates turn up underprepared for what actually gets tested.

This style of interview isn't just testing if you can write SQL - it's testing how you think through problems, communicate your approach, and handle ambiguity under pressure.

Today, I'm breaking down exactly what happens in these interviews, based on what I've seen from both sides of the table.

Here's what we're covering this week:

• The three-part structure (pretty much) every SQL technical interview follows
• What interviewers are really looking for
• The questions you should ask
• How to communicate your thinking process effectively

Let's get into it...

It a nutshell: It's not a syntax test

Most candidates prepare by memorising SQL functions and practising LeetCode-style problems.

That's not what gets you hired.

SQL interviews test three things:

1. Problem decomposition - Can you break a vague business question into logical steps?
2. Technical execution - Can you write clean, efficient SQL that actually works?
3. Communication - Can you explain your approach clearly while you work?

The interview usually follows a predictable structure, and knowing this gives you a massive advantage.

Part 1: The Warm-Up (5-10 minutes)

This is where they ease you in with basic queries to check you actually know SQL.

Typical questions:

• "Show me all customers who placed an order in the last 30 days"
• "Calculate total revenue by product category"
• "Find duplicate records in this table"

What they're really checking:

Can you write clean SELECT statements? Do you understand basic aggregations and GROUP BY? Can you filter data correctly with WHERE vs HAVING?

The trap: Rushing. Most candidates try to write the full query immediately and make silly mistakes.

Better approach: Ask any clarifying questions (Does the table have NULLs, clean columns etc) and talk through your logic first. "I need to filter the orders table by date, then aggregate by customer. I'll use WHERE for the date filter since it's on individual rows, not aggregated data."

When interviewing for roles myself, I like to ask: 

"How does that sound" at the end.

Gives your interviewer a chance to ask any questions, maybe correct you if you're slightly off.

Part 2: The Meat (20-30 minutes)

This is where they give you a business problem that requires multi-step thinking.

Example scenario:

"We have a subscriptions table showing user sign-ups and cancellations. Calculate monthly retention rate - the percentage of users from the previous month who are still active."

Why this is hard:

It's not immediately obvious what SQL constructs you need. You need to figure out:

• How to define "active" in a given month
• How to compare month-over-month data
• Whether you need window functions, self-joins, or CTEs

What strong candidates do:

They break it down out loud. "First, I need to identify active users per month. Then I need to compare each month to the previous month. I'll probably use LAG() or a self-join to get previous month's data, then calculate the ratio."

What weak candidates do:

They immediately start writing SQL, get stuck halfway through, and can't explain why their approach isn't working.

Part 3: Cleaning up your work (10-15 minutes)

Once you've solved the problem, they might ask: "How would this perform on a table with 100 million rows?"

What they want to hear:

• Recognition of potential bottlenecks (table scans, expensive joins)
• Understanding of indexing strategies
• Awareness of when to use summary tables or materialised views
• Practical trade-offs between query complexity and performance

What they don't want:

Vague answers like "I'd add an index." Where? On which columns? Why would that help?

Better answer: "This query has to scan the full orders table for each date range calculation. I'd add a composite index on (user_id, order_date) since we're filtering and joining on those columns. Alternatively, if this query runs frequently, we could maintain a daily summary table to avoid recalculating everything."

This is where going beyond syntax is so important.

You need to know what goes on under the hood and the best way to manipulate it for efficient data work.

Good Questions to Ask Your Interviewer

Most candidates waste the "Do you have any questions for us?" section with generic rubbish.

Don't ask:

• "What's the company culture like?" (Too vague)
• "What technologies do you use?" (You should already know this)
• "What does a typical day look like?" (Surface-level)

These questions do nothing to help you evaluate the role or demonstrate your expertise.

Ask questions that reveal how the team actually works and whether you'd thrive there.

Questions About the Data Environment

"What's the current state of your data infrastructure? Are you migrating to a new warehouse, or is the stack relatively stable?"

Why this works: Shows you understand that technical decisions happen in context. A team mid-migration has different priorities than one with stable infrastructure.

"How do you handle data quality issues and who owns the data? Do you have automated testing, or is it more ad-hoc?"

Why this works: Data quality and ownership problems are universal. Their answer tells you whether they've invested in processes or if you'll spend your time firefighting.

A red flag for you by the way.

Questions About Team Dynamics

"Who are the main stakeholders you support, and how do they typically request analysis?"

Why this works: Tells you whether requests come in structured or chaotic, and whether stakeholders understand data or need heavy education.

Another good one similar to this is:

"Who prioritises the work and has the final say?"

Does your manager give you responsibility to handle your own workload, or do they give you work. And if they do, do they have your back when it comes to pushing back on workloads?

Questions About Growth and Impact

"What's a recent project where [DATA WORK] directly influenced a business decision?"

Why this works: Shows whether your work will matter or just sit in dashboards nobody checks. Also reveals how connected the data team is to actual decision-making.

"What would success look like for this role in the first six months?"

Why this works: Forces them to articulate expectations clearly. Vague answers are a red flag.

The Strategic Question

Always end with one question that positions you as someone who thinks strategically:

"What's the biggest data challenge the team is facing right now, and how does this role help solve it?"

Why this works: Shows you're thinking about problems, not just tasks. Their answer also tells you what you'd actually be working on, not the polished job description version.

The key: Ask questions that reveal information you can't get from the job posting or company website. Make them think, and you'll stand out.

How to Actually Prepare

When you work through practice problems:

1. Read the question and state your approach out loud before writing code (I also like writing things down on paper so I can tick them off)
2. Identify what data you need before deciding which SQL functions to use
3. Write your query in stages (start simple, then add complexity)
4. Test your logic with small examples before running the full query

Start with a foundation and build up.

Even a simple SELECT [fields] is a good start to get a feel for the data and explore it.

TL;DR:

• SQL interviews test problem-solving, not just syntax - they want to see how you think through ambiguous business questions
• The three-part structure is predictable - warm-up queries, complex business problem, optimisation discussion
• Ask strategic questions that reveal how the team operates - data quality processes, stakeholder dynamics, and real project impact
• Communication matters as much as code - explain your approach before and while you write
• Prepare by practising decomposition - break problems into steps before writing any SQL

The difference between knowing SQL and confidently handling interview questions? Practice with realistic scenarios.

This week, inside Premium you'll get:

• The Interview Mistakes Guide - specific errors that derail candidates, plus what strong answers actually sound like
• Strategic Questions to Ask - questions that reveal how the team works (and whether you'd want the job)
• Problem Decomposition Framework - my systematic approach for breaking down SQL problems, with three complete walkthroughs showing exactly how I think through each step
• SQL Interview Practice - local database setup with realistic business scenarios you can practice against

Everything you need to walk into that interview prepared, not just hoping you'll figure it out on the spot.

Click upgrade below to get instant access to this week's resources plus the full archive.