What are the most asked SQL interview questions for freshers?

What are the most asked SQL interview questions for freshers?

Fresher SQL rounds in India keep returning to the same skills: filter rows, join tables, group results, tell WHERE from HAVING, handle NULL, and explain an index in plain language. You are rarely asked to design a bank. You are asked to read a small schema and write a query that would survive real data, including missing values and duplicate customers. If you can write the query on a whiteboard or in a shared editor, the definition is optional. If you can only define a join, the round is already in trouble.

Answer in this order. State what the query returns. Write the query. Say which rows it drops. Then mention one way it could be slow. That habit works for joins, groups, and subqueries. The notes below are a preparation guide, not a promise that every company uses this list.

What does a basic SELECT actually do?

SELECT chooses columns. FROM chooses the table. WHERE keeps rows before grouping. GROUP BY collapses rows that share a key. HAVING filters those groups. ORDER BY sorts the output. LIMIT, or TOP in some products, cuts the output down. Freshers mix the order because they write the words in the order they think. The database does not read the query in the order you type it. A practical way to remember the work is: rows come from somewhere, rows are filtered, rows are grouped, groups are filtered, then the result is sorted and trimmed.

Write a small example from a placement story. “Orders after 1 April, grouped by city, only cities with more than ten orders, sorted by that count.” That sentence maps onto WHERE, GROUP BY, HAVING, and ORDER BY. If you cannot map it, you will put the city filter in the wrong clause. WHERE cannot use an aggregate such as COUNT unless that aggregate is not what you think it is. The count of a group belongs in HAVING.

Also select only the columns you need. SELECT * is fine while you explore. In an interview answer, name the columns. It shows you know the schema you were given.

How do you explain INNER JOIN and LEFT JOIN?

An INNER JOIN returns rows that match in both tables. A LEFT JOIN returns every row from the left table and the match from the right table when it exists. When the right side has no match, the right-hand columns are NULL. A RIGHT JOIN is the same idea with the tables swapped, and most teams write a LEFT JOIN instead so the “keep all of these” table is the one mentioned first. A FULL OUTER JOIN keeps unmatched rows from both sides. Many fresher interviews never ask for it. They do ask you to find customers with no orders, which is a LEFT JOIN plus WHERE orders.id IS NULL.

Say the business sentence before the syntax. “I want every student, even those with no test score yet” is a left join from students to scores. “I want only students who have a score” is an inner join. Draw two small tables with three rows and one missing match. Interviewers trust a drawing you can talk through more than a paragraph that says “left join returns the left table.”

The follow-up is duplicate rows. If one customer has three orders, an inner join to orders returns three rows for that customer. If you then count customers, you will count the customer three times unless you count distinct ids or you aggregate first. This is the bug behind a surprising dashboard total. Mention it before they do.

What is the difference between WHERE and HAVING?

WHERE filters rows. HAVING filters groups. You can write WHERE without GROUP BY. HAVING is almost always paired with GROUP BY. A condition on a plain column, such as city = 'Chennai', belongs in WHERE when you mean “only look at Chennai rows.” A condition on an aggregate, such as COUNT(*) > 10, belongs in HAVING. Putting the aggregate in WHERE is a syntax error in standard SQL. Putting a row filter in HAVING can work in some engines and still be the wrong lesson, because the database may group more data than it needed to.

Use one spoken pair. “Orders placed this year” is WHERE on the date. “Customers who placed more than five orders this year” is WHERE on the date, GROUP BY customer, HAVING on the count. If you skip the WHERE, old years inflate the count. Candidates lose this question by remembering the words and forgetting the date.

How does NULL behave in filters and joins?

NULL means unknown, not zero, and not an empty string. A comparison with NULL using = does not return true. You test it with IS NULL or IS NOT NULL. NULL in a join key fails the match, so those rows disappear from an inner join and appear with empty columns in a left join. COUNT(column) skips NULLs. COUNT(*) counts rows. SUM of an empty set is NULL in many engines, which surprises people who expected zero. Wrap with COALESCE when the report must show zero.

In an interview, fix a query that says WHERE phone = NULL. Explain why it returns nothing useful. Then explain why two NULLs are not equal to each other in a join. If the schema uses empty string and NULL for the same idea, say you would clean that before you trust the report. Data cleaning is part of SQL for analyst freshers, not a separate hobby.

What must you remember about GROUP BY?

Every selected column that is not inside an aggregate must appear in the GROUP BY. If you group by city and you also select customer name, the database does not know which customer to show for a city with many customers. Some products used to pick an arbitrary value. Do not rely on that. Either group by both columns or aggregate the name. The interview version is a query that shows city and the latest order date: group by city, and use MAX(order_date).

