BI Analyst Assessment

Why BI Analysts are hard to hire well

The product of a BI Analyst is not a dashboard. It is trust in a number, and trust is slow to build and instant to lose. One board meeting where two directors quote different figures for the same metric will undo two years of reporting work, and the analyst who caused it will usually have shipped something that looked, at the time, entirely reasonable.

This makes the role structurally different from the analysis work it is often confused with. An analyst answers a question once. A BI Analyst commits to answering it the same way forever, for people who will never read the definition, in a tool that will still be running after they have left. The skill being hired is durability, and nothing in a normal interview process tests durability.

The market has also flooded the title with tool certifications. Power BI and Tableau both run credential programmes, and both certify feature knowledge: what a calculated column is, how to configure a row-level security rule. None of that touches the two things that actually determine whether the hire works out, which are whether they can model data sensibly and whether they will hold a definition steady when a senior stakeholder wants it bent.

What separates the best from the rest

The best BI Analysts design the model before they design the chart. They understand that a dashboard is the visible three per cent of the work and that everything determining its performance, its consistency and its lifespan lives in the layer beneath. Weaker candidates start in the visualisation tool, build something that looks impressive against a small extract, and discover eighteen months later that it cannot be extended without a rewrite.

They are unusually disciplined about naming. Two metrics that are almost the same get two names, not one name and a caveat. A metric with an owner and a written definition survives; a metric with a tooltip does not. This sounds like bureaucracy and it is precisely the opposite: it is what prevents the slow drift where a figure means one thing in January and something else by November, with no single change anyone can point to.

The final divide is how they treat low adoption. A weak analyst reports usage numbers and blames the business for not engaging. A strong one treats an unopened dashboard as a defect in their own work, goes and watches somebody try to use it, and usually finds the problem is a filter that defaults wrongly or a metric named in a language only the data team speaks.

Why interviews alone fall short

BI interviews tend to become tool demos. The candidate walks through a dashboard they are proud of, and it looks good, because they chose it and have shown it before. You learn nothing about the fifty they built that nobody opened, nothing about how the underlying model was structured, and nothing about what they did when the source system changed its schema without warning.

What you actually need to observe is refusal and negotiation: what the candidate does when a stakeholder asks for a metric that will conflict with an existing one, when the requested breakdown is not supported by the data available, or when two teams both believe they own a definition. Situational scenarios put those moments in front of every candidate on identical terms, which is the only way to compare governance instincts rather than portfolio quality.

Common hiring mistakes in business intelligence recruitment

• Weighting tool certification above modelling ability - certifications test what the software can do, and the hard part of the job is deciding what the data should look like before the software gets involved
• Confusing BI with data science - hiring someone who wants to build models into a role that is mostly definitions, refreshes and stakeholder requests produces a resignation within a year
• Judging a portfolio dashboard on how it looks - visual polish is the cheapest thing to acquire and the least predictive of whether the reporting will still be trusted in two years
• Never asking about a refresh failure - most of the operational reality of BI is broken schedules and silent data gaps, and candidates who have never owned an SLA do not know this yet
• Skipping the governance question - an analyst who will build whatever is requested, exactly as requested, will generate the metric sprawl you are hiring them to end

The work this role is assessed against

• Gather and refine reporting requirements; map to source data and KPIs
• Write and optimise SQL; implement DAX, LookML or Power Query; build star schemas and views
• Develop and iterate dashboards; apply visualisation best practices and UX standards
• Set up schedules, data refresh pipelines, and alerting; troubleshoot data and performance issues
• Create documentation, data dictionaries, and training materials; run enablement sessions

Tools and outputs this role works with

SQL (PostgreSQL, SQL Server, MySQL), Power BI (DAX, Power Query M), Tableau, Looker and LookML, Qlik Sense, Excel or Google Sheets, Snowflake, BigQuery, Amazon Redshift, Azure Synapse, dbt, Airflow, Fivetran or Stitch, Salesforce as a data source, Git and GitHub, Jira and Confluence, Collibra or Alation, and Python or R for light analysis and automation.