SQL Interview Patterns — Top 10 Question Types

The 10 SQL question patterns that show up in 80% of analytics interviews. Learn the pattern, not the question. FIND_VIDEO: search 'top 10 SQL interview questions data analyst' — recommended channel: Data With Mo / Strata Scratch. Keep it under 12 min.

25 minutesVideo LessonPDF notes

Watch SQL Interview Patterns — Top 10 Question Types on YouTube

🎯 Free Guest Mode: You are learning for free. Sign in to save your completion progress and quiz answers.

Ready to continue?

Mark this lesson as complete when you're ready to proceed.

Key moments

Introduction & Categorization — Outlines SQL interview formats, splitting questions into theoretical approach and practical technical execution.
Duplicate Detection Patterns — Demonstrates methods to identify duplicate data using distinct row counts and grouped frequency counts.
Table Reconciliation Techniques — Explains how to reconcile disparate tables and identify mismatched records using full outer joins and CASE statements.
Debugging Faulty Query Results — Details structured troubleshooting approaches for isolating join explosions and validating business logic.
Describing Complex SQL Projects — Shares strategies for articulating complex stored procedures and aligning technical narratives with resume bullet points.
WHERE versus HAVING Filtering — Contrasts pre-aggregation row filtering using WHERE against post-aggregation group filtering using HAVING.
COALESCE Fallback Handling — Explains the COALESCE function for selecting the first non-null value across multiple prioritized columns.

PDF notes

Bottom line: You will master essential SQL interview patterns across technical execution and behavioral problem-solving. You will be able to detect duplicates, reconcile mismatched datasets using full outer joins, filter granular versus aggregated records, and systematically debug queries that run without syntax errors but return invalid data.

This lesson on SQL Interview Patterns — Top 10 Question Types is hands-on and example-driven. You will master essential SQL interview patterns across technical execution and behavioral problem-solving. You will be able to detect duplicates, reconcile mismatched datasets using full outer joins, filter granular versus aggregated records, and systematically debug queries that run without syntax errors but return invalid data.

What You'll Be Able To Do

Identify duplicate records using aggregate row counts versus distinct counts and GROUP BY clauses
Compare two staging or production tables to detect missing rows using a FULL OUTER JOIN and CASE statements
Differentiate row-level filtering with WHERE clauses from post-aggregation filtering with HAVING clauses
Replace nested conditional checks with the COALESCE function to retrieve the first non-null value
Structure behavioral and troubleshooting interview responses for query debugging and complex data modeling projects

Detailed Concept Walkthrough

1. Duplicate Detection Patterns

Detecting duplicates requires comparing total volume against unique identifiers or grouping data to evaluate frequencies.

Mechanism: Compare total table volume against unique values by running COUNT(*) alongside COUNT(DISTINCT Column) in a single scan.
Granular Analysis: Group the table by the target business keys (e.g., ProductID, customer ID) and compute COUNT(*) per group to isolate exact duplicate entities.
Under the Hood: A discrepancy between total row count and distinct column count immediately confirms repeated values across rows without needing complex joins.

-- Quick sanity check for column-level duplication
SELECT 
    COUNT(*) AS total_rows,
    COUNT(DISTINCT ProductID) AS distinct_products
FROM dbo.Shipments;

-- Isolating specific duplicated keys
SELECT 
    ProductID, 
    COUNT(*) AS occurrence_count
FROM dbo.Shipments
GROUP BY ProductID
HAVING COUNT(*) > 1;

Key Takeaway: Compare COUNT(*) against COUNT(DISTINCT col) for global duplication, then use GROUP BY with HAVING to locate specific repeated keys.

2. Table Reconciliation via Full Joins

Reconciling two datasets (e.g., weekly batches or ETL stages) identifies unmatched records on either side using set intersections and differences.

Mechanism: Perform a FULL OUTER JOIN on shared composite keys across two tables to retain all matching and non-matching records from both sides.
Classification Logic: Apply a CASE expression checking for NULL values on the joined keys to classify each row as 'Table 1 only', 'Table 2 only', or 'Both tables'.
Best Practice: Join on all relevant granular keys (such as ProductID and SalesPersonID) to prevent unintended Cartesian product expansion during reconciliation.

