BI developer interview questions, with worked answers

How to use these questions

Answer with a report you built: who asked for it, what decision it served, how you modelled the data, what went wrong and how many people use it now. Interviewers trust a BI developer who can explain a figure from the dashboard back to the table it came from.

What a BI developer is expected to know

• Tools: Power BIData models, measures, row-level security, refresh and sharing; knowing why a report is slow. depends on the provider, TableauData sources, calculated fields, dashboards and their performance, and publishing for others. depends on the provider, LookerA semantic layer of shared definitions and the dashboards built on it, often next to BigQuery. depends on the provider or QlikData loads, the associative model and apps that let users explore, with sections for access. depends on the provider, and SQLWrite and tune the queries behind reports, and read the warehouse's tables without help. to read and shape the data.
• Models: star schemasStar schemas with clear facts and dimensions, at a stated grain, that many reports can share. with fact and dimension tables, measures and a semantic model shared by many reports.
• Data: the data warehouseKnow the layers and tables reports read from, and ask the engineers for the right changes., ETLHow data reaches the warehouse and when; where a transformation belongs and who maintains it., refreshes and data quality, and ExcelStill where many users live: connect it to the shared model instead of copying data into it. where users still take the figures.
• People and rules: requirements, KPIs, row-level security, versions and governance, and visual designCharts that answer one question each, readable in seconds, honest about scale and gaps. people can read in seconds.

Requirements, KPIs and models

A department asks for a new dashboard. How do you gather the requirements with the stakeholders?

What they check: that you start from decisions, not from a list of charts.

Short answer: "I ask who will use it, what decision they make with it, how often, and what they do today. Then I agree the few figures that matter, their exact definitions, the filters, who may see what, and how fresh the data must be. I sketch the page with them before I build, and agree what done means."

The full answer: People often ask for every figure they can think of; the sketch helps them choose. Check whether an existing report already answers the question. Write the requirement down in a short page both sides sign off, so later changes are visible as changes.

A weak answer: "I build what they ask for and change it later." Follow-up: "Two managers want different things on the same page." Explain how you would decide or split it.

How do you define a KPI so that everyone reads it the same way?

What they check: precise definitions with an owner, written where people see them.

Short answer: "A KPI needs a name, a formula in plain words, the data it comes from, what is in and out, the time basis, the target and an owner who decides on changes. I write that next to the figure in the report and in a shared glossary, so the dashboard and the meeting use one single source of truth."

The full answer: Most disputes come from small differences: gross or net, order date or invoice date, with or without returns. Show the definition on hover or in a short note. When two definitions are both needed, give them two names.

A weak answer: "Revenue is revenue." Follow-up: "Sales and finance show different revenue for March." Explain how you would find the difference.

Design the data model for a sales report. What goes in the star schema's fact and dimension tables?

What they check: dimensional modelling with a clear grain.

Short answer: "A star schema has a fact table at one grain, here one row per invoice line, with the numbers to add up, such as quantity and amount. Around it sit dimension tables with the things to filter and group by: date, customer, product, region, salesperson. Each dimension table joins to the fact table by one key."

The full answer: A star keeps the model simple and fast in every BI tool. Avoid joining facts to facts, and avoid many-to-many relations unless they are understood. A shared date table lets every report compare periods the same way. If history matters, such as a customer's region last year, the dimension must keep it.

A weak answer: "I import all source tables and connect them as they come." Follow-up: "Targets are monthly, sales are daily." Explain how two grains live in one model.

What is a measure, and how do you keep measures correct and reusable?

What they check: calculations in the model, tested, named and shared.

Short answer: "A measure is a calculation that the BI tool works out at the moment of viewing, for whatever filters are set, such as total sales or margin percentage. I define each measure once in the model, in DAX in Power BI or the calculation language of the tool in use, with a clear name and description, and test it against figures from the source."

