yoklainterview sim
ProgressHistory

Backend Databases / SQL Interview Questions

75 verified Backend Databases / SQL interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Databases / SQLDifficulty 1
What does defining a PRIMARY KEY on a table column guarantee?
  • aValues are unique, but NULLs are allowed
  • bValues are unique and cannot be NULL✓
  • cValues cannot be NULL, but duplicates are allowed
  • dValues are automatically generated as an incrementing sequence
Explanation:A primary key combines a uniqueness constraint with NOT NULL. Auto-increment behavior (d) is a separate feature (SERIAL / IDENTITY / AUTO_INCREMENT) that is often used together with primary keys but is not implied by them.
Databases / SQLDifficulty 1
In the query SELECT u.name, o.total FROM users u LEFT JOIN orders o ON o.user_id = u.id, which rows appear in the result?
  • aOnly users who have at least one order
  • bOnly orders that belong to an existing user
  • cAll users; order columns are NULL for users without orders✓
  • dAll users and all orders, even when nothing matches
Explanation:LEFT JOIN keeps every row of the left table (users). Users without a matching order still appear, with the order columns filled as NULL. Option (a) describes INNER JOIN, and (d) describes something closer to a FULL OUTER JOIN.
Databases / SQLDifficulty 2
The email column contains some NULL values.
SELECT COUNT(*), COUNT(email) FROM users;

How do the two counts differ?
  • aThey are always equal
  • bCOUNT(*) counts all rows; COUNT(email) skips rows where email is NULL✓
  • cCOUNT(email) also counts NULLs but ignores duplicate emails
  • dCOUNT(*) is slower because it has to read every column
Explanation:When given a column argument, aggregate functions ignore NULLs, so COUNT(email) counts only rows with a non-NULL email. COUNT(*) counts rows regardless of column values — and it does not need to read all columns, so (d) is a common myth. Ignoring duplicates would require COUNT(DISTINCT email), so (c) is wrong.
Databases / SQLDifficulty 2
In a query that uses GROUP BY, what is the difference between WHERE and HAVING?
  • aWHERE filters rows before grouping; HAVING filters groups after aggregation✓
  • bHAVING filters rows before grouping; WHERE filters the aggregated results
  • cThey are interchangeable as long as the query has GROUP BY
  • dWHERE works only on indexed columns; HAVING works on any column
Explanation:WHERE runs first and eliminates individual rows before they are grouped. HAVING runs after aggregation and can therefore filter on aggregate results like COUNT(*) or SUM(total). Indexes (d) are irrelevant to which clause you can use.
Databases / SQLDifficulty 2
SELECT department, name, COUNT(*)
FROM employees
GROUP BY department;

What happens when this query runs on PostgreSQL?
  • aIt returns one row per department with an arbitrarily chosen name
  • bIt returns every employee together with their department's row count
  • cIt fails: name is neither in GROUP BY nor inside an aggregate function✓
  • dIt fails: COUNT(*) cannot be selected together with other columns
Explanation:Standard SQL requires every selected column to appear in GROUP BY or inside an aggregate. PostgreSQL enforces this and raises an error for name. Option (a) describes MySQL's historical loose mode (ONLY_FULL_GROUP_BY disabled); (d) is wrong because COUNT(*) combines fine with properly grouped columns.
Databases / SQLDifficulty 2
Which statement about PRIMARY KEY and UNIQUE constraints is correct?
  • aA table can have multiple primary keys but only one unique constraint
  • bUNIQUE implies NOT NULL, just like a primary key does
  • cA primary key must be a single column; UNIQUE can span multiple columns
  • dA table can have only one primary key but multiple unique constraints✓
Explanation:A table has at most one primary key (which may be composite, so (c) is wrong), while any number of UNIQUE constraints can coexist. Unlike a primary key, UNIQUE does not imply NOT NULL, so (b) is wrong.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview