Power BI Interview Questions & Answers 2026
Asked at MNCs in Delhi NCR

Power BI is Microsoft's business intelligence platform that lets you connect to data sources, transform raw data, build data models, and create interactive visual reports and dashboards. Its three main components work together: Power BI Desktop is the Windows application where you build and design reports — think of it as your workbench. Power BI Service is the cloud platform (app.powerbi.com) where you publish, share, and collaborate on those reports. Power BI Mobile lets users view and interact with reports on their phones and tablets. There's also Power BI Gateway, which acts as a secure bridge between your on-premises data sources (like SQL Server databases in your company's office) and the Power BI cloud service — without it, scheduled refresh from local databases would not work. In MNC interviews in Noida and Gurgaon, this question always comes up first. The answer they are really looking for is whether you understand that Desktop is for building, Service is for sharing, and Gateway is for on-premises connectivity.

This is one of the most frequently asked Power BI questions in India, and many candidates get it wrong because they think both are just "DAX formulas." The difference is fundamental. A calculated column is computed row-by-row when the data is loaded, and the result is stored in the table itself — it takes up memory in your data model. You use it when you need a value that is tied to a specific row, like concatenating first name and last name, or calculating profit per transaction. A measure is computed on the fly, only when a visual renders, and only for the specific filter context that visual is currently operating in. It is not stored anywhere — it is calculated fresh every time a filter changes. You use measures for aggregations like total sales, average order value, or year-to-date revenue. The rule I teach my students: if you need to put the result in a slicer or use it as an axis on a chart, use a calculated column. If you are aggregating numbers that change based on filters, use a measure. Using a calculated column where a measure belongs is one of the most common performance mistakes in Power BI reports.

Import mode loads a snapshot of your data into Power BI's in-memory engine (VertiPaq) when you refresh. Queries run extremely fast because the data is already in memory. The limitation is that data is only as fresh as your last refresh, and large datasets can hit memory limits. DirectQuery sends every visual interaction back to the source database as a live SQL query. Data is always real-time, but performance depends entirely on your database's speed. If your source is slow or the query is complex, your report will feel sluggish. This is ideal when data freshness is critical — like a live operations dashboard tracking orders. Live Connection is specific to Analysis Services, Power BI datasets, or Dataflows. You connect to an already-built semantic model and cannot modify the data model in Desktop — you can only build visuals on top of it. This is common in large enterprises where a central BI team manages the model and report developers just create visuals. In Delhi NCR interviews, they often ask: "Your client needs a dashboard that always shows today's transactions — which mode do you choose and why?" The answer is DirectQuery, and you should explain the trade-off with performance.

A star schema organises a data model into two types of tables: one central fact table containing measurable events (sales transactions, orders, website clicks) surrounded by dimension tables that provide context (date, customer, product, region). The relationship always flows from dimension to fact — one-to-many. This creates a shape that looks like a star when drawn on paper. Power BI's DAX engine (VertiPaq) is specifically optimised for star schemas. When you write a measure like CALCULATE(SUM(Sales[Revenue]), Products[Category] = "Electronics"), the engine can navigate the relationship between Sales and Products in microseconds because the schema is clean and predictable. The alternative — a snowflake schema where dimensions have their own sub-dimensions — adds relationship hops that slow down DAX. And many-to-many relationships or circular references in poorly designed models can cause incorrect filter propagation. I have seen analysts bring in normalised database tables directly into Power BI from SQL Server, which is technically possible but performs poorly. The right approach is to use Power Query to denormalise and reshape the data into a proper star schema before building measures.

Row-level security lets you restrict which rows of data a specific user sees when they view a report, without creating separate reports for each person. A sales manager in Noida should see only Noida region data; the national head sees everything — but they both look at the same report. You implement RLS in Power BI Desktop under the Modelling tab → Manage Roles. You create a role (e.g., "RegionFilter") and write a DAX filter expression on the relevant table — something like [Region] = USERNAME() if your data contains user email addresses, or a lookup to a separate user-region mapping table. After publishing to Power BI Service, you go to the dataset settings and assign users or security groups to each role. When those users open the report, Power BI automatically applies the filter in the background. There are two types: static RLS where the filter values are hardcoded (e.g., [Region] = "North"), and dynamic RLS where the filter uses DAX functions like USERNAME() or USERPRINCIPALNAME() to match the logged-in user's email against a mapping table. Dynamic RLS is far more maintainable for large organisations.

CALCULATE is the most important function in DAX, and understanding it separates analysts who can build basic reports from those who can build genuinely powerful ones. CALCULATE evaluates an expression in a modified filter context. That last part — modified filter context — is the key. Every visual in Power BI operates within a filter context determined by slicers, rows, columns, and report-level filters. CALCULATE lets you override or add to that context temporarily while computing a measure. For example, if you want to show total sales for all regions regardless of whatever region slicer the user has selected: Total Sales All Regions = CALCULATE(SUM(Sales[Revenue]), ALL(Geography[Region])). The ALL() function removes the filter on Region, so the measure ignores the slicer and always returns the national total. Another common use: calculating year-to-date sales even when a specific month is selected. CALCULATE(SUM(Sales[Revenue]), DATESYTD(Calendar[Date])). The DATESYTD function modifies the date filter context to include all dates from January 1st up to the currently selected date. CALCULATE is the engine behind almost every advanced DAX measure. In interviews at companies like Deloitte and EY in Gurgaon, they often give you a scenario and ask you to write the CALCULATE expression.

SUM is a simple aggregation — it adds up all the values in a column. SUMX is an iterator that goes through a table row by row, evaluates an expression for each row, and then sums the results. The difference matters enormously when you need to calculate something that does not exist as a column. Imagine you have a Sales table with Quantity and Unit Price columns but no Revenue column. SUM(Sales[Revenue]) would fail because Revenue does not exist. But SUMX(Sales, Sales[Quantity] * Sales[UnitPrice]) works perfectly — it multiplies Quantity by Unit Price for each row, then sums all those results. The key thing to understand: SUMX always takes two arguments — the table it iterates over, and the expression to evaluate per row. You can also nest FILTER inside SUMX to iterate over a filtered subset: SUMX(FILTER(Sales, Sales[Region] = "North"), Sales[Quantity] * Sales[UnitPrice]). Performance-wise, SUMX is slower than SUM on large tables because of the row-by-row iteration. If you can pre-calculate a column in Power Query and then use SUM, that is usually faster. But when the calculation requires combining values from the same row, SUMX is the right tool.

RELATED and RELATEDTABLE both navigate relationships between tables, but in opposite directions. RELATED moves from the many side to the one side of a relationship — from a fact table to a dimension table. If your Sales fact table has a ProductID column and you want to bring in the product category from the Products dimension table, you write in a calculated column: Category = RELATED(Products[Category]). This works because Sales[ProductID] has a many-to-one relationship with Products[ProductID]. RELATEDTABLE goes the other direction — from the one side to the many side. It returns an entire table of related rows. If you are in the Products table and want to count how many sales each product has: SalesCount = COUNTROWS(RELATEDTABLE(Sales)). This returns all Sales rows related to each product row. In practice, I see RELATED used most often in calculated columns to bring dimension attributes into fact tables before aggregation. RELATEDTABLE is common in measures when you need to aggregate over a related table — though CALCULATE with filters often achieves the same result more flexibly.

Year-over-year growth is one of the most requested business metrics and one of the most common advanced DAX questions in interviews. Here is how I build it step by step. First, you need a properly marked Date table in your model with continuous dates and a relationship to your fact table. Then: Current Year Sales = SUM(Sales[Revenue]) Previous Year Sales = CALCULATE([Current Year Sales], SAMEPERIODLASTYEAR(Calendar[Date])) YoY Growth % = DIVIDE([Current Year Sales] - [Previous Year Sales], [Previous Year Sales], 0) SAMEPERIODLASTYEAR shifts the date context back exactly one year. DIVIDE is used instead of the division operator because it handles division by zero gracefully — the third argument (0) is what returns when the denominator is zero. One important nuance: SAMEPERIODLASTYEAR requires a marked Date table. If your Date column is not in a marked Date table, you can use DATEADD instead: CALCULATE([Current Year Sales], DATEADD(Calendar[Date], -1, YEAR)). In interviews, they sometimes ask you to handle the case where partial year data exists — for example, calculating YoY for January to July only, so you are not comparing a full previous year against a partial current year. That requires adding DATESYTD to the previous year calculation.

Context transition is the process by which CALCULATE converts a row context into an equivalent filter context. This is an advanced concept that comes up in senior interviews and separates intermediate from advanced DAX developers. In a calculated column, DAX operates in a row context — it knows which specific row it is on. But measures operate in a filter context — they know which filters are active, not which row they are on. When you call CALCULATE inside a calculated column, it converts the current row context into a filter context by adding a filter for every column value in that row. A practical example: imagine a Products table with a calculated column that calls a measure. Without CALCULATE, the measure evaluates in whatever external filter context exists. With CALCULATE, the row context (the specific product) becomes a filter, so the measure evaluates only for that product's data. This is why iterators like SUMX can interact strangely with measures — each row iteration creates a row context, and if that measure internally uses CALCULATE, a context transition happens on each iteration. In most day-to-day Power BI work you will not think about context transition explicitly. But when your measures return unexpected results — especially inside calculated columns or iterators — context transition is usually the culprit. Understanding it fully requires practice with complex data models.

Power Query is the data transformation layer in Power BI — it is where raw, messy data gets cleaned, shaped, and prepared before it reaches the data model. Think of it as the ETL (Extract, Transform, Load) engine built into Power BI Desktop. You connect to a source (SQL database, Excel file, SharePoint, web API, CSV), and Power Query opens the data in a query editor where you apply transformation steps. Each step is recorded and can be modified or deleted — and Power Query remembers these steps so every time you refresh, the same transformations are applied automatically to fresh data. Common transformations include: removing duplicate rows, splitting a column by delimiter, filtering out nulls, merging two tables (equivalent to SQL JOINs), unpivoting wide tables into tall format, changing data types, and replacing values. All these steps are recorded as M language code behind the scenes, though most analysts do everything through the graphical interface and never write M directly. However, in senior interviews, they sometimes ask you to write or read M code for custom transformations. Power Query runs before the data loads into the in-memory model. This means heavy transformations in Power Query do not slow down your DAX — they only add time to the refresh. DAX runs after the model is loaded, so keeping the model clean and efficient matters for report interactivity.

Null handling in Power Query depends on what the null actually represents in your data, and this is something I emphasise heavily when training analysts at EVIKA Academy. The most direct approach: select the column, go to Transform → Replace Values, and replace null with whatever makes business sense — zero for a sales amount, "Unknown" for a category, or the average of the column for a measurement. For numeric columns you can use Fill Down or Fill Up if the nulls represent continuation of the previous value — common in exported spreadsheets where a category label spans multiple rows but only appears in the first row. You can also filter out rows with nulls by clicking the column dropdown filter and unchecking null. But this permanently removes those rows, so only do this when a null means the record is genuinely invalid or irrelevant. A more conditional approach uses a custom column with an if-then-else expression: if [Revenue] = null then 0 else [Revenue]. This gives you full control over the replacement logic. In interviews, the question behind this question is: do you understand that blindly replacing all nulls with zero can corrupt your analysis? A null revenue on a cancelled order should stay null or be excluded, not turned into zero revenue that inflates totals.

Merge and Append are both ways to combine tables, but they work in fundamentally different directions. Merge is Power Query's equivalent of a SQL JOIN. You combine two tables horizontally by matching rows based on a common key column. For example, merging a Sales table with a Customer table on CustomerID brings customer name, city, and segment into the Sales table. Power Query supports Left Outer, Right Outer, Inner, Full Outer, Left Anti, and Right Anti joins — the same joins you know from SQL. Append is the equivalent of SQL UNION ALL. You stack two tables vertically, adding the rows of one table below the rows of another. Both tables must have the same or similar column structure. You use Append when you have the same data structure split across multiple sources — January data in one file, February in another, and you want to combine them into one continuous table. In practice: use Merge when you need to add columns from another table. Use Append when you need to add rows from another table. A common mistake is using Merge when Append is needed — for instance trying to merge monthly sales files together instead of appending them. The result would be a confusing wide table instead of a clean tall table.

Performance troubleshooting is a practical skill that MNCs ask about because slow dashboards are a real operational problem. Here is the systematic approach I use. First, use Performance Analyzer (View → Performance Analyzer in Desktop) to record which specific visuals are slow and whether the slowness is in DAX query time, visual rendering, or other overhead. This tells you exactly where to focus. If DAX query time is the culprit: review your measures for inefficient patterns. Common offenders are using FILTER with many columns instead of CALCULATE with direct filters, iterating over large tables with SUMX where SUM would work, or calling measures inside other measures in long chains. Use DAX Studio (free external tool) to run and analyse queries with execution plans. If the model is the issue: check whether you have unnecessary columns or tables. Every column you import takes memory — columns you do not use in visuals or measures should be removed in Power Query before loading. Check your relationships — bidirectional cross-filtering sounds helpful but can cause filter context explosions that dramatically slow calculations. If it is a DirectQuery model: the database query is the bottleneck. Look at query folding — Power Query should be sending the entire transformation to the database as SQL, not pulling raw data and transforming locally. Indexes on the source database on join and filter columns also dramatically improve DirectQuery performance. Finally, aggregation tables — pre-aggregated summary tables that Power BI serves for high-level visuals while only hitting the detail table for drill-downs — can make a slow 100-million-row model feel instant.

This scenario question tests whether you can think through the full BI development lifecycle, not just click buttons in Power BI Desktop. I start with a requirements conversation: what decisions does this dashboard support? What metrics matter — is it daily revenue, margin, or store-level performance? Who are the users — store managers who need their own view, or a CEO who needs the national picture? What data sources exist and how fresh does the data need to be? With requirements clear, data preparation comes next. I connect Power BI to the source — typically a SQL database for transactions, an Excel file for store metadata, and possibly an API for targets or benchmarks. In Power Query, I clean nulls, standardise date formats, remove test transactions, and build a clean star schema: a Sales fact table, and dimension tables for Date, Store, Product, and Customer. Then I build the Date table — either using CALENDARAUTO() in DAX or generating it in Power Query — and mark it as the Date Table in the model. Relationships flow from dimensions to facts. Key measures I always build first: Total Revenue, Total Units Sold, Average Order Value, YoY Growth %, and Gross Margin %. Then I build the visuals: a KPI card row at the top for the headline numbers, a trend line chart showing daily or weekly revenue, a map visual for geographic performance, a bar chart for product category breakdown, and a table for store-level details with conditional formatting. RLS goes in if store managers should only see their own store. Finally I publish to Power BI Service, set up scheduled refresh, and create a workspace with appropriate access levels for different user groups.

In Power BI Service, reports and dashboards are different things that serve different purposes, and mixing them up in an interview suggests you have only used Desktop, not the full platform. A report can have multiple pages, each page containing multiple visuals. Reports are built in Power BI Desktop from a specific dataset. They support full interactivity — cross-filtering, drill-through, tooltips, slicers. Reports are the main place where detailed exploration happens. Each report is connected to exactly one dataset. A dashboard in Power BI Service is a single canvas of tiles pinned from one or more reports — or even from multiple datasets. You build dashboards in the Service, not in Desktop, by pinning individual visuals from your reports. Dashboards do not have pages; they are designed for quick at-a-glance monitoring, not deep exploration. The key difference that always matters in interviews: dashboards can pull tiles from multiple reports and datasets. If your CEO wants to see revenue from the sales report, headcount from the HR report, and ticket volume from the support report — all on one screen — a dashboard is the right answer because you can pin tiles from all three reports onto one dashboard canvas. A single report could not aggregate across those different datasets.

1

2

3

4

5