-- Compare Week 1 and Week 2 sales datasets
SELECT 
    w1.ProductID AS W1_ProductID,
    w2.ProductID AS W2_ProductID,
    w1.SalesPersonID AS W1_SPID,
    w2.SalesPersonID AS W2_SPID,
    CASE 
        WHEN w1.ProductID IS NULL THEN 'Table 2 only'
        WHEN w2.ProductID IS NULL THEN 'Table 1 only'
        ELSE 'Both tables'
    END AS record_status
FROM dbo.FirstWeekSales w1
FULL OUTER JOIN dbo.SecondWeekSales w2
    ON w1.ProductID = w2.ProductID
   AND w1.SalesPersonID = w2.SalesPersonID;

Key Takeaway: Use a FULL OUTER JOIN combined with CASE evaluation on key NULLs to detect missing or mismatched records between datasets.

3. WHERE versus HAVING Clauses

WHERE evaluates individual rows prior to grouping, whereas HAVING evaluates aggregated values after grouping occurs.

Execution Flow: The database engine applies the WHERE clause first to filter raw rows before computing intermediate groups or aggregation functions.
Aggregation Filtering: The HAVING clause executes strictly after GROUP BY, filtering aggregated summary metrics (like SUM(), COUNT(), or AVG()).
Syntax Rule: Aggregate functions cannot appear in a WHERE clause; attempting to filter SUM(boxes) > 2000000 requires a HAVING clause.

-- Filter individual records before aggregation, then filter groups post-aggregation
SELECT 
    SPID,
    SUM(Boxes) AS total_boxes
FROM dbo.Shipments
WHERE Date >= '2025-01-01' -- Pre-aggregation row filter
GROUP BY SPID
HAVING SUM(Boxes) > 2000000; -- Post-aggregation group filter

Key Takeaway: Filter individual rows with WHERE before grouping, and filter aggregate metric thresholds with HAVING after grouping.

4. Handling Nulls with COALESCE

COALESCE scans an arbitrary list of arguments sequentially and returns the first evaluated expression that is not NULL.

Mechanism: Pass multiple fallback columns or literals into COALESCE(arg1, arg2, ..., argN) to evaluate them from left to right.
Under the Hood: Replaces verbose, nested CASE WHEN ... IS NOT NULL expressions with a concise, optimized inline fallback evaluation.
Practical Nuance: Commonly used when reconciling cascading priority values, such as fallback interest rates, alternate phone numbers, or promotional pricing.

-- Extract the first valid price from a prioritized pricing cascade
SELECT 
    ProductID,
    COALESCE(SalePrice, DiscountedPrice, BasePrice, 0.0) AS effective_price
FROM dbo.Products;

Key Takeaway: COALESCE streamlines cascading fallback logic by returning the first non-null argument in a prioritized list.

5. Troubleshooting Query Logic and Complex SQL

Handling logic bugs and articulating complex query designs demonstrates authentic industry experience to interviewers.

Debugging Strategy: When queries run without syntax errors but yield incorrect results, isolate joined tables into smaller chunks and verify join cardinality to catch accidental one-to-many explosions.
Requirement Validation: Verify whether business assumptions match actual data constraints, checking for missed join keys or invalid filter conditions.
Interview Communication: Structure discussions around complex queries by detailing the business objective, source schemas, multi-table joins, testing timelines, and resume alignment.

-- Isolate joined cardinality to inspect row multiplication
SELECT 
    s.ProductID,
    COUNT(*) AS join_row_count
FROM dbo.Shipments s
JOIN dbo.Products p ON s.ProductID = p.ProductID
GROUP BY s.ProductID
HAVING COUNT(*) > 1000;

Key Takeaway: Debug unexpected results by deconstructing queries into modular chunks, checking join cardinalities, and aligning logic with business requirements.

Topics Covered in SQL Interview Patterns — Top 10 Question Types

Introduction & Categorization (0:00 - 0:45) — Outlines SQL interview formats, splitting questions into theoretical approach and practical technical execution.
Duplicate Detection Patterns (0:46 - 2:04) — Demonstrates methods to identify duplicate data using distinct row counts and grouped frequency counts.
Table Reconciliation Techniques (2:05 - 3:58) — Explains how to reconcile disparate tables and identify mismatched records using full outer joins and CASE statements.
Debugging Faulty Query Results (3:59 - 5:32) — Details structured troubleshooting approaches for isolating join explosions and validating business logic.
Describing Complex SQL Projects (5:33 - 7:18) — Shares strategies for articulating complex stored procedures and aligning technical narratives with resume bullet points.
WHERE versus HAVING Filtering (7:19 - 8:35) — Contrasts pre-aggregation row filtering using WHERE against post-aggregation group filtering using HAVING.
COALESCE Fallback Handling (8:36 - 9:50) — Explains the COALESCE function for selecting the first non-null value across multiple prioritized columns.

