Business Intelligence Analyst Interview Questions for AI Training Work

A dashboard metric needs to be something stakeholders check repeatedly to make ongoing decisions, and it needs a stable, well-understood definition. If a metric requires a fresh explanation every time someone looks at it, or the underlying question only comes up occasionally, it's better as an ad hoc analysis than a permanent dashboard tile that adds clutter without recurring value.

I'd aggregate the KPI by month first, then use the LAG window function partitioned appropriately and ordered by month to pull the prior month's value into the same row. From there the percentage change is a straightforward calculation between the current and prior value, which avoids the self-join that a lot of analysts default to for this kind of comparison.

I start from the grain of the fact table, since getting that wrong makes everything downstream harder to reconcile. Conflicting reporting needs usually mean different teams want different aggregation levels, which is solved by keeping the fact table at the most granular useful level and letting each report aggregate up from there, rather than pre-aggregating and locking in one team's view.

I reconcile the dashboard total against a known source, often a manually run query or an existing trusted report, for at least a few time periods before publishing. I also sanity-check edge cases like the most recent partial period and any known one-off events, since those are the spots where a dashboard is most likely to show a misleading number.

I ask what decision the visualization needs to support before picking a chart type, since that determines whether they need a trend over time, a comparison across categories, or a distribution. Defaulting to a line chart for trends and a bar chart for comparisons covers most business questions, and I avoid pie charts and 3D effects, which tend to obscure rather than clarify.

I'd walk through the definitions and filters behind both numbers side by side rather than assuming either one is simply wrong. Most of these discrepancies come from different date ranges, inclusion criteria, or timing of when data was pulled. Once the actual source of the difference is identified, it's usually clear which number, if either, needs to be corrected.

I would build the report as requested but include the additional context that changes the interpretation, rather than either refusing the request or delivering a report I believe is misleading by omission. My job is to make sure the decision-maker has the full picture, not to editorialize on their behalf or withhold analysis because I disagree with where it might lead.

I would fix the calculation and flag the error transparently to everyone who relies on the dashboard, including how long the error was live and roughly how it affected past reported numbers. Quietly fixing it without disclosure risks people making decisions based on a number they don't know changed, which is worse than the original error.

A team believed a metric decline was gradual until I broke the same data down by weekly cohort instead of a single monthly trend line, which showed the decline was actually a sharp drop tied to one specific week. The right level of granularity in the visualization, not new data, was what changed their understanding of the problem.

I dropped the statistical methodology from the presentation entirely and led with the business implication, keeping the methodology available as backup for anyone who asked. Leading with what the finding meant for their decision, rather than how I arrived at it, is what made the analysis land with a non-technical audience.