One-way interview questions for data analysts, with model answers

A data analyst one-way interview is an early screening step where you record answers to set questions on your own time, with no live interviewer. It is also called a one-way video interview, an on-demand interview, or “a HireVue” after the most common tool. A hiring team reviews your recordings later, usually before a live case or technical round.

For analyst roles the questions are mostly behavioral and business-sense, not a live SQL test. Expect a time your analysis changed a decision, a time you were wrong, how you handle a stakeholder, and at least one estimation prompt. Large employers like JPMorgan and Deloitte use this format because they hire analysts in volume and want a consistent read on how you think before they spend an interviewer’s time. Many other data-heavy teams run an early one-way round for the same reason.

The part that catches analysts off guard is specific to the job. You are used to showing your work: a query, a chart, a dashboard you can point at. Here there is none of that. You talk through an analysis out loud, in order, to a camera lens that does not react. That is a learnable skill, and most of this page is about doing it well.

This page covers the questions data analysts actually get in a one-way interview, three model answers in the STAR format, and the traps specific to the role.

The questions you should expect

Data analyst one-way interviews pull from a stable set. You will not get all of these, but if you can speak to each one you are covered. They fall into four groups.

Motivation and fit

• Why data analysis, and why this team or company specifically?
• Walk me through your background and one project you are proud of.
• What kind of analytics work do you want to be doing in a couple of years?

Behavioral, the “tell me about a time” set

• Tell me about a time your analysis changed a decision.
• Describe a time you found something surprising or counterintuitive in the data.
• Tell me about a time you were wrong, or your first read of the data turned out to be off.
• Tell me about a stakeholder who pushed back on your findings or wanted a different answer.

Business sense and estimation

• How would you measure whether a new feature is working?
• A key metric dropped last week. How would you figure out why?
• How would you estimate the impact of a change when you cannot run a clean A/B test?

Walk-me-through and analytical approach

• Describe an analysis you ran end to end.
• How do you check whether a dataset can be trusted before you analyze it?
• How would you explain a technical finding to someone with no analytics background?

Most of these are behavioral or reasoning prompts, which means they want a real story or a clear line of thinking, not a definition. That is what the STAR method is for.

Three model answers in STAR

STAR is four beats: Situation (one sentence of context), Task (the problem in front of you), Action (what you specifically did), Result (how it turned out, with a number where you have one). On a one-way interview there is no one to nudge you back on track, so the structure does the work. These are templates to adapt to your own work, not lines to recite.

”Tell me about a time your analysis changed a decision.”

Situation. The growth team wanted to double spend on a paid channel that looked like our best performer on last-click attribution.

Task. Before we committed the budget, I was asked to sanity-check whether that channel was really driving new customers or just taking credit for them.

Action. I pulled the conversion paths instead of the last-click view and segmented by whether users had touched other channels first. Most of the “wins” had already been reached by organic and email earlier in the week. I built a simple before-and-after comparison on a small holdout region where we had paused that channel, and conversions barely moved.

Result. We held the budget flat instead of doubling it and redirected the increase to a channel that did move the holdout. That saved roughly a quarter of the quarter’s paid budget from going to a channel that was mostly claiming credit. I learned to never trust last-click on its own.

Why it works: it names a concrete decision, shows the analytical move in plain language, and lands on a number. It does not drown the point in tool names.

”How would you measure whether a feature is working, and what if you cannot run an A/B test?”

This is the signature data analyst prompt on a one-way interview. They want to hear you reason, not recite a formula.

Situation. Say we shipped a new onboarding checklist to everyone at once, so there was no clean control group to test against.

Task. I would need to know whether the checklist actually improved activation, without the A/B test I would normally lean on.

Action. First I would define the metric that matters, say the share of new users who complete a key action in their first week, not just clicks on the checklist. With no randomized control, I would build a comparison another way: look at the trend before and after launch, compare similar cohorts of users who happened to see it late versus early in a staged rollout, and check a segment the change should not have affected as a sanity baseline. I would call out the obvious confounder, that seasonality or a marketing push could move the same number, and say how I would rule it out.

Result. That gives a defensible read on impact and an honest confidence level, instead of a false-precision number. The point I would make is that no A/B test does not mean no measurement, it means being explicit about what the comparison can and cannot prove.