The full answer: Measures that are copied into each report drift apart. Keep base measures simple and build others from them. Watch totals and ratios, which are where errors hide: an average of averages is not an average. Write the test cases down so a change can be checked.

A weak answer: "Each report has its own calculations." Follow-up: "The total row does not match the sum of the rows." Explain why that can be right or wrong.

ETL, refreshes, performance and security

Where should a transformation happen: in the ETL, in the warehouse, or in the BI tool?

What they check: that you put logic where it can be shared, tested and maintained.

Short answer: "As far upstream as makes sense: cleaning and business rules that many reports need belong in the ETL or the warehouse, often as versioned models in a tool such as dbt. The BI tool does what is specific to one report and the measures that depend on filters."

The full answer: Logic hidden in one report cannot be reused or checked, and every other report copies it slightly differently. Doing everything upstream can make small changes slow, so agree with the data engineers who owns what and how fast they can respond.

A weak answer: "I do everything in the BI tool, it is quicker." Follow-up: "Three reports clean customer names three different ways." Explain where you would move that logic.

How do you set up the refresh of a large data set, including incremental refresh?

What they check: refreshes that are fast, reliable and monitored.

Short answer: "I schedule the refresh after the warehouse load has finished, and for large tables use incremental refresh, which reloads only the recent period and keeps older data. Failures send an alert to the owner, and the report shows when the data was last updated."

The full answer: Incremental refresh needs a reliable date column and a rule for late changes to old data. Avoid refreshing more often than the source changes. For near real-time needs, a direct connection to the source may fit better, at a cost in speed.

A weak answer: "We reload everything every hour." Follow-up: "The refresh failed and nobody noticed for two days." Explain how you would catch it next time.

A report is slow. How do you find and fix the cause of the poor performance?

What they check: a method, starting from measurement, not guesses.

Short answer: "I measure first: which page, which visual, which query takes the time. Common causes are a model that is not a star, too many columns or rows loaded, complex measures, too many visuals on one page, or a slow direct connection. I fix the biggest cause, measure again, and stop when users are happy."

The full answer: Each tool has a way to see query times; use it. Remove columns nobody uses, summarise data the report never shows in detail, and simplify the measures behind slow visuals. Sometimes the fix is in the warehouse: an aggregated table or an index.

A weak answer: "Buy a bigger licence." Follow-up: "The page is fast for you but slow for users abroad." Discuss gateways, regions and connections.

How do you set up row-level security so each person sees only their data?

What they check: access rules in the model, tested, and kept with the user directory.

Short answer: "Row-level security filters the data by who is looking: a regional manager sees only their region. I define roles in the model, map users or groups from the company directory to them, test each role, and avoid separate copies of the report for each group."

The full answer: Base the rules on groups the HR or identity team keeps current, not on hand-kept lists. Remember that exports and subscriptions must respect the same rules. Personal data in reports, such as names and salaries, needs the tightest rules, and in the EU the GDPR applies to them.

A weak answer: "We make one copy of the report per region." Follow-up: "A manager changes region." Explain how their access follows.

Semantic models, dashboards, quality and versions

How do you build a semantic model that supports self-service without chaos?

What they check: shared definitions that let users build their own reports safely.

Short answer: "A semantic model is the shared layer of tables, relations, measures and names that reports are built on. I build one per business area, with business names and descriptions, and let trained users create their own reports on top of it. Self-service then means freedom in the pages, not in the definitions."

The full answer: Without a shared model, self-service creates hundreds of reports with different answers. Offer training and a few templates, watch which reports become popular, and bring the important ones under proper ownership.

A weak answer: "Everyone can connect to the database and build what they like." Follow-up: "A user's report shows a different margin." Explain how you would trace it.

How do you design a dashboard that people can read in a few seconds?

What they check: visual choices made for the reader.

Short answer: "One page answers one question. The most important figures sit top left, with comparison to target or last period. I pick the chart for the comparison: lines for time, bars for categories, tables when people need exact numbers. Colour marks what needs attention, not decoration."

