Walk me through how you approach a new analysis request.

I start by understanding the business question behind the request, not just the data question. Often what someone asks for and what they actually need are slightly different, and a short conversation upfront saves a lot of rework. Once I understand the goal, I clarify the scope: what time period, what segments, what level of precision is needed. Then I explore the data before building anything, checking for nulls, duplicates, outliers, and unexpected distributions. I build the analysis incrementally, validating intermediate results against known benchmarks or sanity checks. Before presenting findings I ask myself: if this is right, what should we do? If the answer is not obvious, I either need more analysis or a clearer hypothesis. I present findings in the simplest format that supports the decision.

How do you communicate complex data findings to a non-technical audience?

I lead with the finding, not the method. Stakeholders want to know what the data says and what to do about it: they do not need to understand the JOIN logic that got me there. I structure presentations as a single headline finding, two or three supporting points, and a clear recommendation. I use simple charts rather than tables wherever possible, because visualisations let people grasp relationships instantly. I also translate metrics into business language: instead of "the 30-day retention rate dropped 4 percentage points", I say "we lost roughly 400 customers this month who we would have kept last month". I always ask in advance whether the audience will want to drill into details or just hear the summary, so I can prepare accordingly.

How do you handle a situation where your analysis produces unexpected results?

My first assumption is that I have made an error, not that the data is telling me something surprising. I go back and check the query logic, the filters applied, the date ranges, and whether the underlying table has any known data quality issues. I also look for a simpler version of the same question: if I remove one variable at a time, does the result still look wrong? If the result still holds after that review, I look for external factors that might explain it: a product change, a marketing campaign, a data pipeline issue. Only once I have ruled out errors and found a plausible explanation do I present the finding, and even then I flag that it was unexpected and describe the checks I ran. Surprising findings are often the most valuable, but only if they are real.

Tell me about a time your analysis led to a significant business decision.

I was asked to investigate why our trial-to-paid conversion rate had declined over two quarters. I built a funnel analysis segmented by acquisition channel and found that conversion from paid search had dropped sharply, while organic conversion was stable. Digging further, I found that paid search was bringing in users with very different job titles to our core ICP. The cost per acquisition had gone down, but the quality had too. I presented this to the growth team with a recommendation to add an intent signal to the paid search targeting. They tested it and conversion from paid search recovered to previous levels within six weeks. The insight came from segmentation: the aggregate number was hiding a channel-specific problem.

Describe a time you had to work with messy or incomplete data.

I inherited a legacy reporting dataset that had been built by merging three different source tables with inconsistent ID schemes. About 12% of rows had null values in a key join column, and there were clear duplicate events caused by a logging bug that had since been fixed. Rather than ignoring the issues, I documented them, estimated the impact of each on the metrics I needed, and made explicit choices about how to handle each case: nulls were excluded with a note in the analysis, duplicates were deduplicated using a window function on timestamp and user ID. I also flagged the data quality issues to the engineering team, which led to a fix in the pipeline. Every analysis I produced from that dataset included a brief data quality note so stakeholders understood the caveats.

Give an example of when you proactively identified an insight without being asked.

While building a routine weekly report I noticed that mobile users were completing our core workflow at about half the rate of desktop users. Nobody had asked me to look at this. I ran a quick cohort analysis and found the gap had widened sharply over the previous eight weeks, coinciding with a navigation redesign that had shipped on mobile only. I flagged it to the product manager with the data and a hypothesis, and they prioritised a usability review of the mobile flow. The subsequent fix brought mobile completion rates up by 28%. The lesson for me was to always look at the data holistically while doing routine work: the most valuable insights are often hiding in the peripheral view.

Write a SQL query to find the top 5 customers by revenue in the last 90 days.

This is a straightforward aggregation, but I always start by clarifying a few things: does "revenue" mean gross or net? Are we including refunded orders? Is the date filter on order date or payment date? Assuming a simple orders table with customer_id, order_date, and revenue columns, the query would be: SELECT customer_id, SUM(revenue) AS total_revenue FROM orders WHERE order_date >= CURRENT_DATE - INTERVAL '90 days' GROUP BY customer_id ORDER BY total_revenue DESC LIMIT 5. In practice I would also add a check for negative revenue values (refunds) and decide whether to include or exclude them based on the business question. If the schema has a customers table I would JOIN to get the customer name for readability.

How would you detect and handle outliers in a dataset?

My first step is to understand whether an outlier is a data error or a real extreme value, because the treatment is different. For detection, I use a combination of visual inspection (scatter plots, box plots), statistical methods (values beyond 3 standard deviations from the mean, or IQR-based bounds), and domain knowledge checks (a revenue figure of £10 million for a small business account is almost certainly an error). Once I have identified outliers I investigate each category: data errors get corrected or excluded with a note, real extreme values are typically kept but handled carefully depending on the analysis. For summary statistics I often report median alongside mean when there are significant outliers, because the mean can be heavily distorted. I document all decisions so the analysis can be audited.

Explain the difference between a left join and an inner join, and when you would use each.

An inner join returns only rows that have matching values in both tables. A left join returns all rows from the left table and the matching rows from the right table: where there is no match, the right-side columns come back as null. I use an inner join when I only care about records that exist in both tables: for example, joining orders to products where I only want to analyse orders that have a valid product record. I use a left join when I need to keep all records from the primary table regardless of whether a match exists: for example, joining users to orders to find users who have never placed an order (where the order columns will be null). A common mistake is using an inner join when a left join is needed, which silently drops records and can skew metrics without any obvious error.

Data Analyst

Data Analyst interviews test your ability to turn raw data into decisions. Interviewers want to see SQL fluency, a structured approach to analysis, and clear communication of findings to non-technical stakeholders. Preparation matters across all three: the best candidates combine technical skill with business instinct. This guide covers the most common questions and the answers that demonstrate you are ready to deliver insight from day one.

For general interview preparation tips, read our guide to common interview questions.

Common Data Analyst Interview Questions

Behavioral Interview Questions for Data Analyst Roles

Technical Questions for Data Analyst Candidates

What Hiring Managers Look for in Data Analyst Interviews

What hiring managers really look for in Data Analyst candidates:

Business thinking, not just technical skill. The best analysts understand why a number matters, not just how to calculate it.
SQL fluency under pressure. Expect live SQL questions: practice writing queries without autocomplete.
Structured communication. Can you explain a complex finding clearly in two minutes? Practise out loud.
Data quality awareness. Analysts who flag data issues proactively are far more trusted than those who present numbers without caveats.
Intellectual curiosity. Interviewers notice candidates who ask good questions about the data, the business, and the tools. Curiosity predicts long-term performance.

Questions to Ask Your Interviewer

→What does the data stack look like here, and what tools does the team use day to day?
→How mature is the data infrastructure: are there reliable data models and a well-maintained warehouse?
→How does the data team collaborate with product and business stakeholders?
→What does a typical analysis request look like, and how is the team's work prioritised?
→What is the biggest data quality or data access challenge the team is currently working through?

Practice These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free during beta. No commitment.

Related Roles