Data Analyst Interview Questions: entry level level

You are applying for your first data analyst job, and the live SQL task is the bit you are quietly dreading. This guide is for graduates, quantitative degrees, and bootcamp leavers.

What Data Analyst interviewers assess

This is the real work sitting behind the questions. They are checking whether you have actually done it, not whether you can describe it.

  • SQL fluency: Joins, window functions, CTEs, aggregations, and queries someone else can still debug six months from now.
  • Statistics and experimentation: Hypothesis testing, confidence intervals, sample size, and where inference stops helping on messy product data.
  • Data modeling: Dimensional modeling, source-of-truth tables, and how your models mirror what the business actually does.
  • Stakeholder partnership: Turning vague asks into measurable questions, setting expectations, and saying no to ad hoc work.
  • Visualisation and storytelling: Picking the right chart, headline-first dashboards, and the discipline of never burying the answer.
  • Tooling craft: Notebooks vs. BI tools, version control for queries, and reusable assets that outlive your time on the team.

Common Data Analyst interview questions with answer guidance

1. Walk me through a recent analysis you are proud of.

Pick an analysis with a real decision attached. Cover the question, the data, your method, and the recommendation. Spend equal airtime on what the business did with it. Do not get lost in technique, because interviewers are grading impact and judgment. Close with one limitation you would fix in v2.

2. Write a SQL query to find the top 3 products by revenue per month.

Clarify the schema and the edge cases first: refunds, currency. Then walk the CTEs: aggregate revenue per product per month, then ROW_NUMBER() OVER (PARTITION BY month ORDER BY revenue DESC) and filter to rank ≤ 3. Cover ties, NULL handling, and performance on large tables. Say which indexes would help.

3. A PM asks why DAU dropped 10% last week. How do you investigate?

Validate first: is the drop real or a logging problem? Slice by segment (platform, geography, cohort) and check for known events like a release, an outage, or a holiday. Look at top-of-funnel acquisition and retention separately. Form a few hypotheses and test each one. Do not commit to a story off the first chart.

4. Explain a confidence interval to a non-technical stakeholder.

Plain language: the interval is the range you expect the true value to sit in, given the data you have. Steer clear of the frequentist trap of "the probability the true mean is here". Tie it to a live decision: do we ship? Respect the audience without talking down to them.

5. Design a dashboard for a marketing team launching a new product.

Start from the questions that team has every morning. Headline metric first, then channel breakdown, then funnel. Add guardrails such as CAC and refund rate so growth chasing has a counterweight. Cover refresh frequency, ownership, and how you retire the thing once the launch is over.

6. Tell me about a time you said no to an ad-hoc data request.

Pick a story where you protected your roadmap without wrecking the relationship. Show you understood the real need, offered an alternative (self-serve, batched, deferred), and taught the requester something. Mention the trust it built. Make it clear you say yes far more often than no.

7. Explain Type I and Type II errors in an A/B test context.

Type I is a false positive: you ship a change that never moved the metric. Type II is a false negative: you kill a winner. Connect that to alpha, power, and sample size, and to how product risk shifts your tolerance for each. Add that variance drives power just as much as effect size does.

8. How do you check data quality before running an analysis?

Row counts against expectations, distribution sanity, NULL rates, freshness, and cross-checks against aggregates you already trust. Use dbt tests or similar where they exist. Talk about the discipline of stopping when something looks wrong rather than pushing on with caveats nobody reads.

9. A leader wants a single "north star" metric. How do you choose one?

Anchor it to value the product actually delivers, not vanity. Cover leading vs. lagging, sensitivity, how easily it can be gamed, and whether other teams can read it. Pair the metric with guardrails. Say you would run it for a quarter before institutionalising it. Use a concrete example from a real role.

10. Walk me through how you would investigate a sudden conversion rate increase.

Treat a nice surprise exactly like a nasty one, because it is usually a bug. Check the logging, look for filter changes, inspect the denominator. Slice by segment to find where it concentrates. If it is real, name the driver: campaign, release, seasonality. Communicate carefully so nobody over-invests in a phantom win.

11. Why data analytics rather than data science or engineering?