DA Career Playbook & Interview Prep Cheat Sheet

COUNT(DISTINCT column) — Counts unique non-null values in a column
```
SELECT COUNT(DISTINCT ProductID) FROM dbo.Shipments;
```

GROUP BY ... HAVING — Filters aggregated groups based on metric conditions

SELECT SPID, SUM(Boxes) FROM dbo.Shipments GROUP BY SPID HAVING SUM(Boxes) > 2000000;

FULL OUTER JOIN — Returns all rows from both joined tables

SELECT * FROM Table1 t1 FULL JOIN Table2 t2 ON t1.ID = t2.ID;

COALESCE(v1, v2, ...) — Returns the first non-null value passed

SELECT COALESCE(DiscountPrice, StandardPrice, 0) FROM dbo.Sales;

CASE WHEN ... END — Evaluates conditional branching logic within SQL queries

SELECT CASE WHEN ColA IS NULL THEN 'Missing' ELSE 'Found' END FROM dbo.Data;

Comparison Table

Feature	WHERE Clause	HAVING Clause
Execution Order	Before GROUP BY executes	After GROUP BY executes
Data Level	Filters individual table rows	Filters aggregated grouped rows
Aggregate Support	Cannot contain aggregate functions	Accepts functions like SUM, COUNT
Primary Purpose	Reduces dataset before processing	Applies thresholds to summary metrics

Common Pitfalls

Mistake: Using aggregate functions inside a WHERE clause filter. Avoid: Filter raw rows in WHERE and aggregate expressions in the HAVING clause.
Mistake: Leaving out join keys during reconciliation queries. Avoid: Join across all composite key columns to prevent unintended Cartesian row explosions.
Mistake: Writing nested CASE statements for sequential null fallbacks. Avoid: Pass candidate columns into COALESCE to return the first non-null value cleanly.
Mistake: Describing abstract complex SQL queries disconnected from your resume. Avoid: Align your technical examples with measurable projects and domain requirements listed on your CV.

FAQs

Why did my query return 2,000 rows instead of the expected 100 without throwing an error? A join condition was likely incomplete or mapped to a non-unique column, turning a one-to-one join into a one-to-many Cartesian explosion.
Can WHERE and HAVING clauses be used within the same SELECT query? Yes; WHERE filters raw rows before aggregation, and HAVING filters the summarized groups afterward.
How should I answer an interview question about a SQL function I have never used? Directly state that you have not encountered that specific function yet, and explain your general approach to solving that pattern.

Common pitfalls

Mistake: Using aggregate functions inside a WHERE clause filter. Avoid: Filter raw rows in WHERE and aggregate expressions in the HAVING clause.
Mistake: Leaving out join keys during reconciliation queries. Avoid: Join across all composite key columns to prevent unintended Cartesian row explosions.
Mistake: Writing nested CASE statements for sequential null fallbacks. Avoid: Pass candidate columns into COALESCE to return the first non-null value cleanly.
Mistake: Describing abstract complex SQL queries disconnected from your resume. Avoid: Align your technical examples with measurable projects and domain requirements listed on your CV.

