Why Situational Questions Are Different
Technical SQL questions test whether you know the syntax. Situational questions test something else entirely: judgment under ambiguity, how you communicate with non-technical stakeholders, how you handle mistakes, and whether you can prioritize under real-world constraints. Interviewers ask these specifically because a candidate who can write a flawless recursive CTE can still be a poor hire if they can't explain a discrepancy to a confused VP or safely investigate a production incident without making it worse.
Each scenario below includes what the interviewer is actually listening for and a full sample answer written the way you'd actually say it out loud — not a bullet list to memorize, but a model of the reasoning process itself.
1. "A query that used to run in seconds now takes minutes. How do you approach it?"
What they're testing: Whether you have a real debugging process for performance, not just "add an index" as a reflex.
Sample answer: "I wouldn't guess — I'd run EXPLAIN (or EXPLAIN ANALYZE) first to see the actual query plan and find out whether it's doing a sequential scan where it should be using an index, or whether a join order changed. I'd also check if the data volume simply grew — sometimes a query didn't get slower, the table just got bigger. Common culprits I'd check for: a missing index on a join or WHERE column, a function applied to a column in the WHERE clause that prevents index use, or a new NULL-heavy column messing with an existing index. I'd fix the highest-impact issue first, re-run the plan to confirm the change worked, and only then consider structural options like adding an index, if the team agrees it's worth the write-performance tradeoff."
For the mechanics behind this answer, see our query optimization guide and indexes guide.
2. "You realize a report you already sent to leadership had incorrect numbers. What do you do?"
What they're testing: Ownership and communication under an uncomfortable situation, not just SQL debugging.
Sample answer: "First, I'd verify the error myself before saying anything — I don't want to raise an alarm over something that turns out to be a misunderstanding on my end. I'd re-run the query against a known-good reference point, or manually spot-check a handful of rows, to confirm something is actually wrong before going further. If it's real, I'd check the usual suspects first: did a join fan out and inflate a sum, did an aggregate silently drop rows with NULLs, or was there a timezone boundary issue in a date filter. Once I know the root cause, I wouldn't wait to be asked — I'd proactively message whoever received the report with three things: what was wrong, what the corrected numbers actually are, and why it happened, in plain language they can act on immediately. Afterward, I'd propose an actual prevention step, like a sanity-check query that compares row counts and totals against the last known-good version before any report goes out, so this doesn't quietly happen again."
The specific failure modes mentioned here are covered in our JOINs guide (join fan-out) and date functions guide (timezone boundaries).
3. "A stakeholder asks for 'a report on our top customers' with no further detail. What do you do?"
What they're testing: Whether you clarify ambiguous requirements before writing SQL, rather than picking an arbitrary interpretation and hoping it's right.
Sample answer: "I wouldn't start writing SQL immediately, because 'top customers' can mean at least four different things, and guessing wrong means redoing the whole thing later. I'd ask what 'top' means to them specifically — total revenue, order frequency, or recency of activity? I'd also ask over what time window, since 'top customers all-time' and 'top customers this quarter' can be completely different lists. And I'd clarify what counts as a single customer, especially if the same person has multiple accounts or a household shares multiple emails. If I really needed to produce something quickly before getting an answer, I'd default to total revenue over the trailing twelve months as the most common definition, state that assumption explicitly in the deliverable, and flag that I'm happy to adjust once they confirm what they actually meant."
This kind of segmentation judgment is covered in more depth in our RFM analysis guide.
4. "You need to run a bulk UPDATE on a production table with millions of rows. How do you approach it?"
What they're testing: Risk awareness around destructive operations at scale.
Sample answer: "Before I touch anything, I'd write the equivalent SELECT with the exact same WHERE clause I plan to use in the UPDATE, and actually look at the rows it returns, so I know precisely what I'm about to change and how many rows are affected. I'd wrap the actual UPDATE in a transaction so I can roll it back immediately if the affected row count looks off. Given the table has millions of rows, I wouldn't run this as one giant statement — I'd batch it, maybe ten or twenty thousand rows at a time, so I'm not holding a long lock that blocks other production traffic the whole time. I'd also make sure the update is safe to re-run — for example, if it's a relative change like multiplying a value, I'd guard it so running it twice by accident doesn't double-apply. And before any of this, I'd confirm there's a recent backup or point-in-time recovery option, just in case something still goes wrong that I didn't anticipate."
See our transactions guide and idempotent SQL guide for the underlying techniques.
5. "You're asked to investigate a data discrepancy between two systems that are supposed to agree. How do you approach it?"
What they're testing: Systematic reconciliation thinking, not a single query trick.
Sample answer: "I'd start at the aggregate level rather than jumping into row-by-row comparison — comparing total row counts and total sums between the two systems tells me roughly where the gap is before I spend time figuring out why. Once I have a sense of scale, I'd do a full outer join between the two sources on whatever shared key exists, which directly surfaces the specific records that exist in one system but not the other, rather than me guessing. From there I'd check the usual causes: a timezone difference in how each system timestamps events, a subtly different definition of what counts for the metric, or one system reflecting a snapshot from midnight while the other is closer to real time. Once I actually find the root cause, I'd document it clearly, because these discrepancies tend to resurface later if the explanation isn't written down somewhere both teams can find it."
6. "You inherit a database with zero documentation and need to understand it quickly. How do you approach it?"
What they're testing: How you approach an unfamiliar, messy real-world system rather than a clean interview schema.
Sample answer: "I wouldn't try to fully map the schema before doing anything useful — that takes too long and I'd probably get details wrong anyway. I'd start by querying the database's own metadata: which tables actually have data and reasonable row counts versus ones that look abandoned, and what foreign key relationships exist, since those tell me the real shape of the data model faster than any diagram would. If I have access to query logs or slow-query logs, I'd look at what the application is actually reading and writing day to day, since that tells me what's actually load-bearing versus legacy. I'd build my understanding incrementally as I go, documenting what I learn so the next person doesn't have to repeat the same archaeology."
Common Mistakes Candidates Make on Situational Questions
- Jumping straight to a query without clarifying an ambiguous request first — signals a lack of real-world experience with messy requirements.
- Being vague ("I'd check the performance," "I'd look into the data") instead of naming specific commands, concepts, or root causes, the way each sample answer above does.
- Not mentioning communication at all — many of these scenarios are as much about how you'd talk to a stakeholder or teammate as about the SQL itself.
- Refusing to acknowledge trade-offs — presenting a fix as if it has no downsides makes an answer sound rehearsed rather than genuinely experienced.
- Skipping the prevention step — stopping at "here's how I'd fix it" without addressing how to stop it from recurring leaves the answer feeling incomplete to an experienced interviewer.
How to Prepare for These Questions
- Practice saying your answer out loud, not just thinking it — these sample answers are written the way you'd actually speak, and that's a different skill than writing a bullet list.
- Swap in a real detail from your own experience wherever possible — a genuine specific beats a polished generic answer every time.
- Notice that every sample answer above names something concrete (a command, a guide, a specific failure mode) rather than staying abstract — that's the single biggest differentiator between a strong and a weak answer to the same question.
Frequently Asked Questions
Do situational questions replace technical SQL questions in an interview?
No — they're typically asked alongside technical questions, often in a separate portion of the interview loop specifically focused on judgment and communication, or woven into a technical question as a follow-up ("and what would you do if this query needed to run against a live production table with no maintenance window?").
Is it okay to say "I don't know" to part of a situational question?
Yes, when genuine — a candidate who says "I haven't dealt with that specific case, but here's how I'd reason about it" is usually viewed far more favorably than one who bluffs confidently through an unfamiliar situation.
Practice Applying This Judgment
Situational fluency comes from combining real technical knowledge with practiced communication — not from memorizing scripted answers. Build the underlying technical foundation with our SQL practice questions, and apply it to realistic, messy scenarios in our case studies. For the pattern-recognition approach to technical questions that often accompany these, see our FAANG SQL interview pattern guide. Ready for six more scenarios — deadlocks, stakeholder pushback, and messy upstream data? Continue to Part 2 of this guide.