Data analyst interview questions

Analyst interviews test something narrower than "can you use SQL": whether the numbers you produce change what anybody does. The questions are usually about a time you were believed, a time you were ignored, and a time you were wrong.

What this round is actually assessing

Turning a vague request into an answerable question: Most requests arrive as "can you pull the numbers on X". The work is deciding what X means before you write anything.
Knowing what your data cannot say: Interviewers listen for caveats you volunteered before anyone asked, not ones you produced when challenged.
Making a finding land: An analysis nobody acted on is a common, honest answer — and the interesting part is why not.
Being wrong in a checkable way: How you found your own mistake, and how fast you said so, is the whole trust question for this role.

The questions, and what each one is for

“Tell me about an analysis that changed a decision.”

Why they ask it: To find out whether your work reaches the point of decision, or stops at the dashboard.
What a strong answer contains: The decision before, the decision after, and the specific thing in the analysis that moved it.
The follow-up a vague answer earns: “Who had to be convinced, and what convinced them?”
The mistake it catches: Describing the analysis in detail and the decision in one clause. It is the wrong way round.

Answer this one — free, no sign-in →

The question

Tell me about an analysis that changed a decision.

What this is testing: To find out whether your work reaches the point of decision, or stops at the dashboard.

Your answer

0 words · stays in this tab · ⌘/Ctrl+Enter

“Describe a time your analysis was wrong.”

Why they ask it: Everyone has been. The question is whether you noticed first, and what you did in the hour after.
What a strong answer contains: How you caught it, who you told before they found out, and what you changed about how you check.
The follow-up a vague answer earns: “What check do you run now that you did not run then?”
The mistake it catches: A "wrong" that turned out fine. It is an answer that avoids the question.

Answer this one — free, no sign-in →

The question

Describe a time your analysis was wrong.

What this is testing: Everyone has been. The question is whether you noticed first, and what you did in the hour after.

Your answer

0 words · stays in this tab · ⌘/Ctrl+Enter

“How do you handle a request where the ask is not really the question?”

Why they ask it: To see whether you negotiate scope or just deliver what was literally asked for.
What a strong answer contains: The question they asked, the question they meant, and how you found the gap without being difficult about it.
The follow-up a vague answer earns: “What did you deliver in the end, and did they use it?”
The mistake it catches: Making the requester sound foolish. Interviewers will assume you would do the same to them.

Answer this one — free, no sign-in →

The question

How do you handle a request where the ask is not really the question?

What this is testing: To see whether you negotiate scope or just deliver what was literally asked for.

Your answer

0 words · stays in this tab · ⌘/Ctrl+Enter

“Tell me about a time the data was too messy to answer the question.”

Why they ask it: To test whether you can say "we cannot know this from here" and be trusted rather than dismissed.
What a strong answer contains: What you could say, what you could not, and what you proposed to close the gap.
The follow-up a vague answer earns: “What did you report, given you could not answer it?”
The mistake it catches: Producing a number anyway with a quiet caveat. That is how a caveat gets dropped in the next meeting.

Answer this one — free, no sign-in →

The question

Tell me about a time the data was too messy to answer the question.

What this is testing: To test whether you can say "we cannot know this from here" and be trusted rather than dismissed.

Your answer

0 words · stays in this tab · ⌘/Ctrl+Enter

A made-up answer, made specific

“Tell me about an analysis that changed a decision.”

The vague version

I looked at our churn data and found some interesting patterns, and I presented it to the team and they found it really useful. After that we made some changes to the onboarding.

What is missing

The finding is unnamed, the decision is unnamed, and "really useful" is the evidence. Every clause is a placeholder for the thing the interviewer wanted.

The stronger version

We believed churn was a pricing problem, because it spiked after the first invoice. It was a first-week problem: accounts that had not invited a second user in seven days churned at about four times the rate, and the invoice was simply the moment they noticed. I could not prove it caused churn — it is correlational and I said so — but it was strong enough to reorder the onboarding around the second invite. The team shipped that; I do not know the eventual effect because I left two months later.

Written as an illustration. It is not a customer, a transcript, or a result we measured.

Three questions worth asking them

“Who reads the analysis here, and what do they do with it?”
“What is the number this team is judged on, and does everyone agree it is the right one?”
“Where does the data here disagree with itself?”

Practise these against your own résumé

Add your résumé and the job description and the questions change: they ask about your work, by name, and the feedback quotes what you actually said.

Build my interview