HR & Behavioural Power BI Interview Questions

Situation: regional managers tracked sales in separate Excel files, and stock planning was late. Task: give one daily view. Action: I combined ERP and target data in Power Query, built a star schema with DAX measures for target achievement and stock cover, and published an app with row-level security per region. Result: weekly planning moved from Friday to Monday morning, and two slow-moving products were discontinued earlier.

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.

Situation: a client sent 36 monthly Excel files with merged headers and changing columns two days before a review. Task: build a consolidated sales report. Action: I used the Folder connector with a custom function that promoted the right header row, unpivoted month columns and mapped renamed fields through a lookup table. Result: the report was ready a day early, and future files loaded automatically with no manual work.

I first understand the goal behind the changes, because frequent changes often mean the core question was not clear. I write down agreed requirements and a mock-up, then deliver in small iterations so feedback comes early. In one project weekly 20-minute reviews cut rework a lot, and changes that were large were logged for the next version rather than added mid-sprint.

Situation: a finance report took 40 seconds per page with a 2 GB file built on joined flat tables. Task: improve speed. Action: I split it into a star schema with Date, Account, Cost Centre and fact tables, removed unused columns, turned off auto date/time and replaced bi-directional filters with single direction. Result: model size dropped to 450 MB and pages loaded in under 4 seconds.

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.

Situation: a regional head noticed our margin report did not match finance. Task: find and fix it quickly. Action: I compared numbers at product level, found returns were double-subtracted because a measure used both a net amount column and a returns table. I fixed the measure, added a reconciliation page against finance totals and informed users. Result: numbers matched to the rupee and the reconciliation check became standard.

I learn by building tiny examples. For filter context I made a small model with five products and wrote measures with and without ALL, KEEPFILTERS and ALLSELECTED, checking each result in a table visual. I also read documentation and use DAX Studio to see queries. Explaining it to a teammate afterwards showed me which parts I had not fully understood.

Situation: finance needed month-end inventory balances, which are semi-additive and must not be summed across months. Task: build balances that work at any date level. Action: I wrote a measure using LASTNONBLANK over dates to take the closing balance per period and SUMX across warehouses, then validated against ERP reports for six months. Result: the report replaced a manual Excel process and matched ERP within rounding.

Situation: sales managers stopped using a dashboard I built. Task: find out why. Action: I watched two managers use it and found they needed weekly target gaps first, which were hidden on page three. I moved those to the top, removed four rarely used charts and added drill-through for details. Result: weekly usage in the activity log tripled within a month.

Situation: a sales user reported seeing another region's numbers after a reorganisation. Task: fix the leak fast. Action: I confirmed the security mapping table had stale entries, removed the user from the wrong row, refreshed the model and then automated the mapping from the HR system with a daily refresh. I informed the data owner. Result: access stayed correct after later reorganisations, and quarterly access reviews were added.

I log every request with its business goal, deadline and effort, and agree priorities with my manager instead of choosing alone. I reuse shared semantic models so new reports are faster, and I communicate realistic timelines early. In one quarter this helped me deliver eight reports, with two lower-priority ones moved by a week after discussion with requesters, without escalations.

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.

Situation: a sales report on DirectQuery took over 30 seconds per page and users had stopped opening it. Task: get pages under 5 seconds. Action: I added an Import aggregation table at day and store level, set dimensions to Dual, reduced the main page from 18 to 9 visuals and rewrote two FILTER-heavy measures. Result: page load fell to about 3 seconds and weekly active users doubled.

I acknowledge the goal, explain the limitation in simple terms and offer an alternative that meets most of the need. For example, when a user wanted live updates every second on a DirectQuery report over a slow system, I explained the load it would create and offered a 15-minute refresh plus an alert for threshold breaches. They accepted because the key decision was covered.

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.

Situation: an operations head asked for a 'delivery performance dashboard' with no detail. Task: deliver something useful in a week. Action: I held a 30-minute session to list five questions they wanted answered, sketched a page layout and built a quick prototype in two days with sample data. After feedback I finalised it. Result: the dashboard went live on time and became part of the weekly operations review.

Situation: a client moved its data to a Fabric lakehouse and wanted reports on Direct Lake within three weeks. Task: learn it and deliver. Action: I studied the documentation, built a small proof of concept in two days, checked fallback behaviour and refresh rules, and then migrated the main sales model. Result: reports went live on time with data visible minutes after loading instead of after nightly refreshes.

I would build a dashboard in the Power BI Service and pin the key KPI tiles from each report, so the manager sees all areas on one page and can click through to details. If the KPIs need cross-filtering together, a better option is a summary report built on a shared model or composite model that combines the needed tables, published inside an app.

I would check the refresh history in the Service for errors or whether the refresh actually ran, confirm the gateway is online and has valid credentials, and verify the source itself has the latest data. Then check for cached dashboard tiles, query caching, or an incremental refresh policy that excludes recent days. Also confirm users are viewing the right workspace or app version, which may need republishing.