Hire a Power BI Consultant: 2026 Screening Framework & Questions

Hiring a Power BI consultant is where most enterprise BI programs fail before they start. The candidate has certifications, LinkedIn endorsements, and a portfolio of dashboards — but 90 days into the engagement, the semantic model is a mess, the DAX is slow, and nobody knows why. The problem isn't a shortage of consultants. The problem is that the standard hiring process rewards the wrong signals: certifications over judgment, dashboard aesthetics over data model discipline, confident answers over correct answers. This guide gives you a screening framework that reliably separates the real senior consultants from the resume. Twelve technical questions with expected answers. Three practical exercises the candidate should complete during the interview. Reference-check script. Scoring rubric.

The Three Signals That Matter

Every good Power BI consultant demonstrates the same three qualities, in this order:

1. Data model discipline. Do they build star schemas or single-table designs? Do they know when calculated columns are appropriate and when measures are the right answer? Can they diagnose a bad model in five minutes? A consultant without model discipline will ship reports that break under load and require rewrite within 12 months.

2. DAX depth. Can they debug a slow measure? Can they explain the difference between CALCULATE with a filter argument and CALCULATE with FILTER over a table? Do they understand row context vs filter context? A consultant without DAX depth will produce reports that produce wrong numbers under RLS and that consume 3-5x the CU they should.

3. Enterprise judgment. Do they push back when you ask for the wrong thing? Do they think about governance, security, and cost from day one, or only when reminded? Do they know when to say "this isn't a Power BI problem, this is a data engineering problem"? A consultant without judgment will build technically-correct solutions that solve the wrong problem.

The 12 questions and 3 exercises below test all three signals.

Twelve Technical Screening Questions

Data Model Discipline (Questions 1-4)

Q1. Walk me through when you would use a calculated column versus a measure. Give me an example of each from a real engagement.

*Expected answer*: Calculated columns are row-level derivations stored in the model, evaluated at refresh time. They increase memory and slow refresh but are queried like any other column. Use for row-level derivations that will appear in filters or slicers (e.g., customer age bucket). Measures are aggregations evaluated at query time, no memory cost. Use for anything you'd normally SUM, COUNT, or aggregate across rows. Watch for the answer "measures are always better" — that's a memorized rule, not judgment.

Q2. A user asks you to add a table to the model. It has 500 million rows. Walk me through your decision process.

*Expected answer*: First questions: what queries will use it, what's the grain, what filters will apply. Options: (a) star-schema fact table if it's transactional, (b) aggregated table if the queries are always summary-level, (c) Direct Lake+ mode if on Fabric F64+, (d) DirectQuery if data must be live, (e) push back — is a semantic model the right home for this? Bad answer: "I'd import it."

Q3. Explain what "role-playing dimensions" are and give an example.

*Expected answer*: A single dimension table joined multiple times to a fact via different relationships — e.g., a Date dimension joined to OrderDate, ShipDate, and DueDate. In DAX, you use USERELATIONSHIP inside CALCULATE to activate the inactive relationship. Bad answer: "I create multiple date tables." That works but shows they haven't learned the correct pattern.

Q4. When would you use a bidirectional relationship, and why is it usually a bad idea?

*Expected answer*: Bidirectional is required for many-to-many filtering (e.g., customer-to-customer group relationships). It's usually a bad idea because it creates ambiguity in filter propagation, hurts performance, and is a common source of wrong-number bugs. Prefer single-direction plus explicit CROSSFILTER in DAX where needed. Bad answer: "I turn bidirectional on by default."

DAX Depth (Questions 5-8)

Q5. Explain the difference between these two measures. When would you use each?

``` Sales_A := CALCULATE([Total Sales], Products[Category] = "Bikes") Sales_B := CALCULATE([Total Sales], FILTER(Products, Products[Category] = "Bikes")) ```

*Expected answer*: Sales_A uses a simple filter argument that overrides any existing filter on Products[Category]. Sales_B uses an iterator over the Products table that respects existing filters — it applies "Bikes" as an additional filter on top of whatever filter already exists. Both return the same result in simple cases. Sales_B is slower (iterator) and preserves existing filter context; Sales_A is faster (predicate pushdown) and overrides. Use Sales_A for straightforward "give me sales where category = Bikes" and Sales_B when you need to preserve other filters on the Products table.

Q6. A report page has 15 measures. It takes 12 seconds to render. Walk me through your performance diagnosis process.

*Expected answer*: Start with DAX Studio. Capture the queries generated for each visual. Identify the top 3 slowest queries by duration. For each: run in Server Timings, look for high storage-engine time (indicates model design issue, aggregation opportunity, or partitioning issue) vs high formula-engine time (indicates DAX rewrite opportunity). Common fixes: replace iterator-heavy measures with predicate pushdown, add aggregation tables, reduce cardinality of high-column tables. Bad answer: "I add more memory" or "I use aggregations" without asking about the specific bottleneck.

Q7. Explain row context vs filter context. Give me a scenario where a consultant would confuse them.

*Expected answer*: Row context exists inside iterators (SUMX, AVERAGEX, FILTER, calculated columns) — it points at "the current row being iterated." Filter context is the set of filters that constrain the query (from slicers, page filters, visual filters, CALCULATE modifiers). Common confusion: writing SUMX(Sales, Sales[Amount] * RELATED(Products[Price])) expecting Sales[Amount] to be the running row's amount (correct) but also expecting Products[Price] to filter by the row's product (wrong without RELATED). Bad answer: unable to give a clear example.

