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.
“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.
“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.
“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.
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.