SQL Interview Questions for QA Engineers: What to Expect and How to Answer

Most SQL interview questions for QA roles come down to four patterns: SELECT with WHERE to verify a record was saved, LEFT JOIN to find orphaned records, COUNT with GROUP BY to find duplicates, and DELETE to clean up test data. Interviewers want practical answers tied to testing scenarios, not textbook definitions. This article covers the ten questions that actually appear at junior, mid-level, and senior QA screens, with answers framed around common testing use cases.

What Level of SQL Do QA Interviews Test?

For most QA automation roles:

• Junior: SELECT, WHERE, basic filtering, understanding what a JOIN does conceptually
• Mid-level: JOINs (INNER, LEFT), GROUP BY, aggregate functions (COUNT, SUM, AVG), subqueries
• Senior: Window functions, query optimization concepts, explaining query plans

If the job description mentions "database testing" or "data validation," expect deeper SQL questions. Otherwise, junior-to-mid level is typical.

Core Questions and Answers

1. "What SQL queries do you use most often in testing?"

2. "How would you verify a user was created correctly after a registration?"

-- Find the user and check key fields
SELECT id, email, role, is_active, created_at
FROM users
WHERE email = 'test_user@example.com';

Then verify:

• Row exists (if 0 rows, the registration didn't write to the DB)
• email matches what was submitted
• role is 'member' (not 'admin' by default)
• is_active is false (if email confirmation is required before activation)
• created_at is recent (not a pre-existing row)

3. "What's the difference between WHERE and HAVING?"

-- WHERE: filter individual rows
SELECT user_id, amount FROM orders WHERE status = 'completed';

-- HAVING: filter groups (after GROUP BY)
SELECT user_id, COUNT(*) as order_count
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 5;
-- Returns users who have more than 5 orders

4. "Explain the difference between INNER JOIN and LEFT JOIN."

-- Which users have placed at least one order?
SELECT u.email
FROM users u
INNER JOIN orders o ON u.id = o.user_id;
-- Only users who have orders

-- Which users have NEVER placed an order?
SELECT u.email
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;
-- Users with no matching order (the NULL check)

5. "How would you find duplicate records in a table?"

SELECT email, COUNT(*) as count
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

This finds emails that appear more than once. Replace email with whatever field should be unique.

6. "What's the difference between DELETE and TRUNCATE?"

| | DELETE | TRUNCATE |

|-|--------|---------|

| Removes | Specific rows (with WHERE) or all rows | All rows (no WHERE clause possible) |

| Rollback | Can be rolled back (in a transaction) | Generally cannot (DDL operation) |

| Triggers | Fires row-level DELETE triggers | Does not fire triggers |

| Speed | Slower for large tables | Much faster |

| Use in testing | Set up/tear down specific test data | Reset entire tables between test runs |

-- Remove just the test user
DELETE FROM users WHERE email LIKE 'test_%@example.com';

-- Clear the entire test_runs table between suites
TRUNCATE TABLE test_runs;

7. "How do you use SQL for test data setup?"

-- Setup: create a test user
INSERT INTO users (email, password_hash, role, is_active)
VALUES ('playwright_test@example.com', '$2b$10$hashedpassword', 'member', true);

-- Verify: check it exists with right values
SELECT id, email, role FROM users WHERE email = 'playwright_test@example.com';

-- Teardown: remove it
DELETE FROM users WHERE email = 'playwright_test@example.com';

8. "How would you find all orders placed in the last 7 days?"

SELECT id, user_id, total, status, created_at
FROM orders
WHERE created_at >= NOW() - INTERVAL '7 days'
ORDER BY created_at DESC;

(Syntax varies slightly by database: PostgreSQL uses INTERVAL '7 days', MySQL uses INTERVAL 7 DAY, SQL Server uses DATEADD(day, -7, GETDATE()))

9. "What's a subquery and when would you use one?"

A subquery is a query inside another query:

-- Find users who have placed orders over $100
SELECT email FROM users
WHERE id IN (
    SELECT user_id FROM orders WHERE total > 100
);

10. "How do you verify referential integrity after a delete?"

If you delete a user, you might want to verify their related records were also deleted (cascade delete) or that foreign key constraints prevented orphaned records.

-- Confirm user is deleted
SELECT COUNT(*) FROM users WHERE id = 123;
-- Expected: 0

-- Confirm related orders were also deleted (cascade)
SELECT COUNT(*) FROM orders WHERE user_id = 123;
-- Expected: 0 (if cascade delete is configured)

-- OR confirm orders still exist (if soft-delete is used)
SELECT id, user_id, deleted_at FROM orders WHERE user_id = 123;
-- Expected: rows with deleted_at set

Practical Tips for the Interview

• Start by saying what the query should do before writing it
• Write the basic structure first (SELECT ... FROM ... WHERE ...), then add complexity
• Mention if you'd want to test the query on real data before finalizing

• Say "I'd check the documentation for exact syntax, but the approach would be..." and explain the logic
• This is much better than guessing wrong syntax and defending it

• "My experience is mainly with PostgreSQL, but the concept is the same in MySQL — the syntax for date arithmetic is slightly different"
• Showing awareness of cross-database differences is a plus

Quick Reference: Queries QA Engineers Use Most

-- Verify a record was created
SELECT * FROM table WHERE id = 123;

-- Check count (record created or deleted)
SELECT COUNT(*) FROM orders WHERE user_id = 456;

-- Find duplicates
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;

-- Find orphaned records (should not exist)
SELECT o.* FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE u.id IS NULL;

-- Recent records
SELECT * FROM logs WHERE created_at > NOW() - INTERVAL '1 hour';

-- Clean up test data
DELETE FROM users WHERE email LIKE 'test_%';

SQL in QA interviews is about demonstrating that you can verify and manipulate data to support testing — not write production database schemas. Focus on the practical patterns above and you'll be well prepared.