Power BI Mock Interview: 20 Questions in 50 Minutes

A semantic model, earlier called a dataset, is the published data model behind reports: tables, relationships, measures, hierarchies, security roles and refresh settings. Many reports can connect to one shared semantic model, which keeps business logic and numbers consistent across teams. Certified or promoted endorsements help users find trusted models. Build permission controls who can create new reports on it.

First connect to sources such as Excel, SQL Server or SharePoint and clean the data in Power Query. Then build a data model with relationships, ideally a star schema, and write DAX measures. Next design report visuals and interactions in Desktop. Publish to a workspace in the Power BI Service, set scheduled refresh through a gateway if needed, apply row-level security and share through an app or dashboard.

A calculated column is computed row by row at refresh and stored in the model, so it uses memory and can be used in slicers, filters and relationships, for example Profit = Sales[Amount] - Sales[Cost]. A measure is computed at query time in the current filter context and is not stored, for example Total Profit = SUM(Sales[Profit]). Prefer measures for aggregations and use columns only when you need to slice by the value.

A report is a multi-page, fully interactive document built on one semantic model, with slicers, filters, drill-through and cross-highlighting. A dashboard is a single-page canvas in the Power BI Service made of pinned tiles that can come from several reports and models; it is used for a quick at-a-glance view. Dashboards are created only in the Service, while reports are usually built in Desktop.

Only one active relationship can exist between two tables along a filter path; additional relationships become inactive and appear as dashed lines. For example, Sales may have OrderDate and ShipDate both linked to Date, with OrderDate active. An inactive relationship is used only inside a measure with USERELATIONSHIP, such as CALCULATE([Sales], USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])).

Functions like TOTALYTD and DATESYTD accept a year-end date argument, so for an Indian fiscal year ending 31 March use TOTALYTD([Sales], 'Date'[Date], "31/3"). Add fiscal year, quarter and month columns to the date table for slicing. For complex calendars such as 4-4-5 retail weeks, standard functions do not work, and you write custom logic using fiscal period columns. Newer calendar-based time intelligence also supports custom calendars.

Incremental refresh partitions a large table by date so each refresh reloads only recent data, such as the last 10 days, while keeping older partitions, such as five years of history, unchanged. It uses the RangeStart and RangeEnd datetime parameters to filter the query, which must fold to the source. It cuts refresh time and load on sources, and can add a DirectQuery partition for real-time data.

Key table functions include FILTER, ALL, VALUES, DISTINCT, SUMMARIZE and SUMMARIZECOLUMNS for grouping, ADDCOLUMNS to add calculated columns, TOPN for top rows, CROSSJOIN, UNION, EXCEPT, INTERSECT, GENERATESERIES and TREATAS for virtual relationships. They return tables used inside iterators, CALCULATE filters or calculated tables. ADDCOLUMNS over SUMMARIZE is a common pattern for reliable grouped results.

VAR defines a named value inside an expression and RETURN gives the final result. Variables make measures easier to read, avoid repeating the same calculation, which improves performance, and help debugging because you can return an intermediate variable. A variable is evaluated once in the context where it is defined, so its value does not change if later CALCULATE filters are applied.

Group By in Power Query aggregates rows at refresh time and stores only the summarised table, reducing model size, which is useful when detail is never needed. Summarising in DAX through measures keeps detail in the model and aggregates dynamically for any filter at query time. Use Power Query grouping for fixed summaries such as monthly snapshots, and DAX measures when users need flexible slicing.

Place a chart and a table in the same position. In the Selection pane hide the table and create a bookmark named Chart View with Data unchecked so filters are not saved; then show the table, hide the chart and create Table View. Add two buttons and set each button's action to the matching bookmark. Group the visuals to keep the layout tidy.

Desktop runs on a local machine with its own memory and only you as user, while the Service shares capacity with other workloads and users, so throttling or memory pressure may appear. Also check RLS, which adds filters that do not exist in Desktop tests, gateway latency for DirectQuery, and differences in data volume after a full refresh. Testing with View as role and capacity metrics helps pinpoint it.

I would ask which decisions the page supports and keep only visuals that answer those questions. Then group related KPIs into a top row of cards, keep two or three main charts, and move details to drill-through or tooltip pages. Slicers can move into a collapsible panel using bookmarks. Fewer visuals also make the page load faster.

I would start with three to five headline KPIs versus target and last year at the top, then a trend chart showing the quarter's movement, then a breakdown by region or product showing what drove the change, and finally a short text box or smart narrative stating key takeaways and actions. Each element answers the next natural question, and details live on drill-through pages.

I would check the relationship path in model view: whether Targets is related to the Product or Category dimension at all, whether the relationship is active, and its cross-filter direction. If Targets are at category level, it needs a relationship to a Category table that also filters Product. Also check whether visual interactions were turned off for that slicer and whether the measure uses ALL or REMOVEFILTERS.

The measure is probably ignoring the filter context of the rows, for example using ALL on that column or table, or the row field comes from a table that is not related to the fact table, so its filter cannot reach the data. I would check relationships in model view, the direction of filtering, and any ALL or REMOVEFILTERS in the measure.

I like turning raw data into clear answers that people can act on. In my projects I enjoyed the full flow: cleaning messy Excel and SQL data, designing a proper model, writing DAX and making reports that users actually open every day. Power BI is widely used across Indian companies and global clients, so the role offers strong growth into data analytics, data engineering with Fabric, or BI architecture.

I pair with them on real tasks, review their models and DAX with clear reasons rather than just fixes, and share a short checklist covering star schema, naming, measures over columns and performance checks. I give them ownership of small reports early. One junior I mentored moved from building single-table reports to owning a shared finance model within six months.

I use a simple analogy: the fact table is the list of transactions, and dimensions are the labels we use to slice them, like date, product and region. I show the model diagram with only main tables and explain that slicers work through these links. Then I demonstrate one visual changing when a slicer changes, which makes the idea concrete quickly.

Power BI releases features monthly, so I read the monthly update blog and Fabric release notes, try new features on a test report, and follow community experts and forums. I keep a short list of features relevant to our team, such as visual calculations or TMDL view, and share a five-minute demo in team meetings when something will save us effort.