The full answer: Start axes at zero for bars, label units, and avoid pie charts with many slices. Think about colour blindness and phones. Test the page with a real user: ask them what it tells them, and change what they misread.

A weak answer: "I fit as many charts as possible on the page." Follow-up: "The CEO wants everything on one page." Explain how you would agree on what goes first.

How do you check data quality before a report goes out?

What they check: checks that catch errors before users do.

Short answer: "I reconcile key totals with the source system, check for missing days, duplicates and unmatched keys, and compare with the last period for jumps that need an explanation. The checks run with each refresh, and the report shows a warning when one fails."

The full answer: Fix errors at the source where possible and tell the owner. Write down known data issues next to the report, so users do not discover them in a meeting. A short reconciliation with finance each month builds trust quickly.

A weak answer: "Users will tell us if something is wrong." Follow-up: "Yesterday's sales are missing for one country." Explain what you would check first.

How do you manage versions and changes of reports and models?

What they check: controlled change, with history and a way back.

Short answer: "I keep models and reports under version control where the tool allows it, work in a development workspace, test, then publish to production through a fixed process. Changes to shared measures are announced, and each release notes what changed."

The full answer: Many BI tools now save reports in formats that version control can read, which makes reviews and rollback possible. Separate development, test and production. Reports that feed financial statements may need approvals that auditors check.

A weak answer: "I edit the live report directly." Follow-up: "A change broke the board report an hour before the meeting." Explain how you would roll back.

Governance, tool choice and the senior steps

How do you run BI governance: workspaces, certified data sets and ownership?

What they check: order that helps users find trusted reports.

Short answer: "I set up workspaces by area with named owners, mark the shared data sets that have been checked as certified or endorsed, and keep a list of reports with their owner and users. Reports nobody opens are archived. Access follows groups, not individuals."

The full answer: Governance in BI is mostly about trust and finding things: which report is the official one. Keep the rules short and the process quick, or people build around it. Review usage regularly and tidy up.

A weak answer: "Everyone publishes wherever they like." Follow-up: "There are five sales dashboards and nobody knows which is right." Explain how you would settle it.

How would you compare Power BI, Tableau, Looker and Qlik for a company without favouring one?

What they check: a fair comparison on the company's needs and costs.

Short answer: "I write down the needs: data sources, number and kind of users, the cloud and office software already in use, security, self-service, embedding and budget. Then each tool builds two real reports, and we compare speed, ease for users and the full cost of licences and running."

The full answer: Power BI fits naturally where Microsoft tools are used, Looker where data lives in BigQuery and a strong semantic layer is wanted, Tableau and Qlik where exploration across many sources matters; each can do most jobs. Migration from the current tool is a large cost of its own, so count it.

A weak answer: "I would use the tool I know." Follow-up: "Finance already pays for one tool through another contract." Explain how that changes the comparison.

As a lead BI developer or analytics manager, how do you set priorities between departments?

What they check: a fair, visible way to say yes and no to stakeholders.

Short answer: "I keep one visible list of requests, agree a few criteria with management, such as value, effort and risk, and review the list with the department heads regularly. Urgent work has a clear rule. Everyone can see why their request is where it is."

The full answer: At senior BI developer and lead BI developer level, much of the work is reviewing others' models and setting standards; as analytics manager it is the team, the priorities and the budget for tools. Expect a case where finance and sales both need the team for the same month.

A weak answer: "Whoever shouts loudest goes first." Follow-up: "The CEO's assistant asks for a new report today." Explain how it fits the rules.

Your CV for these questions

Each report on your CV invites the questions above: what decision it served, how it was modelled, how fast it was, and who trusted it. Keep each report to one line under the job where you built it, and let the interviewer pick which one to hear about:

Score your CV against the BI developer job you want first: each missing skill the check names is a likely question, and a report story to have ready.