Power BI Developer interview questions and answers

Power BI Desktop is the free Windows application where you build reports: connect to data, shape it in Power Query, create the model and DAX measures, and design the pages. The Power BI Service is the cloud platform at app.powerbi.com where you publish them, share them through workspaces and apps, schedule data refreshes, set up row-level security members and build dashboards by pinning visuals.

So you author in Desktop and distribute in the Service. Mention that sharing in the Service needs the right licences: usually Pro (or Premium Per User) for the people sharing and viewing, unless the content sits in a capacity that allows free viewers. Power BI Report Server is the on-premises option for companies that can't use the cloud.

Drill-down works inside one visual with a hierarchy: a sales chart by year can drill down to quarter, month and day. Drill-through takes the user to a different, detailed page filtered to what they right-clicked: right-click a customer and jump to a Customer Details page. You set it up by adding the field to the drill-through well of the target page, and Power BI adds a back button.

Cross-filtering is the default interaction between visuals on the same page: clicking a bar for South filters or highlights the other visuals. You control it with Edit interactions, choosing filter, highlight or none for each visual. Explaining when to use each one shows you design for the user.

Import loads the data into Power BI's in-memory engine, compressed. It gives the fastest visuals and full DAX and Power Query features, but the data is only as fresh as the last refresh and the model size is limited by your licence. It's the right default for most reports.

DirectQuery leaves the data in the source and sends a query on every interaction. Use it when data must be near real-time or is too large to import, accepting slower visuals, some DAX and Power Query limits, and extra load on the source database. A composite model mixes them: for example, import the dimensions and recent aggregates, and keep a huge detail fact table in DirectQuery. Say that you'd test performance before committing.

Read the refresh history error first; it usually names the problem. Then check the common causes. If the source is on-premises, such as a SQL Server inside the office network, the Service needs an on-premises data gateway: is it installed, online, and is the data source added to it with the same server and database names used in Desktop? Next, the credentials in the semantic model's settings: an expired password or a token for a cloud source is very common.

Also check privacy level settings when combining sources, a column renamed or removed at the source, and refresh timeouts on a large model, which incremental refresh can solve. After fixing it, set up failure notifications so you hear before the users do.

In Desktop, go to Modeling, Manage roles, and create a role with a DAX filter on the dimension. A static role would be Region[Region] = "South", but with many managers that becomes one role each. Dynamic security is better: keep a mapping table of manager email and region, relate it to the Region dimension, and create one role with the filter [Email] = USERPRINCIPALNAME() on that table, so the filter flows to the sales data.

Test it with View as role in Desktop, publish, then add users or groups to the role in the semantic model's Security settings. Remember that RLS restricts viewers; workspace members who can edit the content aren't restricted by it.

A calculated column is computed row by row when the data refreshes and stored in the table, so it uses memory and makes the file bigger. It can be used like any column: on an axis, in a slicer or in a relationship. A measure is computed when a visual asks for it, in the current filter context, and isn't stored.

Use a calculated column when you need a value per row to slice or group by, such as an age band or a Profit column for a filter. Use a measure for aggregations that must respond to filters, like Total Sales = SUM(Sales[Amount]) or a margin percentage. A common rule: prefer measures, and add columns only when you need to slice by the result.

Filter context is the set of filters applied when a measure is evaluated: the slicers, page filters, and the row and column of the visual. In a matrix of sales by region, the cell for South is calculated with the filter Region = South.

Row context means "the current row", and exists when DAX goes through a table row by row: in a calculated column, or inside an iterator like SUMX. In SUMX(Sales, Sales[Qty] * Sales[Price]), the row context lets each row multiply its own quantity and price before the results are summed. Row context doesn't filter anything by itself; CALCULATE turns it into a filter context, which is called context transition.

CALCULATE evaluates an expression in a modified filter context: it adds, replaces or removes filters before calculating. For example, South Sales = CALCULATE([Total Sales], Region[Region] = "South") always shows South's sales, because its filter replaces any existing filter on that column.

For share of total, remove the product filter from the denominator: Sales Share = DIVIDE([Total Sales], CALCULATE([Total Sales], ALL(Product))). In each product's row, the numerator is that product's sales, while the denominator ignores the product filter and gives the total, still respecting other filters like the date slicer. Use DIVIDE rather than the / operator so a zero denominator returns blank instead of an error.

