30 SQL Basic Interview Questions for a 30-Minute Sprint

Master SQL basic interview questions in 30 minutes with plain-English answers, common traps, and a step-by-step order from SELECT to joins.

You have one evening. Not one week, not one weekend — one evening to stop feeling behind on SQL and start feeling ready enough to walk into a screening round without blanking. The good news is that sql basic interview questions at the entry level keep circling the same small set of ideas. The bad news is that most study resources hand you a list of 80 questions and wish you luck, which is the fastest way to memorize nothing useful.

This guide works differently. It sequences the concepts the way interviewers actually introduce them — starting with SELECT and WHERE, building through GROUP BY and HAVING, then landing on joins, keys, and the NULL traps that quietly cost candidates easy points. If you follow the 30-minute practice sequence at the end, you will be able to say clear answers out loud, which is the actual test.

The 10 SQL Basics You Need Before Anything Else

What are the core SQL basics a beginner should memorize first for an interview?

The trap most beginners fall into is trying to cover everything before they can answer the obvious questions. SQL basics for interviews have a natural hierarchy, and ignoring it means you spend two hours on window functions while still fuzzy on why GROUP BY exists.

The starter set that actually matters, in order: SELECT and FROM (how you ask for data), WHERE (how you filter rows), ORDER BY (how you sort results), GROUP BY (how you summarize by category), HAVING (how you filter after summarizing), and the three key types — primary, unique, and foreign. Everything else — subqueries, CTEs, window functions, stored procedures — is built on top of these. Nail the foundation first.

From real hiring experience, the most over-prepared topic at the entry level is subqueries. Candidates will walk in ready to explain correlated subqueries but stumble when asked to explain why HAVING exists. The most under-prepared topic, consistently, is NULL behavior. It shows up in almost every screening and trips up people who have otherwise solid query instincts.

How do you explain SQL to someone who has never used it?

The cleanest plain-English version goes something like this: "SQL is a language for asking questions of a database. A database stores information in tables — rows and columns, like a spreadsheet. SQL lets you say: give me the rows from this table where this condition is true, sorted this way."

If you need a concrete anchor, use employees and departments. You have an `employees` table with columns like `name`, `salary`, and `department_id`. You have a `departments` table with `department_id` and `department_name`. SQL is how you connect those tables and pull out exactly the rows you care about. That framing — tables, rows, columns, questions — is enough for a beginner-level answer and sounds natural rather than rehearsed.

Which SQL topics show up first in a basic interview, and which ones can wait?

According to SHRM's hiring practice guidance and commonly published technical screening rubrics, entry-level SQL screens almost always start with single-table queries before introducing multi-table scenarios. That means SELECT, WHERE, ORDER BY, GROUP BY, and HAVING are the first gate. Joins come second. Subqueries and performance topics come third, if at all in a basic round.

What can safely wait until you have more time: CTEs, window functions, indexes and query optimization, stored procedures, and database-specific syntax differences. These topics matter for mid-level and senior roles. For a beginner screen, knowing them is a bonus, not a baseline.

How to Answer the Query Basics Without Rambling

How do you explain SELECT and FROM in 30 seconds?

The spoken answer that survives follow-up: "SELECT tells the database which columns I want to see. FROM tells it which table to look in. So `SELECT name, salary FROM employees` gives me just those two columns from every row in the employees table."

The follow-up that usually comes next is: "What if you want all columns?" The answer is `SELECT *`, and you should mention immediately that in production code you'd avoid it because it pulls unnecessary data. That one extra sentence signals you understand the real-world tradeoff, not just the syntax. For a basic SQL interview question, that distinction is often what separates a passing answer from a strong one.

How do you explain WHERE without mixing it up with HAVING?

WHERE filters rows before any grouping or aggregation happens. That is the entire distinction, and it is worth saying exactly that way.

Concrete example: "I have an `orders` table. `WHERE amount > 100` gives me only the orders above $100 — it filters individual rows. That's WHERE." The mistake candidates make is trying to use WHERE after a GROUP BY, which SQL does not allow. WHERE does not know what a group is. It only knows rows. Keep that image — WHERE sees rows, HAVING sees groups — and you can answer the distinction question under pressure without hesitating. The official PostgreSQL documentation on aggregation makes this sequencing explicit: WHERE runs before grouping, HAVING runs after.

How do you explain ORDER BY and GROUP BY clearly in under a minute?

These two get confused because they both change how results look, but they do completely different jobs.

