How to Screen Data Analysts: 9 Questions and What to Listen For Screening Interview Template

Walk me through the most impactful analysis you have delivered. What was the question, what did you find, and what did the business do differently afterward?

What this assesses: Most candidates answer the first two parts and skip the third, which is the part that matters. Strong answers end with a decision: a campaign killed, a price changed, a support queue restaffed, a feature deprioritized. They can name who made that call. Weak answers end at the deliverable, describing a dashboard that was built and shipped with no account of whether anyone opened it. Treat vague impact numbers with suspicion, especially clean ones like a 30 percent lift with no baseline attached.

A stakeholder messages you saying churn feels high and asks you to look into it. What do you do in the first hour?

What this assesses: This is the single most common real request an analyst gets, and the response separates order-takers from analysts. Strong answers do not open a query editor. They go back to the stakeholder to define what churn means here, over what window, for which segment, and what decision the answer would change. Then they check whether someone has already answered it. Weak answers dive straight into pulling data and building a dashboard, which is how analysts end up doing three weeks of work that answers the wrong question.

You come in Monday morning and a key metric dropped 20 percent over the weekend. Walk me through how you investigate.

What this assesses: Tests structured diagnosis under ambiguity. Strong answers rule out the boring causes first: a broken pipeline, a tracking change, a duplicate load, a timezone shift, a bot filter that stopped running. Then they cut by dimension, comparing platform, region, channel, and new versus returning, to see whether the drop is broad or concentrated. They also check whether the same weekend last year looked similar. Weak answers jump to a business explanation, blaming seasonality or a competitor, before confirming the number is even real.

What is your experience with SQL? Describe the most complex query you have written and what specifically made it hard.

What this assesses: Listen for the reason it was hard, not the line count. Strong answers name a real difficulty: fanned-out joins from a mismatched grain, deduplicating an event stream, window functions for sessionization or running totals, a slowly changing dimension, or rewriting something that scanned a full table into something that used a partition. Weak answers say advanced SQL and stop, or describe a long query rather than a hard one. Someone who cannot explain what a join did to their row count has been copying queries, not writing them.

Where did the data you worked with come from, and what did you do the last time you found it was wrong?

What this assesses: Most analyst job postings understate how much of the job is fighting the data. Strong answers describe the actual stack, naming a warehouse, a transformation layer, an event tracker, and describe a specific defect they found: an ID that changed format after a migration, a currency field mixing units, a backfill that double counted a week. Then they say what they did, whether they fixed it upstream, flagged it to the engineer who owned it, or documented the caveat. Weak answers say the data was always clean, which means it was not and they did not check.

How do you check your own work before you publish a number? Tell me about a time you caught an error, and a time you missed one.

What this assesses: The second half of the question is the real one. Strong answers describe concrete habits, such as reconciling totals against a known source, sanity-checking row counts before and after every join, spot-checking a handful of individual records by hand, and having a peer read the query. Then they tell you about a miss without flinching, including how it was caught and what they changed. Weak answers claim they have never shipped a wrong number. Every analyst with real volume behind them has. A candidate who cannot name one is either new or not paying attention.

What tools have you used to present findings, and how do you decide what belongs in a dashboard versus a one-page write-up?

What this assesses: Tests judgment about format, which is where most analyst output goes to die. Strong answers draw a line: dashboards for metrics somebody checks on a recurring cadence and will act on, written analysis for one-time questions that need an argument and a recommendation. They can point to a dashboard they retired because nobody used it. Weak answers treat every request as a dashboard request, or list tools without any point of view. Ask how many of the dashboards they built are still in use, because the honest answer is usually a small fraction.

Tell me about a time stakeholders pushed back on your analysis, or ignored the recommendation entirely. What happened?

What this assesses: Analysts have influence, not authority, and this question shows how they handle that. Strong answers describe the specific objection, whether the analysis was wrong, incomplete, or simply inconvenient, and what the candidate did next. Sometimes the right answer is that the stakeholder had context the data did not capture and the candidate updated. Weak answers frame every disagreement as the business failing to understand data, or fold immediately and rerun the analysis until it says what the stakeholder wanted. Both patterns cost you later.

What statistical methods have you actually used in your work, and when have you decided a situation did not need one?

What this assesses: The second clause filters out course lists. Strong answers name methods tied to real problems, such as a significance test on an A/B result, a sample-size check before launching one, a regression used for a driver analysis, cohort curves for retention. Better still, they describe a case where a simple grouped comparison answered the question and a model would have added nothing but delay. Weak answers recite a syllabus of techniques with no application attached. Run every candidate through the same [structured interview](/glossary/structured-interview) questions in writing, so you are comparing answers rather than impressions, and see [asynchronous screening](/glossary/asynchronous-screening) for how to handle a few hundred applicants without booking a call for each one.