Since my very first job as a software engineer until my recent job as a business intelligence developer, if there is one thing that remained a constant, it is SQL. So in this video, let me share with you 10 interview questions that really test whether you know SQL or not. Let's go. A quick note about these questions. All of these questions are for somebody who needs to use SQL in their data capacity. So whether you're going for a data analyst job, data engineer, data scientist, or anything related to data like AI engineer or whatever, these are the questions that I would personally ask somebody to understand whether they're familiar with SQL or not. These questions are perfect for beginners and people who are getting into the industry, but if somebody is more experienced, I would ask them a different set of questions. So let's get into the questions. I'm categorizing these questions into two buckets. One is testing the theory or the approach side of things, and the second one is testing the practical knowledge of SQL. For the theory side, there is no real database that we're going to use, but for the practical sides, we do require some sort of database to kind of explain how I would answer these questions. So for the purpose of that, I am going to use the Awesome Chocolates data set. So here is how that data set looks like. It is a simple four-table data model or database schema where we ship chocolates, so there is a Shipments table and three sides of the shipment, so what products we are shipping, what people are doing the shipments, which sales per- persons, and then which geographies the shipment of chocolates is going to. This is a very straightforward simple database, and you can quickly understand and use it. So, let's get into the questions. The first question is: I have a table of records, and I want to know if there are any duplicates in the data. What approaches would you use? This is a great question to test what kind of different strategies somebody is familiar with when it comes to SQL, and here is how I would personally answer this question. For example, I would use the count(*) to understand how many records are in the da- data, and then I would use count of distinct a specific column. Let me show you the query. So here I'm selecting count(*) as row count and count of distinct ProductID, a column in my data, as product count from the dbo.Shipments. Let's run this. And here I can see even though we have a total of 119,000 rows, the product count is only 22. This is indicating that there is a lot of duplicates in the product column. If I want to get b- more into this, like understand how many duplicates are there in each of the values of the product, I could also use a GROUP BY option like this, SELECT ProductID, count(*) from dbo.Shipments GROUP BY ProductID. And when we run that, we can see for each product how many records are there. Now, as this is a big chocolate company, there's going to be thousands of records for each of our products. But if I am looking at, for example, a very specific customer ID or a specific refund code or something else, I might find some have multiple records and others have only one record, and that is a great strategy to know if there are any duplicates in the data. The second question is, how do you compare two tables in the database and see which table has extra rows? This is also a common scenario, especially in many database developments, and here is how I would answer it. We can use joins to combine two tables. So if I join Table 1 with Table 2, if the re- data is fully matching, then we will see all the information in the join as well. But if the data is in only one table and not in the other table, then it's going to miss out. So if I use a FULL JOIN or an OUTER JOIN, then what's going to happen is we are going to get records that are in both tables, and wherever the corresponding record from the other table is missing, we are going to see that quickly. So here I have got a query for you. Here I have got two tables: first week sales and second week sales, and we want to compare them and then see which combinations of product and salesperson are there only in the first week as well as only in the second week or in both weeks. So here is the typical query pattern that I would use. I would uh select uh ProductID and sa- SalesPersonID from both tables, and then I'm going to write a CASE statement to basically see which ProductIDs is NULL. If it is NULL in Table 1, that means the record is only in Table 2, and if it is NULL in Table 2, that means it's only in Table 1. So we are going to use the CASE statement to kind of print data in Table 2 only, Table 1 only. If it is not NULL in both of these cases, that means the data is in both tables. And the join criteria is here. Uh we're just checking ProductID in both tables is same as well as SalesPersonID is the same as well. So when I run this, I'm going to get a result like this, and you can see, for example, here P19 SP01, they have only appeared in Table 1, not in Table 2. Likewise, all the way down here, P16 SP08, they have appeared only in Table 2. So this is a great way to compare two tables. Again, a common scenario, especially if you work as a data engineer or data analyst, and you have to work between different environments, whether they are uh production and testing environment or you're working in two stages of ETL like uh the source stage and the target stage, and you want to compare the tables. This is a great pattern to use. Now let's take a look at a theory or approach kind of a question. Here is a question that I would typically ask: What would you do if the query you have written works but produces wrong results? This could be a SELECT query, UPDATE query, whatever may be the case. Now this indicates that there are no syntax or structural issues with the query. It is executing fine. It's just it is giving me wrong results. So then I would start to go backward and then see where the error is happening, what business logic or assumption uh that I personally made wrong. Most of the times what happens is uh it is wrong because we misunderstood the requirement or it is wrong because we are doing something else that is syntactically correct, but wrong. A good example of syntactically correct, but wrong result would be incorrect join. So when you are joining two tables, you can specify this equal to that. Now it doesn't really enforce the join. All it does is it is checking, so if I check the wrong columns, I might get incorrect results, but the join itself is not wrong, so it will still execute the query. So I would check the joins. A classic example, and this has me- happened many, many times throughout my life as a SQL developer is, I would write a join, and I would kind of mention the condition wrongly, so the join would blow up. So instead of doing one-to-one join, it would do one-to-many join, and then it'll give me hundreds of records where I'm really looking for one record. So I was expecting, let's say, 100 rows in the result, but it is showing me 2,000 rows. So this is a classic case of join in- joins blowing up. So yeah, this is uh how I would uh approach. I would also go and look at uh maybe if it is a really big query, then I will break it and then run chunks of it individually to see at which stage of the query I'm getting into the wrong results and then work backwards to fix it. Uh but this kind of a question, the interviewer is really interested in understanding how you think and how you approach these kind of problems, and also to see if you have done any real development. If you have not done any serious SQL work, chances are you have never had this situation. So you would blabber or, you know, not have a good answer. Whereas if you have done some SQL work, you are familiar with this scenario that you your query works, but it gives you wrong result, so then you can fall back on that and you can give some solid examples of how you dealt with that situation. Another approach question that I would definitely ask whether you are a beginner or an experienced person is, what is the most complex query you have written? What was the scenario behind it? What is the business requirement behind it? Now I'll give you an answer from my personal perspective, but this answer, again, there's no right or wrong answer here. You have to uh really think about your experience as a database person or a data person and then give the answer in this case. For example, the most complex query that I have written so far in my life is actually in my recent job. I have built a very large stored procedure to generate a valuation report for a retirement village. The purpose of this stored procedure is it's basically 2,000 lines long, and it is to look at lots of different tables and produce a financial report that defines the value of the various holdings in that retirement industry. So for this purpose, we have to go through lots of different tables, the ledger transaction tables to see how much money was pulled in, and then separate these transactions into cash and accounting basis, as well as look at both historical and current contracts and build their connectivity so that we can find the true value. So when you put all of these business requirements together, the query was getting more complicated, and that is the most complex query I have written. It took me close to 3 weeks to write the initial query, and then another 3 to 4 weeks to actually test it and make sure that it is working correctly, and it is matching the expected results based on an older system that we have in place. So this uh when when somebody is asking this question, the underlying intention is again to see, have you done any serious development work or have you just been dabbling in SQL and maybe watch two or three YouTube videos and calling yourself a SQL person? So I would ask this question again to see what is the level of work you have done. So if you have uh mentioned, whatever you're mentioning, you I would also suggest that it reflects back on what you have said on your resume or CV about this work, because if you're saying something and none of this is mentioned on your CV, that is an obvious red flag. But if you have said something and it ties back to a specific bullet point or an achievement that you have done in your CV, that means, you know, all of this is in sync and you are a genuine candidate. Let's go back to a couple of technical questions. Give me an example each of WHERE and HAVING clause. Again, this is a great question to test the basic understanding of SQL. We use WHERE clause to filter a result based on some specific condition, one or multiple conditions. A simple example of a WHERE clause would be: Let's say I have got some shipment data, and I want to filter all the shipments that happened on a specific date. So here is how I would write that WHERE clause: SELECT * from dbo.Shipments WHERE Date = to a specific date. So in this case the date is 2025 1st of January. And if I run this, I'll see all the shipments that we did on that specific date. So we have 256 shipments on that date. And we can write multiple conditions here, so for example, I can say Date is this, and SPID is a specific person like SP01. And when I run that, I'll get even smaller set because now we have written two conditions. So we could use AND, OR, and many other combinations of different things to filter down the list. The HAVING clause, on the other hand, is helpful if I want to filter after having aggregated some data. So a classic example is, let's say I want to see all the uh shipments, all the salespeople who have done shipments of more than 2 million boxes of chocolates. Well, that's a lot of chocolates. So here is the query: uh SELECT SPID, sum of boxes, boxes is the number of boxes column, as total boxes where uh from Shipments, and we are grouping this by salesperson ID, SPID, and then we use the HAVING, HAVING sum of boxes greater than 2 million. Now when I run this, I'll see just a few records, 13 rows. If I don't do that, if I just select this much, not the HAVING clause, and run it, I'll see 25 rows. That means we have got 25 sales people, but when I have this extra condition that you should have more than 2 million boxes, I'm looking at only 13 people. So that's what HAVING is. WHERE is for specific uh records to filter, whereas HAVING is after you have done some sort of a grouping, you want to filter based on the grouped by condition. We can also mix both of them to do more complicated things. Again, when you're answering these kind of questions, while you can reflect on some of these kind of made-up examples, it's a good idea to actually use the examples based on the previous work that you have done, whether it is project work, school work, or course work, or any other experiences where you have done this. Let's go to another technical question. What is the coalesce function? No, no, no, that's not right. Coalas? No, no. It's coalesce. What is the COALESCE function in SQL, and how do you use it? This is a great function, and again, by asking such a very specific question, I am testing whether you are familiar with these things, and have you used them, because it's a very useful function, mind you, and, you know, it tells that somebody has actually done some serious work. Uh what COALESCE does is, uh many times we will have a query or a scenario where you will have lots of different values, and you have to pick the very first non-null value, right? So this is where you could write a more complicated, let's say you have got four values: uh sale price, discounted sale price, and some other price, some other price, and only one of them will have a value. Whatever that value is we need to pick. So first non-null is what we want to pick, and when I'm writing the query, if I'm just che- testing using uh some sort of if conditions or case conditions or whatever, it gets very long. By using the COALESCE function, you simply just pass everything, and it'll automatically pick the first non-null argument and then return that. So I've used this many, many times, even in the recent project, where we would have different interest rates uh for a particular contract, and we would have to pick the very first non-null one. Uh so we would use that to pick the uh correct value out of a bunch of different values. So again, COALESCE function. Of course, uh here the intention is not to really specifically ask about COALESCE, but something really specific like that just to test whether they have done that or not. Again, if you don't know that, if you're never used it, there is no harm because the whole point of this kind of technical questions is to see uh whether you've used it or not. You can always say, "Oh, I've never used it," or "I don't know what it is. Can you give me an example of when somebody would use it so I can see if I have done something similar like that?" And you can have a conversation with the interviewer at that point. Another technical question, which is, give me an example of CASE WHEN statements. Again, very common in many, many business reporting, data analysis, data engineering situations. We use the CASE WHEN statements, even earlier in this interview, I've shown you uh we have used the CASE WHEN statements to compare two tables, so that is one example. If I'm taking human resources example, we could use CASE WHEN to calculate the employee's tenure, and then categorize them as new joinee if their tenure is less than 12 months, uh 1 to 2 years if it is between 1 to 2 years, and more than 2 years if they have been with us for 2+ years. Another example this time from medical industry if I take, we can use CASE WHEN to see whether somebody has been a long-term patient, short-term patient, or outpatient based on the total time they have spent uh they between their in-time and out-time. So if they have come in and gone on the same day, they might be an outpatient, whereas if the- they've come in and gone under 3 days, they might be a short-term patient; more than 3 days, you're long-term patient. So you can again categorize people based on these kind of things using the CASE WHEN logic. Now let's move on to more approach questions. Uh usually when I am interviewing people, I focus more on the approach and the kind of mindset questions rather than the technical stuff simply because these days with the help of AI and many other tools, uh it's not impossible to build the logic. What I'm really looking for is somebody who has the capability, and that kind of thing can only be tested by asking about approaches and things that they have done. So the first question in this series is, what are some of the limitations of SQL, and what are the some of alternatives that you would use? This is a great question. Again, it kind of tells me that the person has actually thought about SQL versus something else, and they know what is SQL good for and what is it not good for. If I have to answer this question, this is how I would say it: SQL is mainly for tabular data, but many times in business situations our data is not tabular. We may have images, videos, files, API calls, lots of other things, and in all of those things, using SQL, while it is somewhat possible, is really hard. So that's one thing. Another thing is SQL is really good when you have lots of structured and neatly arranged data. Many times your data is not like that. You might have just a small spreadsheet or an API call or something else, and you would want to uh take that and do something to the data or analyze it or whatever. So in that case, again, uh in some of those things, because when you have little data, it feels like an overkill to use SQL and set up a whole database for it. So apart from SQL, the alternatives that I normally use personally in my work life are Excel, especially Power Query in Excel, as well as Python. Frameworks like, libraries like Pandas in Python help me to work with data and analyze it, and even concepts like GraphQL if I'm dealing with uh JSON data that is coming in from an API, and I need to analyze it or I need to take specific portions of it and do something with that. So these are the alternatives. Again, uh while the answer that I gave is more or less complete and it can be used for you by you as well, it's a good idea to think about it because in a specific situation, in a specific industry, the alternatives might be slightly different, and the limitations might also change. Another theoretical question or approach question that I would ask is, when would you use a denormalized database or denormalized table? Now back in school days and college days when I was learning about SQL, one of the biggest thing is normalization. How how does the first normal, second normal, third normal, fourth normal, and all of these forms look like, what is the purpose of it, and all of that? But when I go and start working, I see that not all data is normalized all the time. Many times I have to deal with denormalized data or flat files. So this is a more common thing. Uh in school or college situation we don't really think too much about it, but when you go to work you see that there is a lot of denormalized stuff going on. So a good example here is uh denormalized data is perfect if I want to uh do more analysis-heavy work. Many times in analytical situation what happens is you are only querying. You are not doing any updates, deletes, or inserts, or any of the other DDL and DML stuff. All of the things that you do are querying the data. And because querying is just asking it, getting the answer, if I have got 20 tables and I need to go to all the 20 tables, connect all the relationships, and bring the picture, it is going to be very costly, whereas if it the query is hitting just one table, it will be significantly faster and better, and the queries and the reports will be responsive. So we use denormalized data for these kind of things. Another thing is, many times you don't need to em- enforce the referential integrity all the time. Uh this could be some simple uh very, very easy to use business applications, or even uh some other kinds of very specific things where there's no need for us to have the referential integrity or track every little thing. In such cases, using denormalized tables is a good idea. So, by asking this kind of question, again, I am looking at whether the candidate has come across these or not, because that is more common in a business situation. So I'm trying to see whether their knowledge is textbook or real-world. The last question, and this is something that I ask pretty much any kind of development work, not just SQL work, is, what would you do if you can't figure out the query for a specific business requirement? What Walk us through the steps. Again, there is no right or wrong answer for this, uh but I want you to pause here and think about this. What would you do? You have got a business requirement, you're supposed to write the query, but you have no idea how to proceed. What would you do? I'll give you my answer here. Uh this happened many, many times in my life. Uh the most recent one is the stored procedure one. I had to write this massive stored procedure. I had no idea what to do. I mean, how do you even write a 2,000-line query? Uh it's not something that you can crank up in one day. So essentially what I did is I spent quite a bit of time first understanding the business rules and the requirement uh by talking to various people in the organization uh and getting their perspective on what is needed, what is correct, and what is incorrect. Then I looked at the existing SQL uh code to understand the patterns and the business logic implementation, so whatever is the real world, the how is it implemented in the query. So once these two are there, then I started building in small chunks. And of course, I took the help of uh tools like Copilot and other AI tools whenever I got stuck, or whenever I didn't know how a specific business requirement can be translated into the equivalent in SQL, because I've not done that kind of SQL in a while, or I'm not even familiar with that in syntax. So this is the approach that I take. Um you can also basically reflect on how you have done work previously and what were the challenges that you faced, and what how you overcame that, and then you translate that into the answer here. This is a great question, especially whether you are doing SQL or Python or C++ or Power BI, no matter what, you know, having obstacles, having hurdles is part of life. So essentially as an interviewer, I'm looking for how you overcome that rather than uh I don't want to hear somebody say, "Oh, I never faced any hurdle." That means you have not done any real or hard work in your life at all. So those are the 10 questions that I would ask. Of course, you might think, "Oh, is that all? Shouldn't there be more complicated questions about window functions, CTEs, subqueries, and, you know, different kinds of joins, and all of that?" Of course, there are questions, but, uh like I said, I don't really ask those questions simply because if you if you've not got the correct approach, correct way of thinking, then it doesn't matter if you know CTE or not. Personally, that's how I look at it. But I do think knowing about them is helpful, so I have got five more questions. These are more technical, theoretical questions. Uh all those five questions are a- also in the video description, and if you want to have the queries and the answers for all the technical questions including these five ones, I've got a page on my website that you can go and you can grab all of those. So I hope you found this 10 SQL interview questions episode helpful and interesting. If so, give it a like, and I wish you all the very best with your upcoming SQL interview. Do let me know in the comments if you've landed that job, or if you cracked that interview, and if not, what questions stumped you? Write that there, so other people can see that, and, you know, you can help each other out. So thank you so much for watching. Again, all the best with your interview, and I'll catch you again somewhere else. Bye.

Frequently asked questions

Why did my query return 2,000 rows instead of the expected 100 without throwing an error?

A join condition was likely incomplete or mapped to a non-unique column, turning a one-to-one join into a one-to-many Cartesian explosion.

Can WHERE and HAVING clauses be used within the same SELECT query?

Yes; WHERE filters raw rows before aggregation, and HAVING filters the summarized groups afterward.

How should I answer an interview question about a SQL function I have never used?

Directly state that you have not encountered that specific function yet, and explain your general approach to solving that pattern.

How was this lesson?

Your feedback helps us refine explanations and catch bugs.