Q8. What does CALCULATETABLE do differently from CALCULATE?

*Expected answer*: CALCULATE returns a scalar; CALCULATETABLE returns a table. Otherwise semantically identical. Use CALCULATETABLE when you need the filtered table as an input to another function (e.g., inside another iterator, or as the FROM argument of TOPN). Bad answer: "They're the same."

Enterprise Judgment (Questions 9-12)

Q9. A stakeholder asks for a dashboard that combines data from 8 source systems. What are your first three questions back to them?

*Expected answer*: (1) What decision will this dashboard enable? (2) What's the refresh cadence you need? (3) Who owns each source system, and what's the current state of the data quality? A good consultant reflexively questions scope, not because they're pushing back but because badly-scoped dashboards fail. Bad answer: "When do you need it by?"

Q10. A client tells you their Fabric capacity is being throttled. What do you look at first?

*Expected answer*: Capacity Metrics App. Identify the top CU consumers by workload (Power BI reports, semantic model refresh, notebooks, Data Factory pipelines, Copilot). Identify the top items within the top workload. Look at the throttling events — are they compounding (CU debt accumulating) or spike-based (background jobs at 3am)? Fix candidates: aggregations for heavy queries, refresh scheduling, DAX rewrites for hot measures, capacity upgrade only if all else fails. Bad answer: "Upgrade capacity."

Q11. When would you tell a client Power BI is the wrong tool for their problem?

*Expected answer*: (a) They need real-time (sub-second) analytics — that's KQL / Real-Time Intelligence or a purpose-built streaming tool. (b) They need operational OLTP — that's SQL Database, not Power BI. (c) They need heavy predictive modeling — that's Azure ML or Fabric Data Science, not Power BI. (d) They need reporting with pixel-perfect layout and mail-merge — that's Paginated Reports or an operational reporting tool. A consultant who has never turned down a Power BI project is a hammer looking for nails.

Q12. Describe a Power BI engagement where you were wrong about your initial approach and had to change direction. What did you learn?

*Expected answer*: A concrete story. What the initial approach was, what signal caused them to change, what the new approach was, and what specifically they'd do differently next time. Bad answer: "I always get it right the first time" or a generic non-answer.

Three Practical Exercises

Written questions cover 60% of screening. The rest requires seeing them work. Three exercises they should complete during the interview or as a paid 4-hour take-home:

Exercise 1 — Diagnose a bad semantic model. Send them a small PBIX with a single-table design (denormalized, calculated columns for aggregations, no explicit measures, bidirectional relationships to a poorly-defined date table). Ask: "This model works but users complain it's slow. What would you change and why?" Good candidates identify the single-table anti-pattern, the calculated-column-vs-measure issues, and the date-table problem within 20 minutes. Bad candidates start rewriting individual DAX expressions without questioning the model.

Exercise 2 — Rewrite a slow measure. Give them a slow DAX measure (typically an iterator over a large fact table with nested CALCULATE inside SUMX). Ask them to make it faster. Good candidates identify the iterator, the row-context issue, and rewrite using predicate pushdown or an aggregation table. Bad candidates make cosmetic changes.

Exercise 3 — Design a small architecture on paper. Give them a business scenario: "We're a 5,000-employee healthcare company adopting Power BI. Sketch me the target architecture." Good candidates draw workspaces, semantic model portfolio, deployment pipeline, RLS strategy, capacity sizing, and governance council. They ask clarifying questions about compliance and existing data platform. Bad candidates draw a single workspace with 30 reports in it.

Reference-Check Script

Skip references at your peril. When you talk to references, ask:

1. What was the specific role and scope of the engagement?
2. What percentage of the deliverables would you say were on-time and on-budget?
3. Give me an example of a technical decision the consultant made that you now think was correct.
4. Give me an example of a technical decision you now think was wrong.
5. Would you hire them again, and if so, for what specific type of work?
6. What kind of work should they not do?
7. On a scale of 1-10, how would you rate their communication with non-technical stakeholders?

References who cannot answer question 4 are not real references. A consultant who has never made a decision the client later disagreed with either hasn't done real work or has a reference who isn't paying attention.

Interview Scorecard

Score each question 0-3: - 0 — wrong answer, confused, memorized without understanding. - 1 — correct but shallow, hits the surface without depth. - 2 — correct with depth, shows understanding of edge cases or trade-offs. - 3 — exceptional, gives an example, connects to other topics.

Scoring rubric (of 36 total from 12 questions + up to 9 from exercises): - 34-45: hire, target the top tier of your engagement. - 28-33: hire, appropriate for senior-consultant tier engagements. - 20-27: hire only for supervised or scoped junior work. - Under 20: do not hire for a senior role. Junior track only or pass.

Related Guides

• Power BI Consulting Cost: Transparent 2026 Pricing Guide
• Microsoft Fabric Consulting: 90-Day Activation Runbook
• Power BI Deployment Pipelines with PBIP + fabric-cicd
• Power BI Consulting Services

Ready to run a real screening on the next Power BI consultant you interview? Request the printable scorecard PDF.