Power BI Developer interview questions and practice.
Designs data models and interactive dashboards in Microsoft Power BI, using DAX and Power Query to shape the data.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
This page is still being written: no authored question bank for this competency family. The role is fully supported in the interview itself; only the published question bank is outstanding.
What interviewers for Power BI Developer actually ask
The question bank for this role is still being written. These are the first three competencies in the model the interview is scored against.
Elicits what decisions a report must support, defines metrics precisely with the business, and resolves conflicting definitions across departments.
Designs models (star schemas, semantic layers, measures) that make reports fast, consistent and self-service friendly, and avoids the common traps of flat tables and many-to-many joins.
Designs dashboards that answer the audience's question at a glance: clear hierarchy, right chart types, honest scales, sensible filters and fast load times.
What they are really assessing
Interviewers rarely score whether you seemed nice. They score against a model like this one, usually without telling you it exists. Each competency has a weak, adequate and strong shape, and the difference is almost always the level of specific detail you volunteer without being asked.
Requirements gathering & metric definition
Elicits what decisions a report must support, defines metrics precisely with the business, and resolves conflicting definitions across departments.
- Weak
- Builds the report as specified; cannot say what decision it supports or how a metric is calculated; conflicting definitions between departments go unresolved.
- Adequate
- Asks about intended use and documents metric definitions, but conflicts between teams are escalated rather than resolved and definitions drift over time.
- Strong
- Describes reconciling two departments' definitions of the same metric, how they got agreement and documented it in a governed layer, and how the report changed a decision.
Semantic & data model design
Designs models (star schemas, semantic layers, measures) that make reports fast, consistent and self-service friendly, and avoids the common traps of flat tables and many-to-many joins.
- Weak
- Connects directly to source tables or one flat extract per report; cannot explain fact and dimension tables, relationships or why numbers differ between reports.
- Adequate
- Builds star-schema models with defined measures and relationships and has fixed a wrong total caused by a bad relationship, but performance and reuse across reports are limited.
- Strong
- Describes a shared semantic model with reusable measures, how it eliminated conflicting numbers across reports, the performance techniques used (aggregations, incremental refresh), and a modelling mistake they corrected.
Dashboard design & usability
Designs dashboards that answer the audience's question at a glance: clear hierarchy, right chart types, honest scales, sensible filters and fast load times.
- Weak
- Dashboards are cluttered with every available chart; no evidence of user feedback; cannot say who uses a dashboard or whether it is used at all.
- Adequate
- Applies good visual practice and gathers feedback from users, but usage is not measured and dashboards accumulate without retirement.
- Strong
- Gives a dashboard redesign driven by usage data and user interviews, the design choices made (hierarchy, chart types, interactions) and the measured change in adoption or decision speed.
Data accuracy & reconciliation
Ensures reported numbers are right and trusted: validates against source systems and finance, tests refreshes, and communicates caveats and known issues.
- Weak
- Assumes the data is right; cannot describe reconciling a report to the source or a wrong number that reached executives and how it was handled.
- Adequate
- Reconciles key figures to finance or source systems and documents caveats, but checks are manual and issues are found after publication.
- Strong
- Describes an automated reconciliation or test they built, a wrong number caught before or after publication and how they communicated it, and how trust in the reports was measured or restored.
SQL & data transformation
Writes efficient SQL and transformation logic to prepare data for reporting, and diagnoses slow or incorrect queries.
- Weak
- Relies on the BI tool's drag-and-drop or on others for SQL; cannot debug a slow query or a wrong join.
- Adequate
- Writes joins, aggregations and window functions confidently and has optimised a slow query, but transformation logic lives in individual reports rather than a shared layer.
- Strong
- Describes moving transformation logic from reports into a tested, shared layer, a query performance fix with measured improvement, and a join error they caught by reconciliation.
Self-service enablement & governance
Enables business users to answer their own questions safely through certified datasets, training and governance, while controlling sprawl and access to sensitive data.
- Weak
- Every question becomes a ticket; no certified datasets; no view on who can see what or how many duplicate reports exist.
- Adequate
- Has published certified datasets and trained users, but sprawl and access are managed reactively.
- Strong
- Describes a self-service programme with certified datasets, row-level security, training and usage metrics, and the measured reduction in ad hoc requests or duplicate reports.
Stakeholder management & saying no
Manages a queue of competing requests by business value, negotiates scope, and handles executives who want a different number.
- Weak
- Builds whatever is asked in the order asked; cannot describe declining a request or handling an executive disputing a figure.
- Adequate
- Prioritises with their manager and has handled a disputed number, but the dispute left the relationship strained.
- Strong
- Gives a case of reprioritising with stakeholder agreement based on decision value, and one of walking an executive through why their number differed and reaching an agreed definition.
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level Power BI Developer and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns BI for a business area: semantic models, dashboards, metric definitions and request prioritisation; accountable for accuracy.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: eliciting the decision a dashboard must support before building it, defining and governing a metric used by multiple departments and designing a star schema and relationships in Power BI, Tableau or Looker, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns defined reports and dashboards end to end with review; maintains recurring reports. | Owns BI for a business area: semantic models, dashboards, metric definitions and request prioritisation; accountable for accuracy. | Owns BI architecture and governance across departments: platform standards, certified datasets, security and performance. |
| Tolerance for ambiguity | Clarifies requirements with requesters and documents assumptions. | Turns vague reporting asks into defined metrics and models; resolves definition conflicts. | Defines the reporting strategy from business goals; makes platform and governance decisions with incomplete information. |
| People leadership | No formal leadership. | Mentors juniors and reviews their work. | Leads BI developers technically, sets standards, may manage a small team. |
| Who they deal with | Own team, a few business requesters, line manager. | Business managers, finance, data engineers, analysts. | Heads of department, executives, data engineering and IT leadership, vendors. |
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong Power BI Developer would have said them.
- Gives a dashboard redesign driven by usage data and user interviews, the design choices made (hierarchy, chart types, interactions) and the measured change in adoption or decision speed.
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report