Be careful with counts after joins, as the join section said. Also know the difference between COUNT(DISTINCT customer_id) and COUNT(*). The first answers “how many customers.” The second answers “how many rows,” which may be orders. Say which question the business asked before you pick the function.

What is an index, in fresher language?

An index is a separate structure that helps the database find rows without reading the whole table, often like a book index that points at page numbers. It speeds some searches, filters, and joins, and it costs extra work on every insert, update, and delete because the index must be maintained. A primary key is usually indexed. A foreign key used in joins is a common extra index. A column you never filter and never join does not need an index just because it exists.

You should know a clustered index, especially if the conversation is SQL Server: it is the index that defines the table’s stored order, and a table has one of those. Other indexes are nonclustered and point back at the row. MySQL’s InnoDB clusters on the primary key in a similar spirit. You do not need a vendor argument. You need the idea: one physical order, extra lookup structures, and a write cost. The longer index guide on this site is types of SQL Server indexes, if the interviewer stays on that topic.

A fresher who says “index every column” will be asked what happens to a table that is inserted all day. Answer that the writes get slower and the planner may ignore a useless index. A fresher who says “never index” will be asked why a search on ten million orders is slow. Answer with a selective column that the query actually filters.

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

A primary key identifies a row. It is unique and it does not allow NULL. A unique constraint also forbids duplicate values, and in some databases it can allow a single NULL, so do not treat the two words as identical without checking the product. A foreign key says a value in this table must exist as a key in another table, such as an order’s customer id. Foreign keys protect you from orphan rows. They are not a substitute for an index, though the database may create one.

In a design question, pick a primary key that does not change. A phone number is a bad primary key because people change phones. A surrogate id plus a unique email is a calmer design. Explain that in one example from a project, even if the project was a college library system.

What is the difference between DELETE, TRUNCATE, and DROP?

DELETE removes rows and can have a WHERE clause. It is row-by-row from the user’s point of view and can be rolled back inside a transaction. TRUNCATE empties a table quickly and usually resets identity counters. It is not the tool when you want to remove “only last year’s rows.” DROP removes the table definition itself, not only the data. The interview wants to hear that you will not DROP a table because a cleanup ticket said “remove old rows.”

Also mention transactions briefly. BEGIN, then the change, then COMMIT if it looks right, or ROLLBACK if it does not. On a production-like question, say you would run the SELECT version of the WHERE clause first and count the rows before deleting. That sentence has saved more fresher jobs than a perfect definition of ACID.

What do ACID and a transaction mean here?

A transaction is a group of changes that should succeed or fail together. Transferring money out of one account and into another is the classic pair. ACID is the set of promises people expect: atomic, so the pair is all or nothing; consistent, so rules such as “balance cannot go negative” still hold; isolated, so another session does not see a half-finished transfer; durable, so a committed transfer survives a crash. You can say that in ordinary words. You do not need a lock-manager lecture unless the role is a database engineer.

The fresher mistake is to update two tables in two separate auto-committed statements and call it safe. If the second statement fails, the first has already happened. Wrap them. If you have never used a transaction, say so, then write the two updates inside one.

When do you choose a join instead of a subquery?

Both can answer “customers who ordered in March.” A join is often clearer when you need columns from both tables. A subquery, or an EXISTS check, is often clearer when you only need to know that a match exists. IN with a subquery is fine for a short list and dangerous when the subquery can return NULL, because NULL makes the IN test unknown and the row disappears. Prefer EXISTS if the interviewer pushes on that edge.

Correlated subqueries run an inner query per outer row. They are easy to read and easy to make slow. If the interviewer asks you to speed one up, the first rewrite to try is a join or a grouped derived table. Say that you would compare the plans rather than argue from fashion. You will not have a production planner in the interview. You can still describe what you would look for: a scan of a large table, a missing index on the join key, or a function wrapped around the column so the index cannot be used.

What is a window function, at fresher depth?

A window function calculates across a set of rows that stay in the result, instead of collapsing them the way GROUP BY does. ROW_NUMBER, RANK, and a running SUM are the three worth practising. “Latest order per customer” is ROW_NUMBER over the customer, ordered by date descending, then a filter that keeps number 1. You usually do that filter in an outer query because WHERE cannot see the window result in the same SELECT list.

RANK and ROW_NUMBER differ when values tie. RANK can skip numbers after a tie. ROW_NUMBER does not. If the business wants one row per customer even when two orders share a timestamp, use ROW_NUMBER and add a unique column to the ordering so the choice is stable. Mention the tie. It is the follow-up.