Talk about what genuinely energises you: sitting close to decisions, the craft of communication, the sheer range of stakeholders. Do not talk other roles down. Tie it to the company’s data maturity and the part of the craft you want to go deeper on.

12. How do you keep your team’s queries reusable and trustworthy?

Version control, peer review, and a model layer (dbt or similar) sitting over raw tables. Metric definitions documented and tested. Talk about who owns a metric and the damage two disagreeing charts do. Make it clear you treat analytics infrastructure as a real product with real users.

How to prepare

Say each answer out loud, keep it short, and swap in an example from the job you are actually chasing.

  • Brush up window functions and CTEs, because plenty of candidates fumble them under live coding.
  • Have one analysis you can describe in business terms first and technique second.
  • Refresh the A/B testing traps: peeking, multiple comparisons, novelty effects.
  • Prepare a question for the interviewer about how decisions actually get made on data there.
  • Rehearse the dashboard-design walkthrough on Voxxhire until it stops sounding like a list.

What changes at entry level level

Nobody expects a track record of business impact yet. They want to see that your SQL and Excel hold up, that you think in a straight line, and that you can explain a finding to someone who hates numbers. Expect a take-home task or a live SQL exercise alongside behavioural questions. Freezing on the first query is common. Talking through what you are trying to do while you unfreeze is what separates you.

Extra questions for entry level candidates

Write a SQL query to find the top 5 customers by total revenue in the past 90 days. (technical, easy)

SELECT customer_id, SUM(revenue) as total FROM orders WHERE order_date >= CURRENT_DATE - 90 GROUP BY customer_id ORDER BY total DESC LIMIT 5. Say the clauses out loud as you write them. If you blank, start with the FROM and build outwards.

How would you explain a trend you found in data to someone with no analytical background? (situational, easy)

Use an analogy, drop the jargon, and lead with what it means for the business before you go anywhere near the method. A simple chart beats a clever one. If they look lost, stop and ask which part lost them.

Tell me about a time you found an insight in data that changed someone's decision. (behavioral, easy)

Use one real example from university, a placement, or a project. Say what the insight was, how you got it across, and what decision it changed.

How do you handle missing or inconsistent data in an analysis? (technical, medium)

Say how you actually work: find out how much is missing, work out whether it is random or systematic, then choose between imputing, excluding, or flagging it. Whatever you pick, say you would document it. Patching it quietly is the thing that gets you caught.

What metrics would you use to measure the success of a new feature launch? (situational, medium)

Name a primary outcome metric, a leading indicator, and a guardrail metric so you catch damage elsewhere. Then say how you would set the measurement up before the launch, because afterwards is too late.

entry level preparation tips

Pick examples that match the scope you would genuinely own at this level. Too small and you sound junior. Too big and it sounds borrowed from your manager.

  • Practise writing SQL from scratch with no IDE and no autocomplete. Plenty of interviews still hand you a whiteboard or a plain text box.
  • Line up two or three pieces of analysis from a dissertation, a Kaggle project, or an internship, with specific numbers attached to each one.
  • Be ready to explain how you got there, not just what you found. Interviewers are buying your thinking, not your conclusion.
  • If you have built anything in Tableau, Power BI, or Looker, bring a screenshot or a link. Something they can actually look at sticks.

Frequently asked questions

What SQL skills do I need for an entry-level data analyst interview?

SELECT, WHERE, GROUP BY, ORDER BY, JOIN (inner, left, right), and subqueries, without having to stop and think about them. Window functions like ROW_NUMBER, RANK, and LAG are a bonus at this level rather than a requirement.

Do entry-level data analyst interviews include Python or R?

Increasingly yes, especially at tech companies. Pandas and basic matplotlib come up most. Some teams are Python-only, plenty still run on SQL and Excel, so read the job ad and ask the recruiter what the screen looks like.

How important is domain knowledge for an entry-level data analyst interview?

Less important than the fundamentals. Clear thinking, a finding you can explain to a non-technical person, and technical accuracy will beat knowing their industry. You can pick up the industry in a month.

Start practising with Voxxhire

Related interview preparation resources