ORDER BY is about sorting. `ORDER BY salary DESC` gives you the same rows, just ranked from highest to lowest salary. Nothing is combined, nothing is summarized — you are just rearranging the output. GROUP BY is about summarizing. `GROUP BY department_id` collapses all rows with the same department into one row, so you can ask aggregate questions: how many employees are in each department, what is the average salary per department. One is ranking, one is rolling up. A report that shows total sales by region uses GROUP BY. A report that shows the top 10 salespeople uses ORDER BY.

How do you explain HAVING when the interviewer wants the short version?

One clean sentence: "HAVING filters the results of a GROUP BY, the same way WHERE filters individual rows." Then back it up immediately with an example, because the sentence alone sounds like a definition you memorized.

Example: "If I group sales by salesperson and I only want to see salespeople with total sales above $10,000, I can't use WHERE — there's no individual row with that total yet. I use `HAVING SUM(amount) > 10000` after the GROUP BY." That answer is specific enough to survive a follow-up and short enough to deliver without rambling.

Here is the contrast between a fuzzy answer and a sharp one. Fuzzy: "HAVING is like WHERE but for groups." Sharp: "WHERE filters rows before grouping. HAVING filters the grouped result. If you try to use WHERE on an aggregate function like SUM or COUNT, SQL will throw an error — because at the WHERE stage, those aggregates haven't been calculated yet." The second version would survive a follow-up. The first would not.

Keys, Constraints, and the Stuff Interviewers Use to See If You Really Know the Table

What is the difference between primary key, unique key, and foreign key?

Entry-level SQL questions about keys trip candidates up because the definitions sound similar until you anchor them to what each key actually enforces.

Primary key: uniquely identifies every row in a table, cannot be NULL, and there can only be one per table. In an `employees` table, `employee_id` is the primary key — every employee gets exactly one, and no two employees share one. Unique key: also enforces uniqueness, but it can allow NULL (in most databases) and a table can have multiple unique keys. An `email` column is a classic unique key — two users cannot share an email, but the column is separate from the primary key. Foreign key: links one table to another. The `department_id` column in `employees` is a foreign key that references `department_id` in the `departments` table. It enforces that you cannot assign an employee to a department that does not exist.

What do SQL constraints actually do in a real table?

Think of constraints as guardrails that block bad data before it enters the table. NOT NULL means a column cannot be left blank — if you try to insert a row without a required value, the database rejects it. CHECK adds a condition: `CHECK (age >= 18)` means no row with age below 18 can be inserted. UNIQUE prevents duplicate values in a column. PRIMARY KEY combines NOT NULL and UNIQUE into one constraint.

A signup form is the clearest real-world example. The `users` table has `email` as UNIQUE (no duplicate accounts), `username` as NOT NULL (you cannot register without one), and `user_id` as PRIMARY KEY. Without these constraints, bad data slips in silently — duplicate emails, blank usernames, rows with no identifier — and cleaning it up later is far more expensive than blocking it at the table level. The MySQL documentation on constraints covers each of these in detail if you want the exact syntax for your dialect.

Why do interviewers care about normalization at the beginner level?

At the beginner level, normalization means one thing: stop storing the same fact in multiple places. If you have a `customers` table and an `orders` table, the customer's address belongs in `customers`, not repeated in every row of `orders`. When the customer moves, you update one row instead of hundreds.

The common mistake in beginner schemas is putting `customer_name` and `customer_email` directly in the `orders` table. Now if a customer changes their email, you have to update every order they ever placed — and if you miss one, your data is inconsistent. Normalization is not about memorizing 1NF, 2NF, and 3NF for a beginner screen. It is about being able to say: "I try to keep each fact in one place so updates stay clean."

Joins, Subqueries, and the Point Where Beginners Usually Wobble

When should you use INNER JOIN vs LEFT JOIN in a beginner interview question?

The simple rule first: INNER JOIN returns only rows that have a match in both tables. LEFT JOIN returns all rows from the left table, plus matching rows from the right — and fills in NULL where there is no match on the right.

Here is where the simple rule breaks down. If you have a `customers` table and an `orders` table and you want to see all customers including those who have never placed an order, INNER JOIN will silently drop those customers. LEFT JOIN keeps them and shows NULL in the order columns. SQL interview questions for beginners almost always include a scenario where missing rows matter — customers with no orders, employees with no manager, products with no sales. The question to ask yourself: "Am I okay with rows disappearing if there is no match?" If yes, INNER JOIN. If no, LEFT JOIN. The PostgreSQL documentation on join types explains the full behavior clearly.

