Here’s what separates a strong Database Analyst interview from a weak one: it’s rarely the SQL. Most candidates who make it to interview stage can write a join and a GROUP BY. What actually gets tested — sometimes explicitly, often just through how you answer — is whether you investigate or whether you just report.
Take the classic scenario: “the dashboard shows sales dropped 18% this week.” One candidate says “I’d rebuild the dashboard to make the trend clearer.” Another says “I’d check exactly when the drop started, whether it’s real or a data pipeline issue, whether it’s broad or concentrated in one segment, and only then decide what — if anything — needs building.” Same prompt, completely different instinct. The second answer is what this whole role actually is.
This list is built around that distinction. Split into Beginner (1–30), Intermediate (31–70), and Advanced (71–100), it mixes technical SQL/analytics knowledge with genuine scenario-based and mindset questions — because a real Database Analyst interview does exactly that, and you should walk in ready for both.
Beginner Level
1. What does a Database Analyst actually do, day to day? Pulls, cleans, analyzes, and interprets data to answer business questions — writing queries, building reports and dashboards, checking data quality, and communicating findings to non-technical stakeholders in a way that actually informs a decision, not just presenting numbers.
2. What’s the difference between a Database Analyst and a Data Analyst? The titles overlap heavily and often mean the same thing depending on the company, but where there’s a distinction, a Database Analyst tends to work closer to the actual database layer — schema, query performance, data structure — while a Data Analyst title sometimes leans more toward the reporting/visualization/statistics side. In practice, expect the actual responsibilities to matter far more than the title.
3. What is a primary key, and why does it matter for analysis? A column (or set of columns) uniquely identifying each row in a table. It matters for analysis because it’s what lets you correctly join tables without accidentally duplicating or losing rows — a wrong join key is one of the most common, silent sources of a wrong analysis.
4. What’s the difference between INNER JOIN and LEFT JOIN, and why does the choice matter for a real analysis? INNER JOIN returns only rows with a match in both tables. LEFT JOIN returns every row from the left table regardless of a match. The choice matters because using INNER JOIN when you actually needed LEFT JOIN can silently drop real data — like customers with zero orders disappearing from a “customers by order count” report, understating your true customer base without any error being thrown.
5. What’s the difference between WHERE and HAVING? WHERE filters individual rows before grouping. HAVING filters groups after a GROUP BY, typically based on an aggregate condition like COUNT(*) > 10 — you can’t put an aggregate condition in WHERE.
6. What is a GROUP BY clause used for, in plain terms? It collapses rows sharing the same value in specified columns into summary rows, usually paired with an aggregate function — “total sales by region” is a GROUP BY region with SUM(sales).
7. What’s the difference between COUNT(*) and COUNT(column_name)? COUNT(*) counts every row regardless of NULLs. COUNT(column_name) counts only rows where that specific column is not NULL — a subtle but important difference when a dataset has missing values you need to account for correctly.
8. What is a NULL value, and why does it require special handling in analysis? NULL represents an unknown or missing value, not zero or an empty string. It requires special handling because standard comparisons don’t work as expected — WHERE column = NULL never returns anything; you need IS NULL — and NULLs silently get excluded from most aggregate calculations unless you explicitly account for them.
9. What is a subquery? A query nested inside another query, used to compute an intermediate result the outer query then uses — common when you need to filter based on an aggregated or derived value that can’t be expressed in a single simple WHERE clause.
10. What’s the difference between UNION and UNION ALL? UNION combines two result sets and removes duplicates. UNION ALL combines them without removing duplicates, which is faster — use UNION ALL whenever you know there won’t be duplicate rows or don’t care about them.
11. What is a KPI, and how do you decide if a metric is a good KPI? A Key Performance Indicator — a specific, measurable value tracking progress toward a business goal. A good KPI is directly tied to a real business objective, is actually actionable (someone can do something differently based on it moving), and isn’t easily gamed or misleading in isolation.
12. What’s the difference between a fact table and a dimension table? A fact table holds measurable, quantitative data — transactions, sales amounts. A dimension table holds descriptive context — customer details, product names, dates — used to filter and group the facts.
13. What is data cleaning, and why does it take up so much of an analyst’s time in practice? The process of identifying and correcting (or removing) inaccurate, incomplete, duplicate, or inconsistent data before analysis. It takes up a large share of real work time because raw, real-world data is almost never clean — different systems capture the same entity inconsistently, values go missing, formats vary — and an analysis built on unclean data is only as trustworthy as the cleaning that came before it.
14. What’s the difference between structured and unstructured data? Structured data fits neatly into rows and columns with a defined schema (a database table). Unstructured data has no predefined format (free text, images, documents) — an analyst working primarily in databases deals mostly with structured data, but increasingly needs to at least understand where unstructured sources fit into a broader picture.
15. What is a pivot table, and when would you use one? A tool that reshapes data by turning row values into columns, typically summarizing with an aggregate — used to quickly compare a metric across two dimensions at once (like sales by month across product categories) without writing a complex query for every combination.
16. What’s the difference between a mean, median, and mode, and why does it matter which one you report? Mean is the average, median is the middle value when sorted, mode is the most frequent value. It matters because a mean can be badly skewed by outliers (a handful of very large orders inflating “average order value”), while median often gives a more honest sense of the “typical” case — choosing the wrong one can make a report genuinely misleading.
17. What is an outlier, and should you always remove them? A data point significantly different from the rest of the dataset. No — outliers should be investigated before being removed; sometimes they’re a data entry error worth excluding, but sometimes they’re the single most important, real signal in the dataset (a fraud case, a genuine spike worth understanding), and removing them without checking which one it is can hide the real story.
18. What’s the difference between correlation and causation, and why is this distinction something an analyst has to actively defend in meetings? Correlation means two variables move together; causation means one actually causes the other. It’s something an analyst has to actively defend because stakeholders very naturally jump from “these two things are correlated in the data” to “so this one caused that one” — and it’s genuinely part of the job to push back on that leap when the data doesn’t actually support it.
19. What is a data dictionary, and why would you want one even for a small team? A documented reference describing what every table and column actually means. Even a small team benefits because “what does this column actually represent” is one of the most common, time-wasting questions in any data team, and a shared reference avoids relying on tribal knowledge or repeatedly asking whoever happens to remember.
20. What’s the difference between a report and a dashboard? A report is typically a more static, often periodic summary answering a specific question. A dashboard is an interactive, often real-time or near-real-time view designed for ongoing monitoring — different tools for different needs, and building a dashboard when a one-time report would’ve answered the question is a common, avoidable overinvestment.
21. What is data validation, and what’s a simple example? Checking that data meets expected rules or constraints before trusting it — a simple example is confirming a “percentage” column never contains a value below 0 or above 100, or that an “order date” is never later than today’s date.
22. What’s the difference between a categorical and a numerical variable? A categorical variable represents groups or labels (region, product category). A numerical variable represents a measurable quantity (revenue, quantity sold) — the distinction matters because it determines what kind of chart, aggregation, or statistical approach actually makes sense for that column.
23. What is a time series, and what makes analyzing it different from analyzing a static snapshot? Data points indexed in time order — daily sales, monthly signups. It’s different from a static snapshot because trend, seasonality, and the specific timing of a change all matter, not just the current value — a single number without its trend context can be genuinely misleading.
24. What’s a simple way to explain the difference between “data” and “information” to a non-technical stakeholder? Data is raw — a list of numbers or facts with no interpretation attached. Information is data that’s been processed and given context so it actually means something to the person receiving it — “47” is data; “sales dropped 47% compared to last month” is information.
25. What is a sample versus a population, in analysis terms? A population is the complete set of data you’re interested in. A sample is a subset used to represent that population when analyzing the full population isn’t practical — the analyst’s job includes making sure a sample is actually representative, not just convenient.
26. What’s the difference between a leading and a lagging indicator? A leading indicator tends to predict a future outcome (website traffic predicting future sales). A lagging indicator confirms something that already happened (quarterly revenue confirming a trend that already played out) — both matter, but they answer different questions, and confusing which one you’re looking at leads to bad timing decisions.
27. What is data granularity, and why does it matter when building a report? The level of detail at which data is recorded — one row per transaction versus one row per daily summary, for instance. It matters because you can always aggregate up from fine granularity to coarse, but you can rarely go back down from a coarse summary to finer detail — choosing too coarse a granularity upfront can quietly close off analysis someone needs later.
28. What’s a basic checklist you’d run through before trusting a number you’re about to report to a stakeholder? Does the row count and total make sense against what I’d roughly expect? Are there unexpected NULLs or duplicates in the join keys? Does the time range actually cover what I intended? Would this number survive someone double-checking it independently? — a quick sanity pass before presenting anything, not after someone questions it.
29. What is a data source, and why would an analyst care about more than one existing for “the same” data? Where a specific piece of data originates — a specific database, system, or file. An analyst cares about multiple sources for “the same” data because different systems often capture it slightly differently (a customer count from the CRM versus the billing system rarely match exactly), and picking the wrong source, or not knowing which is authoritative, is a common cause of numbers that don’t reconcile.
30. What’s a reasonable first response when a stakeholder asks you for “all the data” without a specific question in mind? Ask what decision they’re actually trying to make or what problem they’re trying to solve — “all the data” is rarely genuinely what’s needed, and a quick clarifying conversation upfront usually saves significant wasted effort building something that doesn’t actually answer their real question.
Intermediate Level
31. Write a query to find the second-highest salary in an Employees table, and explain your approach.
SELECT MAX(Salary) AS SecondHighestSalary
FROM Employees
WHERE Salary < (SELECT MAX(Salary) FROM Employees);
The logic: find the overall max, then find the max of everything strictly less than that — which is the second-highest. I’d also mention DENSE_RANK() as the more flexible, scalable alternative if you need the Nth highest generally, not just the second.
32. What’s the difference between RANK(), DENSE_RANK(), and ROW_NUMBER(), with a practical example of when the difference actually matters? ROW_NUMBER() gives strictly unique sequential numbers even for tied values. RANK() gives ties the same rank but skips subsequent numbers (1,1,3). DENSE_RANK() gives ties the same rank without skipping (1,1,2). This matters practically in something like a “top 3 salespeople” report — if two people are tied for first, RANK() means there’s no “2nd place” at all, while DENSE_RANK() would still show a 2nd place; picking the wrong one changes who actually appears in your “top 3.”
33. How would you find duplicate records in a table?
SELECT email, COUNT(*)
FROM Customers
GROUP BY email
HAVING COUNT(*) > 1;
This finds the duplicate values; to see the actual duplicate rows, I’d follow up with a query joining back to the full table on that email, or use ROW_NUMBER() partitioned by the duplicate key to identify which specific rows to review or remove.
34. What’s your process for investigating a metric that suddenly looks wrong compared to yesterday’s report? First confirm it’s real, not a reporting artifact — check the underlying row counts and raw data for the affected period before assuming the business number itself changed. Then check whether a data pipeline or ETL job failed or ran late, whether a schema or definition change happened upstream, and only once I’ve ruled out a data issue would I treat it as a genuine business signal worth escalating.
35. What is a CTE (Common Table Expression), and why might you prefer it over a subquery for a complex analysis query? A named, temporary result set defined with WITH ... AS, scoped to a single query. I’d prefer it over a deeply nested subquery mainly for readability — breaking a complex analysis into named, logical steps makes it much easier for someone else (or future you) to follow the reasoning, especially in a query you’ll need to revisit or hand off.
36. How would you calculate month-over-month growth percentage in SQL?
SELECT month, revenue,
(revenue - LAG(revenue) OVER (ORDER BY month))
/ LAG(revenue) OVER (ORDER BY month) * 100.0 AS mom_growth_pct
FROM MonthlyRevenue;
LAG() pulls the previous row’s value within the ordered window, which is exactly what a period-over-period comparison needs.
37. What’s the difference between a database view and a materialized view, and when would you recommend one over the other for a recurring analysis? A regular view is just a saved query, recalculated every time it’s used. A materialized view physically stores its result and is refreshed on a schedule. I’d recommend a materialized view for a genuinely expensive, frequently-reused aggregation where near-real-time freshness isn’t required, and a regular view when the underlying data needs to always be current or the query isn’t expensive enough to justify the storage and refresh overhead.
38. A stakeholder asks you why two reports showing “total revenue” for the same month don’t match. How would you investigate? I’d check whether the two reports are pulling from the same underlying source or two different systems, whether they’re using the same definition of “revenue” (gross vs net, including or excluding refunds/taxes), whether the date filtering logic matches exactly (calendar month vs fiscal month, time zone handling), and whether one report includes data still being finalized while the other’s a locked snapshot — mismatched numbers almost always trace back to one of these definitional or timing differences, not a genuine calculation error.
39. What’s the difference between a scheduled report and an ad hoc analysis, and how does that distinction affect how much rigor you’d apply to each? A scheduled report runs repeatedly and gets relied upon over time, so it deserves more upfront rigor, documentation, and validation since a mistake compounds every time it runs. An ad hoc analysis answers a one-time question and can reasonably be built faster and more loosely — though I’d still sanity-check the actual numbers before presenting either.
40. How would you handle a situation where the data needed to answer a stakeholder’s question simply doesn’t exist in the current database? I’d be upfront about the gap rather than approximating silently, explain what would be needed to actually capture that data going forward, and offer the closest available proxy or partial answer if one exists — being clear about its limitations — rather than either refusing to help at all or presenting an approximation as if it were the real answer.
41. What’s your approach to writing a query that needs to run efficiently against a very large table, beyond just “add an index”? I’d check whether the query is filtering on a genuinely selective condition that could use an index seek, avoid SELECT * in favor of only the columns actually needed, consider whether the date range or filter could be narrowed further given the actual business question, and check the execution plan for an unexpected scan or a non-sargable predicate (like a function wrapped around a filtered column) before assuming indexing alone will solve it.
42. What is data lineage, and why would you want to trace it for a specific report? Tracking where a specific piece of data originated and what transformations it went through to reach its current form. You’d want to trace it when a number looks wrong and you need to find exactly which step in the pipeline introduced the problem, rather than guessing at the whole chain from source to report.
43. How would you explain a complex SQL query’s logic to a non-technical stakeholder who wants to understand how a number was calculated? I’d describe it in plain business terms — what data it’s pulling from, what it’s filtering out and why, how it’s grouping or calculating the final number — deliberately avoiding SQL syntax entirely, focusing on the logic rather than the code, since the stakeholder’s actual question is usually “can I trust this number and do I understand what it represents,” not “explain your JOIN syntax.”
44. What’s your process for deciding what chart type to use for a given dataset? I’d match the chart to what I’m trying to show — a trend over time gets a line chart, a comparison across categories gets a bar chart, a part-to-whole relationship (with few categories) gets a pie or donut chart, and a precise, detailed lookup gets a table instead of a chart at all — choosing based on the message, not on which chart looks most visually interesting.
45. Scenario: A dashboard shows sales dropped 18% this week. What’s your actual first move? Not rebuilding the dashboard, and not immediately alerting leadership either. First, I’d confirm the drop is real — check whether the data pipeline behind that dashboard ran successfully and completely for the period in question, since a partial or delayed data load can produce a fake-looking drop that isn’t a real business event at all. If the data is confirmed correct, I’d pinpoint exactly when the drop started (a specific day, a specific hour) and whether it’s broad across the whole business or concentrated in one region, product, or channel — that segmentation alone usually points straight at the actual cause (a site outage, a pricing change, a marketing campaign ending, a competitor’s promotion) far faster than staring at the aggregate number. Only after understanding the real cause would I decide whether a new dashboard view, an alert, or just a written explanation is actually the right response — building something new is a last step, not a first instinct.
46. What’s the difference between a leading question and a neutral question when gathering requirements from a stakeholder for a new report? A leading question assumes a specific answer or approach (“you want this broken down by region, right?”). A neutral question genuinely opens space for the stakeholder’s actual need (“what decision are you trying to make with this data?”) — leading questions risk building exactly what you assumed rather than what’s actually needed, especially when the stakeholder hasn’t fully articulated their own need yet either.
47. How would you approach validating a new report before sharing it broadly for the first time? I’d cross-check key totals against an independent source or a known reference number if one exists, spot-check a handful of individual records manually against the raw data to confirm the logic is doing what I think it’s doing, and specifically test edge cases (what happens with NULLs, what happens at period boundaries) rather than only testing against clean, typical data.
48. What’s your approach when a stakeholder pushes back on a number you’ve reported, insisting it’s wrong, but your investigation shows it’s correct? I’d walk through my methodology with them step by step rather than just repeating the number more firmly, specifically asking what number or source they were expecting and why, since that comparison often reveals the actual disagreement is about definition (are we counting the same thing) rather than a genuine calculation error on either side — staying curious about the discrepancy rather than defensive tends to resolve it faster.
49. What is data storytelling, and why does it matter beyond just having accurate numbers? Presenting data in a narrative structure that guides the audience toward understanding and, ideally, action — not just a wall of correct numbers. It matters because accurate data that’s poorly presented often fails to actually influence a decision, while a clear narrative (even around simpler analysis) tends to actually get acted upon, which is ultimately the point of the work.
50. How would you handle discovering a significant error in a report that’s already been shared with leadership? I’d correct it and communicate the correction promptly and transparently rather than quietly fixing it and hoping nobody notices, explain clearly what was wrong and what the corrected number actually is, and briefly note what caused the error and what you’re doing to prevent it recurring — being upfront about a mistake, handled well, tends to build more trust than it costs.
51. What’s the difference between descriptive, diagnostic, predictive, and prescriptive analytics? Descriptive answers “what happened” (last month’s sales). Diagnostic answers “why did it happen” (why sales dropped). Predictive answers “what’s likely to happen” (forecasted next month’s sales). Prescriptive answers “what should we do about it” (a recommended action based on the prediction) — most Database Analyst work lives primarily in descriptive and diagnostic, with predictive/prescriptive often belonging to a more specialized data science function, though the boundary varies by organization.
52. How would you approach analyzing customer churn, at a basic level? Define what “churn” actually means precisely first (no purchase in X days? explicit cancellation?), since an imprecise definition undermines everything built on top of it. Then I’d segment churned customers by characteristics (tenure, product usage, plan type) to look for patterns, and compare churned versus retained customers on those same dimensions to identify what’s actually different about the group that left.
53. What’s your approach to a stakeholder who wants a dashboard with 30 different metrics on one page? I’d push back gently but directly — ask what the top 3-5 decisions this dashboard needs to support, since a dashboard trying to serve every possible question usually ends up serving none of them well, and propose a focused primary view with the remaining detail available via drill-down or a secondary page, rather than building exactly what was requested without questioning whether it’ll actually be usable.
54. What is a funnel analysis, and what’s a common mistake analysts make when building one? Tracking how a group of users or events progresses (and drops off) through a sequence of steps — signup to purchase, for instance. A common mistake is defining the funnel steps too rigidly or too broadly, missing that users take genuinely different paths, which can make drop-off numbers look worse (or better) than the reality actually is.
55. How would you decide whether a change in a metric is statistically meaningful or just normal variation? I’d look at the metric’s typical historical volatility before reacting to a single data point — comparing the current change against the normal range of week-to-week or month-to-month fluctuation the metric usually shows, rather than treating any single up or down movement as automatically significant, since normal noise gets mistaken for a real signal far more often than people expect.
56. What’s your process for handling a dataset with a significant amount of missing values in a key column? I’d first understand why the data is missing — a systemic collection gap, a specific segment that genuinely doesn’t have that data, or a recent process change — since the right handling differs (excluding those rows, imputing a reasonable value, or flagging the gap explicitly in the report) depending on the actual cause, rather than defaulting to one blanket approach without understanding why the gap exists.
57. What’s the difference between a one-time data pull and building a repeatable, automated report — and how does that change your approach to writing the underlying query? A one-time pull can prioritize speed and can tolerate some manual cleanup after the fact. A repeatable report needs to handle edge cases robustly without manual intervention every time it runs — NULL handling, date boundary logic, and genuinely defensive query design matter much more, since nobody’s going to manually review and fix it every single time it executes.
58. How would you approach explaining a negative or disappointing result to a stakeholder in a way that’s honest but still constructive? I’d present the number clearly and honestly without softening or burying it, pair it with the context needed to understand why it happened (to the extent the data explains it), and where possible, frame the finding around what it suggests could be done next, rather than either sugar-coating a bad result or presenting it without any actionable context at all.
59. What’s your approach to prioritizing multiple competing data requests when you can’t get to all of them immediately? I’d ask each requester about the actual business urgency and decision timeline behind their request rather than defaulting to first-come-first-served, and communicate realistic timelines back clearly so people can plan around the actual queue rather than being left wondering — a request tied to an active, time-sensitive decision generally outranks one that’s exploratory or “nice to have.”
60. What’s the difference between a vanity metric and an actionable metric, and why does this distinction matter for a dashboard you’re designing? A vanity metric looks good and moves in an encouraging direction but doesn’t actually inform a decision (total lifetime pageviews). An actionable metric directly connects to something someone can do differently based on its value (conversion rate by traffic source). It matters because a dashboard full of vanity metrics feels informative but doesn’t actually drive better decisions — worth actively pushing a design toward the latter.
61. How would you approach validating whether a new data source (like a newly integrated third-party system) is trustworthy before building reports on top of it? I’d cross-check a sample of records from the new source against a known, trusted reference where one exists, look for obvious data quality red flags (unexpected NULL rates, implausible value ranges, duplicate records), and specifically test the actual joins/keys you’d need to use it alongside existing data before building anything significant on it, rather than assuming a newly integrated source is automatically as reliable as an established one.
62. What is data democratization, and what’s a real risk of doing it without adequate guardrails? Making data broadly accessible across an organization rather than gatekept by a small central team. A real risk without guardrails is inconsistent interpretation — many people independently calculating the same metric slightly differently, producing genuinely conflicting numbers across the organization with no single source of truth, which erodes trust in data generally rather than building it.
63. How would you handle a request to pull data that you suspect might be used to support a decision that’s already been made, rather than to genuinely inform one? I’d still provide accurate, honest data regardless of the suspected motive — an analyst’s job is to represent the data faithfully, not to shape it toward a predetermined conclusion — while being willing to note if the data doesn’t clearly support the direction being taken, which is sometimes the more valuable and harder contribution to make.
64. What’s the difference between a sample size that’s “big enough” and one that’s genuinely too small to trust, in a practical, non-statistician’s terms? A genuinely useful rule of thumb: does the finding hold up if you split the sample into two random halves and check each separately? If a “trend” disappears or reverses under that kind of stress test, the sample was likely too small or too noisy to draw a confident conclusion from in the first place — a practical sanity check even without formal statistical significance testing.
65. How would you approach a scenario where automating a previously manual report reveals the manual version had been wrong for months? I’d verify the automated version’s correctness thoroughly first (since automation revealing a discrepancy could mean either the old manual process or the new automated one is wrong), then communicate the discovery clearly and factually to whoever relied on the old numbers, focusing on the corrected go-forward number and impact rather than dwelling on assigning blame for the historical error.
66. What’s your approach to documenting a complex analysis so someone else could pick it up if you were unavailable? I’d document the business question being answered, the data sources and any non-obvious filtering or transformation logic applied, key assumptions made along the way, and where the final output lives — written for someone who understands the business but not necessarily every detail of how you built it, not just inline code comments only another analyst would follow.
67. How would you handle a stakeholder who consistently asks for data “as soon as possible” for requests that turn out not to be genuinely urgent? I’d have a direct, non-confrontational conversation about actual timelines and what “urgent” means for their specific decisions, and gently push for that context upfront on future requests — most people default to “ASAP” out of habit rather than genuine need, and a little clarifying conversation usually resolves it without it becoming a recurring friction point.
68. What’s the difference between reporting a metric and interpreting a metric, and why do stakeholders usually want both, even if they only explicitly ask for the number? Reporting is stating the value. Interpreting is explaining what it means and why it matters in context. Stakeholders usually want both because a bare number without interpretation often leaves them unsure what to actually do with it — part of the analyst’s real value is in the interpretation, not just accurate retrieval.
69. How would you approach a situation where you’re asked to analyze data you have real reservations about, due to a known collection or quality issue? I’d flag the known limitation clearly and upfront, before presenting any findings, rather than either refusing to do the analysis or presenting results without the caveat — a stakeholder can still often get directional value from imperfect data, as long as they genuinely understand its limitations rather than treating it as more precise than it actually is.
70. What’s your approach to staying current with a business’s evolving definitions and metrics as the company changes over time? I’d treat metric definitions as something requiring periodic, deliberate revisiting rather than a one-time setup — checking in with metric owners when the business itself changes (a new product line, a changed sales process) to confirm existing definitions and calculations still make sense, rather than assuming a metric built two years ago is still calculated the way the business actually needs it calculated today.
Advanced Level
71. Scenario: A dashboard shows sales dropped 18% this week, and leadership wants an explanation in the next hour. Walk through your complete process. First five minutes: confirm data completeness — check whether the ETL/pipeline behind this dashboard ran successfully for the full period, since a partial load is the single most common cause of a scary-looking drop that isn’t real. Next: pinpoint the exact timing — did it drop gradually or was there a specific cliff on a specific day/hour, since that timing often points directly at a cause (a site outage log, a pricing change deployment, a marketing spend cutoff). Then: segment — is the drop broad across every region/product/channel, or concentrated in one? A concentrated drop usually has a findable, specific cause; a broad drop suggests something more systemic (a market-wide event, a measurement change). With whatever’s found in that window, I’d give leadership an honest, appropriately-hedged answer within the hour — “here’s what we know for certain, here’s our leading hypothesis, here’s what we’re still confirming” — rather than either overpromising a fully diagnosed root cause I don’t actually have yet, or refusing to say anything until it’s perfectly certain, which isn’t realistic under a one-hour deadline.
72. Explain the difference in mindset between a Database Analyst who “reports numbers” and one who “drives decisions” — and describe a concrete behavior that distinguishes them. A numbers-reporter answers exactly the question asked and stops there. A decision-driver anticipates the actual follow-up question behind the stated request and proactively addresses it — if asked “what was revenue last quarter,” the decision-driver also notes how it compares to the prior quarter and to plan, and flags anything unusual worth the stakeholder’s attention, without being separately asked for that context. The concrete behavior: does the analyst’s output require the stakeholder to ask three follow-up questions to actually act on it, or does it anticipate those questions?
73. How would you design a data quality monitoring approach for a set of critical, business-facing reports, so problems are caught before a stakeholder notices them rather than after? I’d build automated validation checks running ahead of each report’s refresh — row count sanity bounds, key metric bounds (a percentage that should never exceed 100, a total that shouldn’t drop by more than some threshold without a specific flag), and null-rate monitoring on critical join keys — with alerting routed to the analyst/data team before the report goes out, rather than relying purely on a stakeholder noticing something looks wrong and asking about it after the fact, which is both slower and more damaging to trust.
74. Scenario: Two stakeholders each present a different number for “active users” in a leadership meeting, and both are technically correct based on their own definitions. How would you handle being asked to resolve this in real time? I wouldn’t declare either one wrong on the spot — I’d calmly surface that they’re using different definitions (perhaps 30-day active versus 7-day active, or including versus excluding a specific user segment), state both numbers with their actual definitions attached so the room understands why they differ, and offer to follow up with a recommendation for a single, agreed-upon standard definition going forward — the real fix here is a governance conversation after the meeting, not picking a winner live under pressure.
75. How would you approach building a report you strongly suspect will reveal poor performance for the team that requested it? Does that suspicion change how you build it? No — the analysis and query logic should be built with exactly the same rigor and objectivity regardless of what I expect the result to show; letting an anticipated uncomfortable finding change the methodology is exactly how trust in data erodes. What does change is how I communicate it — giving the requesting team a heads-up before it’s shared more broadly, so they’re not blindsided in front of leadership, and framing the finding constructively where genuinely warranted, without softening the actual numbers themselves.
76. Explain how you’d approach root-causing a genuine, confirmed metric drop when the obvious explanations (pipeline failure, a known business event) have all been ruled out. I’d move to systematic segmentation — breaking the metric down by every dimension available (geography, channel, customer segment, product, device type) looking for where the drop is concentrated versus where it’s absent, since an unexplained aggregate drop almost always has a specific pocket driving it that a top-level view obscures. I’d also check for anything that changed in the measurement itself around that time (a tracking change, a tagging update, a definition tweak) before concluding the business genuinely changed, since a silent measurement change is a surprisingly common false alarm that looks identical to a real business drop at the aggregate level.
77. How would you handle a scenario where fixing a long-standing bug in a report’s calculation would change a historical trend that leadership has referenced in prior public communications or board materials? I’d fix the underlying calculation regardless — continuing to report a known-wrong number to preserve consistency with past communication compounds the problem rather than solving it — but I’d handle the communication of that fix carefully: clearly document the change, provide both the old and corrected historical series with the fix’s effective date noted, and make sure whoever owns external/board communication is informed proactively before they encounter the discrepancy on their own, giving them the context needed to explain it appropriately rather than being caught off guard.
78. Scenario: You’re asked to build a dashboard to “track team performance,” and you suspect it will be used punitively against individual team members rather than to genuinely improve process. How do you handle this? I’d raise the concern directly and professionally with whoever requested it — asking what decisions the dashboard is meant to support, and whether individual-level metrics versus team/process-level metrics actually serve that stated goal — since a metric used punitively without full context (workload differences, ticket complexity, external dependencies) often produces perverse incentives and worse outcomes than the dashboard was meant to solve. I’d still build what’s ultimately requested if leadership insists after that conversation, since it’s not always my call to unilaterally block it, but the professional obligation is to raise the concern clearly first, not to just build it silently.
79. How would you evaluate whether a proposed new metric is actually a good addition to an existing suite of business metrics, versus just adding noise? I’d check whether it measures something genuinely not already captured by existing metrics (avoiding redundancy), whether it’s clearly actionable (someone can do something differently based on its movement), whether it’s resistant to being easily gamed, and whether it has a clear, agreed-upon owner responsible for its definition staying consistent over time — a metric failing several of these is more likely to add confusion and maintenance burden than genuine insight.
80. Explain your approach to a scenario where the same underlying data, correctly analyzed, could reasonably support two different, opposing business conclusions depending on how it’s framed. I’d present the data in a way that makes the underlying ambiguity visible rather than picking one framing and presenting it as the only valid conclusion — showing both possible interpretations and being explicit about what additional data or context would help resolve which one is actually correct, since an analyst’s credibility depends on genuinely representing uncertainty where it exists, not projecting false confidence in a single narrative the data doesn’t unambiguously support.
81. How would you approach designing an experiment (A/B test) to validate whether a proposed change actually caused an observed improvement, rather than assuming correlation implies it did? I’d define a clear hypothesis and success metric before the test starts (not after seeing results, which invites bias), ensure genuine random assignment between control and treatment groups, calculate the sample size needed for a meaningful result upfront rather than stopping early once results look favorable, and account for external factors that might affect both groups simultaneously (seasonality, a concurrent unrelated change) before attributing the observed difference to the tested change alone.
82. Scenario: Leadership wants to cut a recurring report that you believe is still genuinely valuable and used, based on usage data suggesting otherwise. How do you handle this? I’d look at the actual usage data honestly first — if it genuinely shows low engagement, that’s real signal worth taking seriously regardless of my own belief in the report’s value, and I’d ask the people who I believe still rely on it directly whether that’s true and why usage data might not reflect it (maybe it’s referenced in a meeting without a logged click, for instance). If genuine value is confirmed through that conversation, I’d advocate for keeping it with that concrete evidence; if it’s genuinely not being used the way I assumed, I’d support retiring it rather than defending it out of attachment to work I built.
83. How would you approach communicating uncertainty or a wide confidence interval to a stakeholder who wants a single, definitive number? I’d give the single number they need to move forward with, but pair it with a clear, plain-language sense of how confident that number actually is — “our best estimate is X, but based on the data available, the real number could reasonably be anywhere from Y to Z” — resisting the pressure to project false precision just because a single clean number is more comfortable to hear, since a stakeholder making a decision on a number they think is far more certain than it actually is is a genuine risk worth managing honestly.
84. Explain how you’d approach a scenario where you discover, mid-analysis, that the business question you were asked isn’t actually the right question to be asking, given what the data reveals. I’d surface that finding back to the stakeholder before continuing further down the original path — explaining specifically what the data is suggesting might be the more relevant question, and why — since continuing to rigorously answer the wrong question produces a technically correct but ultimately unhelpful analysis; the value of catching this mid-stream and redirecting is usually much higher than either silently answering the original (less useful) question, or unilaterally switching questions without checking in first.
85. How would you evaluate whether an automated, self-service reporting tool has actually reduced the burden on your analytics team, or just shifted the problem elsewhere? I’d look beyond raw request volume — checking whether self-service usage has led to inconsistent metric interpretation spreading across the organization (a sign the burden shifted from “answering requests” to “cleaning up confusion”), whether the team’s time freed up from routine requests is genuinely being redirected to higher-value analysis, and gathering direct feedback from both the analytics team and self-service users about whether it’s actually working well, rather than assuming reduced request volume alone means unambiguous success.
86. Scenario: A senior stakeholder insists a specific number is wrong based on “what they remember from a meeting last quarter,” but your current analysis, done carefully, shows something different. How do you navigate this? I’d take the discrepancy seriously rather than dismissing it, since a senior stakeholder’s memory is sometimes a genuine, useful clue that something changed (a definition, a data source) between then and now that’s worth investigating. I’d walk back through what might have changed since that earlier number, present my current methodology clearly, and if my number holds up under that scrutiny, present it confidently but respectfully — genuine expertise means being willing to hold your ground on a carefully-verified finding even against seniority, while still taking the pushback seriously enough to actually re-check your work first.
87. How would you approach building a metric definition that needs to remain meaningful and comparable as the underlying business itself changes significantly over time (like a major product pivot)? I’d design the definition to be as structurally stable as possible around the core concept it’s meant to measure, clearly document any point where a business change forces a genuine break in comparability (rather than quietly adjusting the calculation and letting a trend line imply false continuity), and consider maintaining a “bridge” period showing both the old and new calculation side by side during a transition, so trend analysis spanning the change remains honest about the discontinuity rather than hiding it.
88. Explain your approach to handling a scenario where you’re under real pressure to deliver an analysis faster than you believe is genuinely safe to do rigorously. I’d communicate the trade-off explicitly rather than silently cutting corners or silently missing the deadline — offering a faster, appropriately-caveated preliminary answer now with a clearly-flagged confidence level, alongside a timeline for the fully validated version, letting the stakeholder make an informed choice about whether the faster, less-certain answer is actually sufficient for their immediate need, rather than me unilaterally deciding to either rush without disclosure or refuse to compromise on rigor without explaining why.
89. How would you approach mentoring a junior analyst who’s technically strong in SQL but consistently reports numbers without questioning whether they make sense first? I’d work through specific real examples with them where a wrong number would have gone out if it hadn’t been sanity-checked, building the habit of asking “does this pass a basic smell test” as a genuine, non-negotiable step before sharing any result — technical skill is teachable quickly, but that instinct to pause and question a surprising number is really the core professional habit that takes deliberate practice and real examples to build.
90. Scenario: You’re asked to analyze data that would help justify a decision that’s ethically questionable, though not illegal (e.g., identifying which customer segment is least likely to notice a price increase). How do you handle this? I’d do the requested technical analysis if asked, since the analysis itself is often neutral, but I’d feel comfortable raising the ethical dimension directly with whoever’s making the actual business decision, since surfacing that concern is a legitimate part of professional judgment, not overstepping — the decision itself typically isn’t the analyst’s to unilaterally block, but staying silent about a genuine ethical concern when you see one isn’t the right instinct either.
91. How would you design a process for regularly auditing existing dashboards and reports across an organization to catch drift, staleness, or redundancy? I’d establish a recurring review cadence checking actual usage data (is this report still being viewed), whether its underlying source data and logic are still current and correct, and whether it substantially overlaps with something else already available — treating this as ongoing maintenance rather than a one-time cleanup, since dashboards left unreviewed indefinitely reliably accumulate staleness and redundancy the same way an untended garden accumulates weeds.
92. Explain how you’d approach a scenario where the “obvious” data-driven answer to a business question conflicts with strong stakeholder intuition built from years of experience. I’d take the intuition seriously as a genuine data point worth investigating rather than dismissing it, since experienced stakeholders sometimes have context the available data doesn’t fully capture — checking whether there’s a real gap in what’s being measured that would explain the disagreement. If the data genuinely holds up after that scrutiny, I’d present it clearly and confidently while acknowledging the tension directly rather than pretending it doesn’t exist, since papering over a genuine disagreement between data and experienced intuition usually just delays a harder conversation rather than resolving it.
93. How would you evaluate whether your organization’s current data infrastructure and reporting maturity is actually holding back the quality of analysis you’re able to deliver? I’d look for concrete symptoms — recurring, avoidable data quality issues eating significant analyst time, an inability to answer genuinely important business questions because the underlying data simply isn’t captured, or persistent, unresolved metric definition conflicts across teams — and if present, build a concrete case (with specific examples and their real business cost) for infrastructure or process investment, rather than just working around the limitations indefinitely without ever making the underlying constraint visible to whoever could actually address it.
94. Scenario: A report you built and handed off months ago is now producing subtly wrong numbers because an upstream system changed without anyone telling your team. How do you prevent this from recurring? Beyond fixing the immediate issue, I’d push for establishing a more formal dependency-awareness practice — documenting which reports depend on which upstream sources, and working with those upstream teams (or their change-management process, if one exists) to get advance notice of schema or logic changes that could affect downstream reporting, rather than relying on discovering breakage reactively after the fact, which is both slower and more damaging to trust than catching it proactively.
95. How would you approach a situation where you genuinely don’t know the answer to a stakeholder’s question, and the data available can’t fully answer it either? I’d say so plainly and specifically — what exactly the data can and can’t tell them, and why — rather than stretching the available data further than it genuinely supports just to provide some answer, since a confidently wrong or over-extended answer does more damage to both the decision and to trust in future analysis than an honest “the data doesn’t fully answer this” ever would.
96. Explain your approach to balancing depth of analysis against the reality that most stakeholders only have a few minutes of attention for any given finding. I’d lead with the single most important finding and its direct business implication first, structured so a stakeholder gets the core message even if they only read the first line, while keeping the full depth and methodology available for whoever wants to dig further — rather than presenting a thorough analysis in the order it was built, which often buries the actual headline finding under process detail nobody asked for.
97. How would you handle discovering that a decision was already made and publicly communicated based on a number that later analysis suggests was wrong, but reversing the decision now would be genuinely costly and disruptive? I’d still surface the finding clearly and honestly to the relevant decision-makers regardless of how inconvenient the timing is — that’s a business and leadership call about whether and how to respond, not something the analyst should quietly decide to sit on because the truth is inconvenient — while presenting the finding with appropriate context about its actual implications, so leadership can make a genuinely informed choice about next steps.
98. What’s your approach to evaluating whether your own analysis might be influenced by confirmation bias toward a result you expected or hoped to find? I’d deliberately look for the analysis that would prove my initial hypothesis wrong, not just the one that confirms it, actively seek out a colleague to review methodology with fresh eyes before finalizing anything with significant stakes riding on it, and specifically notice if I’m tempted to stop investigating the moment I find a result that matches what I expected — that instinct to stop early on a confirming result, rather than continuing to check, is usually the clearest sign confirmation bias is actively at play.
99. How would you approach designing a personal practice or checklist to consistently catch your own mistakes before they reach a stakeholder, given that everyone makes analytical errors occasionally? A concrete checklist genuinely helps more than relying on general carefulness — sanity-checking totals against a rough independent expectation, spot-checking a handful of individual records against raw source data, deliberately re-reading the original question to confirm the analysis actually answers what was asked (not a slightly different, easier question), and, for anything high-stakes, getting a second set of eyes before it goes out — treating this as a non-negotiable habit rather than something to skip under time pressure, since time pressure is exactly when mistakes are most likely to happen and least likely to get caught otherwise.
100. Walk through how you’d handle a genuinely difficult, high-stakes analytical situation end to end — combining the technical and the judgment/mindset dimensions this whole list has been building toward. Intentionally open-ended, since interviewers here are evaluating the whole person, not just SQL skill. A strong structure to demonstrate: (1) confirm the problem is real with objective data before reacting to how it’s initially described, the same discipline as the sales-drop scenario throughout this list, (2) investigate systematically — segmenting, checking data quality, ruling out measurement issues — before committing to a root-cause narrative, (3) communicate findings honestly, including genuine uncertainty, rather than projecting false confidence to seem more authoritative, (4) raise legitimate concerns (ethical, definitional, or about how a finding might be used) even when it’s uncomfortable to do so, without unilaterally overstepping decisions that aren’t actually yours to make, and (5) close the loop by making sure the finding actually reached the right decision, not just that a report was technically delivered. Interviewers consistently favor candidates who show this full arc — investigation, honesty, and follow-through — over candidates who can only demonstrate the SQL, because the SQL, on its own, was never really the hard or scarce part of this job.
A Closing Thought
Every scenario question in this list comes back to the same instinct: investigate before you react, and communicate honestly even when the honest answer is “I’m not fully certain yet.” That instinct — more than any specific query pattern — is what a good interviewer is actually listening for, and it’s genuinely what separates an analyst who reports numbers from one an organization learns to actually trust with its real decisions.
Read more articles on SQL server & Azure SQL
SQL Server Execution Plans Explained: A Beginner’s Guide for DBAs and Developers
Top 50 Azure SQL Execution Plan Interview Questions and Answers (Beginner to Advanced)
Difference between Actual & Estimated Execution Plan
How to resolve multiple execution plans cache issue?
Execution Plan Analysis: CTEs vs Temp Tables vs Derived Tables
For Interview Questions on SQL SQL Server, Azure SQL, Performance Tuning, Security, and DBA, click the link below:-
https://www.techmixing.com/interview-questions-2
Explore the Complete TechMixing Article Sitemap – Click the Link Below
https://www.techmixing.com/site-map
Discover more from Technology with Vivek Johari
Subscribe to get the latest posts sent to your email.