Why it works: it defines the metric first, reaches for quasi-experimental comparisons, and names the confounder out loud. Naming what could fool you is exactly the judgment they are screening for.

”Tell me about a time you were wrong in the data.”

Situation. I flagged a sharp overnight drop in signups and started writing it up as a real problem.

Task. Before raising the alarm to the team, I had to confirm the drop was real and not an artifact.

Action. I stopped and checked the data quality first. A tracking change had shipped the day before and one event was firing under a new name, so the old query was undercounting. I corrected the query, re-ran it, and the “drop” mostly disappeared. Then I flagged the tracking change to the engineer who shipped it so the dashboards would not keep breaking.

Result. Real signups were down only slightly, not off a cliff, and I caught it before sending a false fire drill to the team. Now I check whether the pipeline changed before I trust a number that looks dramatic.

Why it works: analyst reviewers are looking for someone who validates before they panic. Showing that you check data quality, find your own error, and fix the pipeline is the answer they want. It demonstrates judgment without pretending you are never wrong.

The role-specific trap: no whiteboard

General interview advice misses the thing that specifically trips up analysts on camera. In a live interview you reach for a whiteboard, a screen-share, or a notebook the moment you start reasoning. On a one-way interview none of that exists. You get a question, a short window to think, and a recording light. You have to make your analysis legible using only your voice.

The fix is to narrate in a fixed order, every time:

1. The question. What were you actually trying to answer?
2. The data. What did you use, and did you check it first?
3. The finding. What did the numbers say?
4. The so-what. What changed, or what would you recommend?

Saying “I started by checking the data quality, then segmented by channel, and the drop was concentrated in one source, so we paused that source” shows your reasoning just as clearly as a chart would. You do not need to draw anything. You need to be ordered and specific. The companion guide on how to prepare for a data analyst video interview drills this delivery line by line.

Other traps that quietly cost analysts

Going silent to think. In a live room a pause reads as care. On a recording, dead air eats your clock and looks like you are stuck. Think out loud. “Let me work through this” is a fine first line while you order your thoughts.

Treating a business-sense prompt like a SQL exam. “How would you measure X” is not asking for a query. It is asking which metric matters and why. Lead with the metric and the reasoning, then mention the data you would pull. Reviewers screening analysts want to see judgment, not syntax.

Burying the point in tool names. Listing every library and dashboard you touched is not the same as showing you can think. Name the decision you influenced and the number that moved. The tools are a footnote.

Reading a script off the screen. Analysts over-prepare these and end up reading, which reviewers can see. Use three or four bullet points off to the side, not a paragraph, and look at the lens. A glance down to check a structure is fine. Reading a wall of text is not.

Forgetting it runs on a timer. Most one-way tools give you a short prep window, then record for a fixed length with no pause, across a handful of questions. The prep window can be tight. Read the first screen for the prep time, the answer length, the number of questions, and whether retakes are on, before you hit start. If retakes exist, save them for a genuinely bad take, not for chasing a perfect one.

A calm word on AI scoring

If your data analyst interview runs on HireVue or a similar tool, the honest version is reassuring. These tools mostly transcribe what you say and check your answers against the role’s criteria, then surface that to a person who makes the call. HireVue said it stopped using facial analysis in 2021, and by recruiters’ own accounts most employers never turned that module on. So speak clearly for the transcript, answer the actual question, and do not perform for a camera you think is reading your face. The full picture is in is it an AI interview?.

One more thing, because it comes up for big-name employers. Candidates trade leaked question banks for roles at firms like JPMorgan, and you may be tempted to memorize answers. It is worth resisting. Reviewers can usually tell a recited answer from a real one, the questions rotate, and a rehearsed line tends to fall apart the moment the prompt shifts. Preparing your own real stories beats memorizing someone else’s.

Before you record

Light your face from the front, put the camera at eye level, and silence your phone. Treat it like the live case it stands in for, because the analysts and hiring managers on the next round will watch it before they decide whether to meet you. Lead each answer with your point in the first ten seconds, narrate any analysis in order, name the metric and the number, and stop when you are done.

For the full mechanics of recording well under a timer, read how to pass a one-way video interview. If you want the delivery drilled for this exact role, the data analyst video interview prep guide is the companion to this page, and the video interview guides by role index has the prep guides and banks for every other function.