Business Analytics Internship Interview Questions

An INNER JOIN returns only the rows that have a match in both tables. A LEFT JOIN returns every row from the left table and the matching rows from the right table, with NULLs where there's no match. For example, joining customers to orders with an inner join shows only customers who have ordered; a left join shows all customers, and the ones with NULL order columns are the customers who have never ordered, which is often exactly what the business wants to find.

WHERE filters individual rows before any grouping happens, so it can't use aggregate functions. HAVING filters the groups after GROUP BY, so it can. For example, to find stores with more than 100 orders in 2025, I'd use WHERE to keep only 2025 orders, GROUP BY store, and then HAVING COUNT(*) > 100.

First I try to understand why it's missing or messy, because the reason changes the fix. I check how much is affected and whether it's random or concentrated in one group. Then I decide: remove rows if it's a small, random share; fill values, for example with a median, if that's reasonable; or keep a flag so the gap is visible. I also standardize things like date formats and duplicate names. Whatever I do, I note it with the results so nobody is misled.

Correlation means two variables move together; causation means a change in one actually produces a change in the other. Ice cream sales and sunburns are correlated, but both are caused by hot weather, which is a confounding variable. To show causation in business, the best tool is a controlled experiment like an A/B test, where the only difference between two groups is the change you're testing.

I'd run an A/B test. Before starting, I'd agree on one main metric, like conversion rate, and how big a change would matter. Users would be randomly split so half see the new feature and half don't. I'd run it long enough to cover full weeks and reach the sample size we need, then check whether the difference is statistically significant rather than stopping as soon as it looks good. I'd also check a guardrail metric, like page load time, to make sure we didn't break something else.

It depends on the question. For how something changed over time, like monthly revenue, I'd use a line chart. To compare categories, like sales by region, a sorted bar chart. To show the relationship between two numbers, like ad spend and sign-ups, a scatter plot. I'd keep labels clear and put the takeaway in the title, like 'Sign-ups rose 20 percent after the redesign', so the reader doesn't have to work it out.

I'd start with the answer, not the method: 'Customers who use the mobile app spend about 20 percent more, so I'd recommend promoting it at checkout.' Then I'd show one simple chart and the one or two numbers that support it, and mention any important limitation in plain language. I'd keep the technical details in an appendix in case they want them. In my [course or project], presenting it that way is what got the team to act on the result.

I'm strongest in Excel — I use pivot tables, XLOOKUP and charts regularly, and I built [a model or tracker] for [project]. I've used SQL in my [course] to query a sales database with joins and aggregations, and I've built dashboards in [Tableau or Power BI] for a class project. I'm currently learning Python with pandas through [course or certification]. If your team uses a different tool, I'm comfortable picking it up quickly.