Power BI Developers/Learning
1.34K subscribers
27 photos
7 files
148 links
Download Telegram
Before Fabric — a typical enterprise data stack looked like this:
Azure Data Factory → for pipelines
Azure Synapse → for warehousing
Azure Databricks → for data science
Power BI Premium → for reporting
Azure Data Lake → for storage
5 different tools. 5 different licenses. 5 different teams.

With Microsoft Fabric — it's now: ONE platform
ONE OneLake storage
ONE license
ONE unified workspace Pipelines
Lakehouse
Warehouse
Notebooks
Power BI
Copilot
All in one place. No data movement. No silos. The cost saving alone is making CFOs pay attention. The productivity gain is making data teams move faster than ever.

Yet in most Indian IT companies today:
→ Teams are still running on Synapse + ADF + Power BI separately
→ Data engineers and BI developers work in silos
→ Nobody has even opened a Fabric workspace yet
The companies that move to Fabric in the next 12 months will have a serious competitive advantage.
🙏1
Interview Highlights!!

EY — Power BI Developer Technical Round (14 LPA)
Panel: 2
Interviewers Duration: 55 Minutes

Q1. How do you identify and fix a table scan that should be a seek?
Q2. What is the difference between a heap and a clustered table in SQL Server?
Q3. Explain CALCULATE with FILTER vs CALCULATE with a boolean condition directly — which is better and why?
Q4. What is ALLNOBLANKROW, and when do you need it?
Q5. Scenario: RLS needs to hide an entire table from one user role but show it to others. How do you do this without breaking their other reports?
Q6. What is OneLake, and how is it different from a regular ADLS Gen2 container?
Q7. Difference between a Fabric Lakehouse and a Fabric Warehouse — when do you pick each?
Q8. Scenario: A dataset refresh succeeds but the report shows yesterday's numbers. Where do you check first?
Q9. What is Direct Lake mode, and how is "framing" different from a traditional refresh?
Q10. What is a bridge table, and when is it better than a direct many-to-many relationship? Q11. Explain ISFILTERED and ISCROSSFILTERED — how are they different?
Q12. Scenario: A Direct Lake report suddenly starts showing "DirectQuery" in Performance Analyzer instead of Direct Lake. What caused the fallback?
Q13. What causes "ambiguous relationship path" errors, and how do you resolve them?
Q14. How does a Fabric capacity (F-SKU) get shared across Power BI, Lakehouse, and Data Factory workloads? Q15. How do you version-control a Power BI project (PBIP / Git integration)?

Pc: Srinivasalu B V
5 years ago, a good BI developer could survive by knowing Power BI really well I don’t think that’s enough anymore….

Not because Power BI is becoming less important.

Because the BI ecosystem is becoming much bigger.

Today, a strong BI developer should understand what happens beyond the report:

🔹 Data Engineering
How data is ingested, transformed and stored.

🔹 Microsoft Fabric
Lakehouse, Warehouse, Pipelines, Notebooks, Dataflows and more.

🔹 Semantic Modeling
Not just creating relationships, but building a model that can actually answer business questions.

🔹 Data Governance
Who owns the data?
Can we trust it?
Where did it come from?

🔹 AI & Copilot
How do we make our data understandable and useful for AI?

🔹 Performance & Architecture
Why is a report slow?
Where should the transformation happen?
Import, Direct Lake or DirectQuery?


Power BI is still the tool but understanding the entire data journey is becoming the real skill.
Power BI is quietly becoming a developer platform.

Most Power BI updates are about another visual, another formatting option, or another small improvement. But the August 2026 release feels different.

Look at the direction:
PBIP → Git → VS Code → Semantic Models → OneLake → Fabric

That's not just a dashboarding workflow anymore.

It's starting to look a lot more like software development. Power BI is moving from:

“Build a report → Publish it”

towards:

“Develop → Version → Govern → Deploy → Scale”

Features like Theme Pane going GA, improvements around semantic model refresh, and continued investment in PBIP + developer tooling are small pieces of a much bigger shift.

The interesting question isn't: “What new features did Power BI get this month?”

It's: “What is Microsoft trying to turn Power BI into?” I think we're going to see the answer more clearly over the next few releases. Power BI isn't just becoming better at making dashboards. It's becoming better at building BI products.
🔥1
📊 How does the choice of Power BI storage mode affect report performance with Azure Databricks?

Liping Huang's new white paper, Modern Power BI Architecture Choices For Reporting On Azure Databricks, focuses exclusively on performance benchmarking. It compares four ways of serving the same Delta tables to a Power BI report:


🔹 Direct Lake on OneLake
🔹 Direct Lake on mirrored Unity Catalog tables—shortcuts with no data copy
🔹 DirectQuery on a Databricks SQL warehouse
🔹 Composite Model—DirectQuery with Import-mode aggregations
Explore the benchmark results to understand the performance characteristics of each architecture.
Interview tip💡

What if there is NO active relationship and NO inactive relationship between two tables in Power BI? 🤔

Which DAX function would you use to create a relationship-like behavior between the tables?

Most developers immediately think of:

USERELATIONSHIP()

But here's the catch...

USERELATIONSHIP() cannot help if no relationship exists in the data model. It only activates an existing inactive relationship. If there is no relationship at all, there's nothing for USERELATIONSHIP() to activate.

The correct answer is: TREATAS()

TREATAS() creates a virtual relationship by applying values from one table as filters on another table during measure evaluation.

Example Sales Amount = CALCULATE( SUM(Sales[Amount]), TREATAS( VALUES(Customer[CustomerID]), Sales[CustomerID] ) )

How It Works
🔹 Takes values from one table
🔹 Applies those values as filters to another table
🔹 Simulates a relationship without creating a physical model relationship
🔹 Useful when working with disconnected tables
Microsoft just quietly changed what Fabric is.

And if you’re in data, you need to understand this shift🔺

At Build 2026, Microsoft announced that Fabric is going agentic.

It’s no longer just a data analytics platform. It’s becoming the backend for AI agents.

Let me break down what’s actually new

👇 Agent Skills for Power BI (now in preview) AI assistants can now:
▸ Create semantic models on their own
▸ Author PBIR and PBIP report files
▸ Manage reports end to end without manual intervention

“Power BI Modeling MCP Server” -
This one’s big for anyone who follows AI tooling.
- A skill can now call a Power BI Modeling MCP server to build a semantic model directly.

- That means AI agents aren’t just reading your data anymore. They’re modelling it.

Here’s the real shift nobody is saying out loud:

Then → Fabric was the platform where analysts built things for stakeholders.

Now → Fabric is the platform where agents build things for analysts.

Your job isn’t disappearing.
But the entry point for what you need to know just moved higher.

The analysts who understand semantic models, governed data, and how MCP servers work will be the ones directing these agents.

The ones who don’t will be waiting for someone else to explain the output.