How do you avoid SQL injection in an interview answer?

Do not build a query by gluing user text into a string. Pass the value as a parameter. In Python that means a placeholder and a separate argument tuple, not an f-string inside execute. The database then treats the input as data, even if someone types a quote and a DROP. Stored procedures do not magically save you if the procedure itself concatenates strings. The rule is the parameter, not the procedure badge.

Also say you grant the application user only the rights it needs. A login that can drop tables is a second bug. This question appears in Java, Python, and web fresher rounds because it is a security habit, not a vendor feature. Pair it with the Python interview questions if you write the query from Python, or with Java interview questions if you write it through JDBC or JPA.

How do you talk about SQL in a project?

Bring one schema with two or three tables. Name the primary keys and the foreign key. Show one query you actually used: a join, a group, and a filter. Then show one wrong result you caught, such as a double count after a join or a NULL that vanished from an inner join. Interviewers remember the bug you fixed more than the tool logo on your slide.

If the role is analytics, connect this page to data analyst interview questions and to Power BI interview questions. The SQL is what makes the dashboard true. A visual that sums the wrong grain is a SQL problem wearing a chart. If you are still building the skill, Python training and a deliberate SQL practice block belong together, and placement preparation is where you rehearse saying the query out loud.

Practise on a real engine, not on a screenshot. Create the tables, insert a NULL, insert a duplicate, and run the join. The day you see the extra row yourself, the interview answer becomes short, because you are describing an event rather than a definition.

What should a fresher say about normalisation?

Normalisation means you stop storing the same fact in several places where it can disagree. First normal form asks for one value per cell, not a comma-separated list of phone numbers. Second normal form matters when a key is composite: every non-key column should depend on the whole key, not on part of it. Third normal form asks that non-key columns depend on the key, not on each other. The fresher example is a student table that also stores the department name and the department head. The head depends on the department, not on the student, so the department belongs in its own table and the student stores a department id.

Say the trade-off. A highly normalised schema is safer to update and needs more joins to report. A reporting table sometimes repeats a name on purpose so a dashboard stays simple. That copy is a choice you can explain, not an accident. If you cannot explain where the copy is updated, it is an accident. Interviewers are listening for that distinction.

You will not be asked to recite the definitions of fourth and fifth normal form in a typical fresher round. If you are, connect them to “do not store two independent facts in one row” and offer an example rather than a number. An example of a student and a department beats a number you cannot illustrate.

A seven-day SQL practice plan

Day one is SELECT, WHERE, ORDER BY, and NULL, including a filter that uses IS NULL. Day two is inner and left joins on a schema you create, plus the “no matching child” pattern. Day three is GROUP BY, COUNT, SUM, and HAVING, with a deliberate double-count bug you then fix using COUNT DISTINCT or a pre-aggregated join. Day four is primary, unique, and foreign keys, then one index on a column you filter. Day five is DELETE inside a transaction, with a SELECT count first, and a rollback you actually run. Day six is one window function: latest row per customer. Day seven is a mixed mock where you speak the business sentence and then write the query without notes.

Keep a note of the query you got wrong and the row that proved it. That note is your revision, not a longer list of question titles. When the interview asks something slightly different, you can adapt the pattern. Candidates who memorise twenty query screenshots cannot adapt the date filter. Candidates who have inserted their own NULL can.

If the same week includes Python or Power BI, do not drop SQL to watch another tool tour. The query is the shared skill. A chart, a notebook, and a Java repository all become easier when the grain of the table is obvious to you.

What is an execution plan, in words a fresher can use?

An execution plan is the database’s chosen steps for a query: which indexes it uses, which tables it scans, and how it joins. You read it when a query is slow, not as a decoration. A seek uses an index to jump near the rows. A scan reads a large portion of the table or index. A scan is not always bad. A tiny table can be scanned cheaply. A scan of a huge orders table, while you filter a selective customer id that has no index, is the case you would index. Say you would look at the plan before you add an index by superstition. If you have never opened a plan, say you would turn it on for the slow query and look for the thickest step. Do not invent percentages.

Also mention a function wrapped around a column in the WHERE clause, such as a date conversion on every row. That pattern can stop an index from being used. Filter on the bare column when you can, or precompute the value. This is a practical answer, and it matches the way analysts accidentally slow a report.

Related reading: Python interview questions, Power BI interview questions, Data analyst interview questions, Java interview questions.

These answers are a preparation guide for students and freshers, including learners at Asmorix in Pondicherry. A company may ask a different follow-up. This page is not a leaked paper and it is not a promise of a result. Say the short answer, show one example, and revise the same day any question you could not code or click.