Time intelligence functions need a proper date table: one row per day with no gaps, covering whole years, related to the fact table and marked as a date table. Then: Sales YTD = TOTALYTD([Total Sales], 'Date'[Date], "3/31"). The third argument is the year-end date, so the total restarts every 1 April, as Indian financial years do.

For last year: Sales PY = CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date])), and growth is DIVIDE([Total Sales] - [Sales PY], [Sales PY]). Add fiscal year and fiscal quarter columns to the date table for the axes. A common mistake is using the fact table's own date column, which has gaps and gives wrong results.

As a rule, shape data as early as possible: do cleaning, merging, type changes and fixed calculated columns in Power Query, or even in the source database, and keep DAX for measures that must react to filters. Columns created in Power Query compress better and keep the model simpler.

Query folding is when Power Query translates your steps into a single query in the source's own language, such as SQL, so the database does the filtering and grouping and only the result is sent to Power BI. It makes refreshes much faster, and incremental refresh depends on it. Some steps break folding, after which later steps run in Power BI. Right-click a step and check View Native Query to see whether it still folds.

A fact table records events or transactions with numbers to measure: each row of a Sales table is one sale, with the date, product, store and customer keys, plus quantity and amount. It's long and grows every day. A dimension table describes the things you filter and group by: Product (name, brand, category), Store (city, region), Customer and Date. Dimensions are shorter and wider, with descriptive text.

In Power BI, dimensions sit on the one side of one-to-many relationships and filter the facts. Slicers and axes should use dimension columns, while measures aggregate fact columns. Mention the grain of the fact table, such as one row per product per invoice, because everything else depends on it.

In a star schema, a central fact table connects directly to each dimension table, like the points of a star. Power BI's engine and DAX are designed around this shape. With one flat table, every descriptive column is repeated on every sales row, which makes the model larger and slower, and adding a second fact, such as targets or returns, becomes very hard because they can't share the same filters.

With a star schema, one Date or Product dimension filters several fact tables consistently, the DAX stays simple, time intelligence works with a proper date table, and relationships are clear one-to-many. Snowflaked dimensions, like Product linked to a separate Category table, work too, but are usually flattened into one dimension for simplicity.

Cardinality describes how rows match across a relationship: one-to-many is the normal case (one product, many sales rows); one-to-one is rare; many-to-many appears when neither side has unique keys. Cross-filter direction says which way filters flow. Single means the dimension filters the fact, which is what you want almost always.

Both lets the fact filter the dimension too. It seems convenient, for example to show only products that have sales in a slicer, but it can create ambiguous filter paths, slow the model and give unexpected numbers, especially with several fact tables. Prefer single direction, and when one measure needs it, use CROSSFILTER inside CALCULATE. For many-to-many, a bridge table is often clearer.

Keep targets as their own fact table at their own grain; don't force them into the sales table. Relate both facts to shared dimensions at the level they have in common. For category, create a Category dimension (or a category key) that both Product and Targets can use. For dates, store each target against the first day of its month and relate it to the date table, or relate it on a year-month key.

Then Total Sales and Total Target can sit side by side in a visual by month and category. Below that grain, such as by product or by day, the target measure is misleading, so blank it with ISINSCOPE or ISFILTERED, or allocate it on purpose if the business wants daily targets.

Join sales to products, filter the year with a date range, and group by month and category. In SQL Server: SELECT YEAR(s.order_date) AS sales_year, MONTH(s.order_date) AS sales_month, p.category, SUM(s.amount) AS total_sales FROM sales s JOIN products p ON p.product_id = s.product_id WHERE s.order_date >= '2025-01-01' AND s.order_date < '2026-01-01' GROUP BY YEAR(s.order_date), MONTH(s.order_date), p.category;

The date range rather than YEAR(order_date) = 2025 in the WHERE clause lets the database use an index on the date. Also mention that for an Import model you'd often bring the data at daily grain and let the model aggregate, so users can still drill down.

Both stack the results of two queries with the same number of columns and compatible types. UNION removes duplicate rows from the combined result, which needs an extra sort or hash step. UNION ALL keeps every row and is faster.

For two branches' sales, use UNION ALL: two genuine sales can look identical, such as the same product, amount and date, and UNION would wrongly drop one, understating sales. Add a branch column to each query, like SELECT 'Hyderabad' AS branch, ..., so the report can still tell them apart. Use UNION only when you truly want distinct rows, such as a combined list of unique customer emails.

