Data Analyst Interview Questions

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.

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.

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.

AI has changed how I handle several parts of my workflow. For SQL, I use it to generate first-draft queries for complex joins or window functions: it usually gets the structure right, though I always check the logic carefully before running anything on production data. For Python scripts, I describe what I need and get a working starting point in seconds rather than minutes. For presenting findings, I use AI to help write the narrative that accompanies charts: given the numbers and the context, it generates options for how to tell the story that I then shape and edit. I have also found it useful for data cleaning tasks where the logic is clear but the code is tedious. Where I do not rely on it is final interpretation: the analyst job is understanding which patterns actually matter for the business, and that requires context the model does not have. I also never put sensitive or proprietary data into consumer AI interfaces.

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.

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. 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, duplicates were deduplicated using a window function. 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.

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

This is a straightforward aggregation, but I always start by clarifying: 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 check for negative revenue values (refunds) and decide whether to include or exclude them. If there is a customers table I would JOIN to get the customer name for readability.

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 visual inspection (scatter plots, box plots), statistical methods (values beyond 3 standard deviations, or IQR-based bounds), and domain knowledge checks. Once identified, I investigate each: data errors get corrected or excluded with a note; real extreme values are typically kept but handled carefully. 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.

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: where there is no match, the right-side columns are null. I use an inner join when I only care about records that exist in both tables. 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. 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.