The SQL interview question that predicts who finds the bug
Most SQL questions for QA test whether you remember JOIN syntax. The ones that matter test whether you'd think to check the database at all. Ten years of interviewing, and here's what actually separates candidates.
A user saves their profile. The page says "Saved." They move on.
The field is empty in the database. The backend returned 200 on a request that changed nothing, and the interface, having no reason to doubt a 200, believed it. Nobody notices for a week, until a customer does.
I've watched this exact bug slip past testers who were perfectly competent at the interface. It slipped past because nobody looked at the one place that would have shown it immediately: the table itself.
The wrong question, and why it's everywhere
"Do you know SQL?" is a bad interview question, and most SQL questions for QA are just that one dressed up. Ask someone to define a JOIN and they'll define a JOIN. It tells you they've seen a tutorial. It doesn't tell you they'd think to run one at 4pm on a Tuesday when a bug report doesn't make sense from the interface alone.
The useful version of this question isn't about syntax. It's about instinct — does this person reach for the database when the interface goes quiet, or do they only ever look at what's drawn on screen?
What actually needs testing
The real job is small. A QA engineer doesn't need to write a query with three subqueries and a window function. They need four things, applied at the right moment:
SELECT with WHERE. Not the syntax — everyone can write that after five minutes of practice. The judgment is knowing when to check: after every "success" message that touches persistence, not just when something visibly breaks.
JOIN across two tables. The profile-saved bug above is really a two-table problem: does the row in profiles actually match what the row in audit_log says happened. A candidate who's only ever queried one table at a time won't think to check the seam between two.
Test data setup. You need a user with an expired subscription, three orders, and one refunded line item. Building that through the UI takes half a day. One INSERT takes a minute. This isn't a nice-to-have skill — it's the difference between testing an edge case and skipping it because it was too annoying to set up.
COUNT with GROUP BY. The question that catches silent data corruption: "how many orders does this user have according to the orders table, versus what the dashboard says." When those two numbers disagree, you've found something an interface test would never catch.
Five questions, and what each one is actually listening for
"A user says they saved their settings, but when they come back the settings are gone. Where do you look first?" Listening for: do they say "the database" without prompting, or do they only offer to "try it again in the browser." The second answer means they've never once needed to look past the interface, which is a real gap on any product with a backend.
"Write a query to find every order placed by a user with an expired subscription." Listening for: not whether the syntax is perfect — whether they build the query out loud, table by table, rather than freezing on a blank editor. The freeze usually means they've read about JOINs, not written one under any pressure.
"The dashboard shows 47 active users. How would you verify that number is actually correct? Listening for: SELECT COUNT(*) with the right filter, compared against what the dashboard claims. This is the single fastest way to catch a metric that's silently wrong, and it's shockingly rare for candidates to reach for it unprompted.
"You need to test a discount code that only applies to users with three or more previous orders. How do you get a test user in that state without placing three real orders through the UI?" Listening for: whether "just insert the rows" occurs to them at all. If the only answer is "I'd manually go through checkout three times," that's an hour lost on every test cycle that a two-minute query would have saved.
"What's the difference between testing through the interface and testing at the database level, and when would you do each?" Listening for: an actual opinion, not a recitation. The interface tells you what a user experiences. The database tells you what's true. A tester who only trusts one of the two will eventually ship a bug the other one would have caught in seconds.
What this isn't testing
Not a computer science degree. Not "do you know what a foreign key is" as trivia. The bar for a QA engineer is four query shapes, applied with judgment about when to reach for them — not a database administrator's depth, and treating it that way in an interview filters out people who'd do the job perfectly well.
Same instinct shows up on the API side — see the API testing question that separates "read about it" from "done it" for the equivalent when there's no database in sight.
Practice questions like these — scored on the actual reasoning, not just the syntax — against real QA manual interview questions, with the free demo. No signup required.