Data Analyst Interview Questions

An INNER JOIN returns only rows that match in both tables, so any customer who has never placed an order simply disappears from the result. A LEFT JOIN keeps every row from the left table and fills unmatched columns with NULLs, which is exactly what I want when I am auditing gaps: customers with no orders, users who signed up but never activated, products that have never sold. The mistake I see most often is using an INNER JOIN to calculate retention and quietly dropping churned users from the denominator. That inflates the retention rate and no one notices until leadership asks why the cohort sizes shrink month over month. I always ask which rows need to survive before I write the join.

I start with a coin flip analogy. I tell the stakeholder: imagine you flip a coin ten times and get eight heads. A p-value answers one question: if the coin were perfectly fair, how often would you get a result at least this extreme just by luck? If the answer is 5% of the time or less, we say the result is statistically significant. I am careful not to say the p-value is the probability we are right. It is the probability of seeing our data if nothing is going on. A small p-value means our result would be rare by chance alone. It does not mean the effect is large or important. Statistical significance is about ruling out luck, not about measuring value.

Before I open any tool, I ask five things. First, who is the primary audience, and how often will they look at it? Second, what decision is this dashboard supposed to support? Third, what data sources are available and how fresh does the data need to be? Fourth, is this a one-time view or something that needs to stay maintained? Fifth, what does success look like: what would make a stakeholder say the dashboard is working? "Quick" usually means different things to different people. A five-minute exploratory view and a production-ready decision support tool are built very differently. Clarifying audience, decision, and freshness requirements upfront prevents building the wrong thing fast.

My first move is to check instrumentation, not the product. A 15% overnight drop is more likely a broken event pipeline, a misconfigured tracking tag, or a timezone shift in the reporting query than a real behavior change. I pull raw event counts from source tables and compare them to the dashboard number. If they match, the data is real, and I move to segmentation: break the drop by platform, geography, acquisition channel, and user cohort to find a clean fault line. A single segment driving the whole drop points to a product issue, a release, or an external event. If the drop is uniform across all segments, I suspect infrastructure: a login service outage, a broken push notification, or a payment failure. I only form a root-cause hypothesis after I have localized the drop.

My default is SQL for anything the database can do well: filtering, joining, aggregating, and returning a clean result set. SQL runs close to the data, scales with the engine, and keeps transformation logic visible to the whole team. I reach for Python when the work outgrows what SQL handles gracefully: iterative transformations, multi-step cleaning pipelines, statistical modeling, or any output that feeds a chart or a report. The clearest signal is when I find myself writing deeply nested subqueries just to apply a formula: that work belongs in pandas. The antipattern is pulling millions of rows into Python to do something a GROUP BY would have handled in seconds at the source.

A product manager came to me needing data to justify shipping a feature the team had already committed to publicly. I asked a few clarifying questions and realized the launch was already announced internally. Rather than pulling confirming numbers, I ran the full analysis first and found conversion lift was positive but only for one user segment. I then reframed the presentation: I gave the PM the headline result plus a clear segment breakdown that showed where the feature would underperform. I said the data supported the decision but flagged where to watch post-launch. The PM used the segmentation to set realistic expectations with the exec team. The feature shipped and the segment finding became a follow-on project the next quarter.