BI Tools
Power BI and Tableau, the semantic layer underneath them, and dashboards people actually use.
The Last Mile
The tool matters less than the two things around it: a model shaped for the questions being asked, and one agreed definition per metric. Where those are missing, no visualisation layer saves you — you get three dashboards with three revenue numbers and a meeting about which is right.
Power BI
Microsoft's tool, and the default anywhere the organisation already runs Office and Azure. Modelling happens inside it: relationships between tables, then measures written in DAX.
Revenue = SUM(fact_orders[net_amount])
Revenue YoY % =
VAR Current = [Revenue]
VAR LastYear = CALCULATE([Revenue], SAMEPERIODLASTYEAR(dim_date[date]))
RETURN DIVIDE(Current - LastYear, LastYear)| Strength | Cost |
|---|---|
| Cheap per seat, ubiquitous in Microsoft shops | DAX has a genuinely steep learning curve |
| Strong modelling and time intelligence | Logic can end up living only in the report |
| Import mode is very fast | Refresh schedules and dataset size limits |
Tableau
Tableau leads on exploration and visual craft: drag a field, see a chart, follow the question wherever it goes. It is the stronger tool for analysts investigating something, and its defaults produce better-looking charts with less effort.
| Power BI | Tableau | |
|---|---|---|
| Best at | Modelling and governed reporting | Exploration and visual analysis |
| Calculation language | DAX | Calculated fields, LOD expressions |
| Cost | Low per seat | Higher |
| Fits | Microsoft estates | Analyst-heavy teams, any stack |
Both converge on the same failure mode. Once metric logic is written inside the tool, two reports drift apart and nobody can say which definition of "active customer" is the real one — which is the argument for a semantic layer.
The Semantic Layer
A semantic layer holds metric definitions once, outside any dashboard: revenue, active customer, churn — defined in version-controlled code, computed in the warehouse, and consumed identically by every tool and every notebook.
| With one | Without one |
|---|---|
| One definition, reviewed in a pull request | The same metric written in four dashboards |
| Changes propagate everywhere | Some reports quietly stay on the old rule |
| Lineage from metric to source table | Nobody knows where the number came from |
| Consistent across BI, notebooks and APIs | Numbers depend on which tool you opened |
Interview Questions
Power BI or Tableau?
Power BI where the organisation is Microsoft-based and reporting is governed — cheap seats, strong modelling, DAX. Tableau where analysts explore and visual quality matters. Both are fine; the model beneath them matters more.
Import versus DirectQuery?
Import copies data into the tool: fast, but stale between refreshes and bounded by dataset size. DirectQuery queries the warehouse live: always fresh, but dashboard performance becomes warehouse performance.
Why does a semantic layer matter?
It defines each metric once, in version control, so every dashboard and notebook computes it the same way. Without it the same metric gets rewritten per report and the numbers drift apart.
Why do dashboards end up with conflicting numbers?
Metric logic written inside the reporting tool. Two authors implement "active customer" slightly differently and nothing reconciles them.
What makes a dashboard good?
It answers a specific question for a specific person. The headline numbers a decision needs first, drill-down beneath, and nothing on it that does not support an action.
What is the biggest cost of a wide dashboard?
Attention. Forty charts arranged by source table means nobody finds the two that matter, so the dashboard stops being opened at all.