In Power BI, a blank member appears when fact rows have a key with no match in the dimension, or the matching dimension column is empty. Find the rows with a left join: SELECT s.product_id, COUNT(*) AS rows_count, SUM(s.amount) AS amount FROM sales s LEFT JOIN products p ON p.product_id = s.product_id WHERE p.product_id IS NULL GROUP BY s.product_id;

If it returns rows, the products are missing from the product table, often new items not loaded yet. If not, check for NULL categories in products. The real fix is upstream: load the missing products or add an "Unknown" member. In the view you can label them with COALESCE(p.category, 'Unknown') so the gap is visible, not hidden.

Choose by the question the visual answers. To compare categories, use a bar chart, sorted, horizontal when names are long. For a trend over time, use a line chart. For part of a whole with only two to four parts, a pie or donut can work, but a stacked or simple bar is usually clearer. For a relationship between two numbers, use a scatter chart. For a distribution, use a histogram. For one headline number, use a card, ideally with a comparison such as versus last month or target.

Avoid 3D charts, too many colours and dual axes that mislead. A table or matrix is right when users need exact values.

Start with what they need to know in the first few seconds, and place it where the eye goes first: KPI cards across the top left, such as revenue, margin and orders, each with a comparison to target or last year. Below that, a trend over time, then breakdowns by region or product that explain the movement. Detail belongs on drill-through pages, not on the summary.

Keep it to a handful of visuals per page, use consistent colours (one colour for actual, one for target, red only for problems), align visuals on a grid, and put slicers in one place. Check it on a laptop screen and, if managers use phones, build the mobile layout too.

Stay factual, and present it as a business problem to solve, not a mistake to expose. Check the numbers thoroughly first, including how costs are allocated, because they'll be questioned. If you can, share it with the sales head privately before any larger meeting, so they aren't surprised in front of others.

Structure it as what, so what, now what: what the data shows (margin is negative in two regions since the price cut), why it matters (the loss each quarter), and options (adjust pricing, limit discounts, focus on profitable regions). One clear chart is better than ten. Ending with options gives the stakeholder a way forward, which makes them far more likely to act.

Keep it to a minute and focus on reporting. For example: "I'm a [degree] graduate from [college]. I've been building reports in Power BI for [time], and I'm comfortable with Power Query, star-schema modelling and DAX measures like time intelligence. In my project I built [report, e.g. a sales dashboard for a distributor's data] that showed [one insight or result]. I've also [certification or internship]. I'm looking for a Power BI developer role where I can build reports people use every day."

Have the report ready to show or describe in detail, because interviewers often ask you to walk through it.

Show that you start with decisions, not visuals. A good structure: who will use it, what decisions they make with it, which numbers and definitions they need, how often the data must refresh, and who should see what (security). For example: "I'd ask the sales head what they look at every Monday and what they do about it. Then I'd write down each KPI with its exact definition, confirm the data sources, and show a quick sketch or a first page early for feedback."

Mention agreeing definitions in writing, such as whether revenue includes GST, because that prevents most later arguments.

Use STAR and name real techniques. For example: "Our sales report took over 20 seconds per page (situation), and I was asked to fix it before the quarterly review (task). Performance Analyzer showed that two measures were slow and one page had too many visuals. I rewrote a measure that used FILTER over the whole sales table as a simple column filter in CALCULATE, removed unused high-cardinality columns, replaced a flat table with a star schema and split the page in two (action). Pages loaded in 2 to 3 seconds, and the file size halved (result)."

The point is a method: measure first, fix the biggest cost, then measure again.

Show that you're helpful but organised. Small changes add up and can break the report, so collect them in one place, check each one's value and effort, and agree priorities with the report owner. For example: "I'd thank them, log the request, and group requests into a fortnightly release. Urgent fixes for wrong numbers go first. If a request changes a definition or needs new data, I'd check with the owner first, since it affects everyone using the report."

Mention testing changes in a development workspace before publishing to the live app, which shows real-world discipline.

Give specific habits rather than "I read blogs". For example: "I read the monthly Power BI Desktop update notes and try the features that matter for my work, such as new visuals or modelling options. I practise DAX on sample datasets, follow the official Microsoft Learn paths, and I'm preparing for [certification, e.g. the Power BI Data Analyst exam]. When I learn something new, I try it in a small report first before using it at work."

Mentioning Microsoft Fabric, and how Power BI fits into it, shows you're aware of where the platform is heading.