A strong answer

• Checked the work before announcing the finding
• Names what they verified - the join, the filter, the date range, the denominator, duplicates
• Distinguishes a genuine insight from a data artefact
• Escalated or shared it appropriately once confident

Red flagReported the surprising number straight away because it made a good story.

A strong answer

• Asks what decision the number will inform before running anything
• Clarifies definitions - which customers, which period, active means what exactly
• Confirms understanding back to them in writing
• Knows the requested number is often not the useful one

Red flagGoes straight to the query.

A strong answer

• Chose a concrete example over an abstract explanation
• Checked understanding rather than assuming
• Adjusted when the first attempt did not land
• Can admit an attempt that failed

Red flagDescribes the audience as the problem.

A strong answer

• Produces it if required, with the caveat attached and visible
• Offers the better alternative alongside rather than instead
• Escalates only if the number will cause real harm
• Understands they are an adviser, not a gatekeeper

Red flagEither refuses outright, or hands it over silently knowing it is misleading.

A strong answer

• Has some grasp of the domain - meter data, tariffs, hardship, regulation
• Interested in a domain deep enough to learn over years
• Honest about wanting breadth early in a career
• Has read something about the industry

Red flagInterested in data generically, with no view on where.

A strong answer

• WHERE filters rows before grouping, HAVING filters groups after aggregation
• Gives an example: filtering by a customer state versus filtering to customers with more than five invoices
• Knows an aggregate cannot be used in WHERE

Red flagUses them interchangeably and cannot be led to the difference.

A strong answer

• Duplicates on the join key in the right-hand table
• Knows to check the grain of both tables before joining
• Would run a count of distinct keys to confirm
• Recognises this is the single most common cause of wrong numbers in reporting

Red flagAdds DISTINCT to make the row count look right without diagnosing it.

A strong answer

• Reaches for a window function - ROW_NUMBER partitioned by customer, ordered by date
• Or a correlated subquery or a max-date join, and knows the tie-breaking problem
• Asks what to do when two invoices share a timestamp
• Thinks about customers with no invoices at all

Red flagUses GROUP BY with a max date and then selects other columns without understanding why it is wrong.

A strong answer

• Calculates across a set of rows while keeping each row
• Names real uses: running totals, rank within group, month-on-month change, deduplication
• Understands PARTITION BY versus GROUP BY
• Has actually used one

Red flagHas heard the term but has never written one and does not ask.

A strong answer

• Counts at each stage of the pipeline to find where the drop happens
• Suspects an inner join, a date filter, a timezone boundary, or a null in the join key
• Compares against the source rather than another derived table
• Knows nulls do not behave as expected in comparisons

Red flagRebuilds the query from scratch hoping it comes out right.

A strong answer

• Grain is what one row represents - one customer per day, one meter read, one invoice line
• Knows mixing grains is how double counting happens
• Would state the grain explicitly when designing a model
• Connects it to sums that are inexplicably too large

Red flagHas never thought about it and shows no curiosity when it is explained.

A strong answer

• Row counts and freshness, uniqueness of keys, nulls where they should not be, accepted values, referential integrity
• Runs them after load and fails or quarantines rather than publishing silently
• Distinguishes a hard failure from a warning
• Knows someone has to be told, and who

Red flagAssumes the pipeline running successfully means the data is correct.

A strong answer

• Someone is alerted, with enough context to act
• Decides between rerunning, backfilling and publishing stale data with a notice
• Considers whether partial data is worse than no data
• Communicates to consumers rather than hoping nobody notices

Red flagWould rerun the job and say nothing.

A strong answer

• Full rebuilds everything; incremental adds or updates only what changed
• Knows incremental is faster and cheaper but can silently miss late-arriving or back-dated records
• Mentions needing a reliable change indicator, and periodic full reconciliation
• Deleted source rows are the classic trap

Red flagOnly knows one and does not ask about the other.

A strong answer

• Separates dimensions from facts, or reasons to that structure without the vocabulary
• Handles a customer moving house - a meter can have several customers over time
• Recognises meter reads as high volume and invoices as low volume with corrections
• Asks about restatements and history: do we need to know what we believed last month

Red flagProduces one flat table and does not revise it when you introduce a moving customer.

A strong answer

• Assumes a definition difference before assuming an error
• Checks period boundaries, GST, credits and adjustments, cancelled invoices, accrual versus cash
• Reconciles at a smaller grain to isolate where the gap appears
• Writes the agreed definition down so it does not recur

Red flagAssumes finance is wrong.

A strong answer

• Shared business logic belongs upstream so every consumer agrees
• Presentation-only logic can stay in the dashboard
• Knows logic buried in a report is invisible and unversioned
• Weighs reusability against speed of delivery honestly

Red flagPuts everything in the dashboard because it is quicker.

A strong answer

• Leads with the answer, not the method
• States the recommendation and what would change if acted on
• Caveats are present but proportionate and near the end
• No jargon, and no apologising for the data

Red flagWalks through their process chronologically and never reaches a conclusion.

A strong answer

• Found at least two of the planted problems - duplicates, impossible dates, a units change partway through, missing months
• Says what they did about each: excluded, corrected, flagged
• Quantifies the impact on the answer
• Notes anything they suspected but could not confirm

Red flagReports no problems at all.

A strong answer

• Names the biggest source of uncertainty in their own answer
• Wants additional data they can specify
• Would validate a finding against a second source or with a stakeholder
• Prioritises rather than listing

Red flagWould make the charts nicer.

A strong answer

• Distinguishes correlation from a causal claim
• Knows the sample, the period and what else changed during it
• Suggests a limited trial or a holdout before a full rollout
• Is comfortable saying the data supports investigating, not deciding

Red flagPresents a correlation as a reason to change pricing for 210,000 customers.