How do you explain a subquery without making it sound scary?

A subquery is a query inside a query. The inner query runs first and produces a result, and the outer query uses that result. That is the whole idea.

Example that makes it concrete: "I want to find all employees who earn more than the average salary. I could calculate the average in one query, then write a second query using that number. Or I can do it in one step: `SELECT name FROM employees WHERE salary > (SELECT AVG(salary) FROM employees)`." The inner query calculates the average. The outer query uses it. Two steps, one statement.

What's the fastest way to tell a join from a subquery in an interview?

Memory hook: use a JOIN when you need columns from both tables in your result. Use a subquery when you just need a value from another table to filter or compare against.

If you want to list employees alongside their department names, you need columns from both `employees` and `departments` — that is a JOIN. If you want to find the top spenders without needing any columns from the `orders` table in your final output, a subquery can be cleaner. In an actual interview loop, a candidate who wrote a subquery where a JOIN was expected got partial credit for the correct logic but was asked to rewrite it — the interviewer wanted to see if they understood that the JOIN version was more readable and indexable. Knowing both patterns and being able to say why you chose one is what separates a passing answer from a strong one.

NULL, DISTINCT, and Aggregates: The Small Traps That Cost Easy Points

Why does NULL keep breaking beginner SQL answers?

NULL is not zero. It is not an empty string. It means the value is unknown or absent, and that distinction breaks ordinary comparison logic.

`WHERE salary = NULL` will never return rows, even if some salaries are NULL. SQL requires `WHERE salary IS NULL`. The reason is that NULL compared to anything — even another NULL — returns NULL, not TRUE or FALSE. So the filter silently drops every row. SQL basics for interviews almost always include at least one NULL question, and the answer that lands is: "NULL means unknown, so you can't use = to find it. You need IS NULL or IS NOT NULL." One real data-cleaning example that shows why this matters: a team calculated average response times and got a suspiciously high number because they forgot that NULL response times were being excluded by the aggregate function, not treated as zero.

How do you use DISTINCT without hiding a data problem?

DISTINCT removes duplicate rows from your result. The risk is using it to make a messy result look clean without understanding why the duplicates exist.

If you have a `contacts` table and `SELECT DISTINCT email` returns fewer rows than `SELECT email`, you have duplicate emails in your data. DISTINCT is the right tool when duplicates are expected and harmless — for example, pulling a unique list of countries from a sales table. It is the wrong tool when duplicates signal a data integrity problem that should be fixed at the source. In an interview, if you reach for DISTINCT, be ready to explain why the duplicates are there and whether removing them is correct.

What do SUM, COUNT, AVG, MIN, and MAX get wrong when NULL is involved?

The rule beginners forget: most aggregate functions ignore NULL values entirely. `AVG(salary)` calculates the average of non-NULL salaries only — it does not treat NULL as zero. `COUNT(salary)` counts only non-NULL salary values. `COUNT(*)` counts all rows regardless of NULL.

Small table example: five employees with salaries 50,000, 60,000, NULL, 70,000, NULL. `AVG(salary)` returns 60,000 — the average of three values, not five. `COUNT(salary)` returns 3. `COUNT(*)` returns 5. If you expected AVG to account for all five employees, your number is wrong. The fix is usually `COALESCE(salary, 0)` to substitute zero for NULL before aggregating — but only if zero is actually the right business interpretation.

The 30-Minute Practice Sequence That Actually Sticks

How should you spend the first 10 minutes if you only have one evening?

Minutes 0 to 10 are about recall, not mastery. Write out — on paper or in a text editor — the five core clauses in order: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY. Then write one sentence explaining what each does. Do not look anything up. Whatever you cannot write from memory is what you need to review first.

Basic SQL interview questions at the screening level almost always start with these clauses. If you can explain each one in a sentence and write a simple query using it, you have covered the first gate. This is retrieval practice, not reading — and learning science research on spaced retrieval from the Association for Psychological Science consistently shows that active recall beats passive review for retention under time pressure.

What should you practice in minutes 10 to 20 if you are a total beginner?

Move to single-table queries with filtering and grouping. Use this prompt: "You have a `sales` table with columns `salesperson`, `region`, and `amount`. Write a query that shows total sales by region, but only for regions where total sales exceed $50,000."

That one prompt forces you to use SELECT, FROM, GROUP BY, HAVING, and a SUM aggregate in sequence. Write the query. Read it out loud. Then change the prompt slightly — filter by a different threshold, add ORDER BY to rank the regions. The goal is not to write perfect SQL; it is to get comfortable moving between clauses without freezing.

What should you drill in the final 10 minutes before the interview?

Shift to joins and one subquery. Prompt: "You have `customers` and `orders` tables linked by `customer_id`. Write a query that returns all customers, including those who have never placed an order." That forces a LEFT JOIN decision. Then: "Find the customer who has placed the most orders." That can be solved with a subquery or a JOIN plus ORDER BY and LIMIT — try both.

After each query, say the answer out loud in one sentence: "I used LEFT JOIN here because I needed to keep customers even if they had no matching orders." That spoken summary is exactly what interviewers want to hear. Coaching beginners through entry-level SQL screens repeatedly shows the same pattern: candidates who can write the query but cannot explain it in plain English get pushed harder on follow-ups, while candidates who lead with the explanation and then write the query tend to move through faster.

The Follow-Ups That Usually Come Next

What follow-up questions should you expect after answering a basic SQL question?

The standard interviewer move after a basic SQL answer is to test whether the answer was memorized or understood. If you explain GROUP BY, they will ask: "What happens if you SELECT a column that is not in the GROUP BY?" (SQL will error or return arbitrary values depending on the dialect.) If you explain INNER JOIN, they will ask: "What if there are multiple matching rows on the right side?" (You get duplicate rows on the left — one for each match.)

Expect these probes in a normal screening round: "Can you show me that in a query?", "What would happen if the data had NULLs here?", "Why did you choose that approach instead of a subquery?" The pattern is always the same: one level deeper than the definition you just gave.

How do you answer when they ask you to write the query on the spot?

Saying the right thing and building the query live are different skills. When asked to write on the spot, narrate as you go: "I'll start with SELECT and the columns I need, then FROM to name the table, then I'll add a WHERE to filter before grouping." This running commentary does two things — it shows your reasoning and it buys you a few seconds to think without going silent.

Practice prompt you can use on paper right now: "You have an `employees` table with `name`, `department`, and `salary`. Write a query to find the average salary by department, only for departments with more than five employees." Write it without looking anything up. If you get stuck, say out loud what you are trying to do — interviewers will often give you a hint if they can see you are thinking correctly.

How do you handle it if you only know one SQL dialect?

Say it directly and without apology: "I've been working primarily in PostgreSQL, so I'll write the query in that syntax — but I'm happy to flag if something is dialect-specific." That is a clean, professional answer. It is far better than writing MySQL syntax when you are not sure of the differences, then getting caught when the interviewer asks about a specific function.

The real dialect differences at the beginner level are minor — LIMIT vs TOP for row limits, some differences in string functions, and a few NULL-handling edge cases. According to W3Schools SQL reference, the core DML syntax (SELECT, WHERE, JOIN, GROUP BY) is consistent enough across MySQL, PostgreSQL, and SQL Server that a beginner answer in any of them reads correctly. Overclaiming fluency in a dialect you have only skimmed is the bigger risk.

How Verve AI Can Help You Ace Your Coding Interview With SQL

The hardest part of SQL interview prep is not learning the syntax — it is being able to explain a query clearly while you are writing it live, under pressure, with someone watching. That gap between knowing the answer and delivering it fluently is exactly what Verve AI Interview Copilot is built to close.

Verve AI Interview Copilot reads your screen in real time — whether you are working through a SQL prompt on HackerRank, LeetCode, or CodeSignal, or inside a live technical round — and surfaces suggestions based on what is actually on your screen, not a generic prompt. If you are mid-query and blanking on whether to use HAVING or WHERE, Verve AI Interview Copilot can surface the distinction in the moment, before the silence gets uncomfortable. The Secondary Copilot feature keeps you focused on one problem at a time rather than spiraling into adjacent topics when the pressure spikes. And because the desktop app is invisible to screen share at the OS level, the support stays between you and the screen. For a beginner walking into a SQL screening round with one evening of prep behind them, having something that responds to what's actually happening — not a canned script — is the structural advantage that memorization alone cannot give you.

Conclusion

You do not need to know all of SQL before a basic screening round. You need to know the handful of ideas that interviewers keep returning to — SELECT through HAVING, the three key types, the LEFT JOIN versus INNER JOIN decision, and the NULL traps that quietly break aggregate answers. That is a manageable set, and it is learnable in one focused evening.

Run the 30-minute sequence once. Write the queries on paper. Say the answers out loud. The goal is not to sound like you read a textbook — it is to sound like someone who has actually used these tools and knows why each one exists. Walk in with that, and the basics will not be what stops you.