Questions to Ask in a Business Intelligence Interview
This list is for anyone up for a business intelligence analyst, developer or engineer job who wants better questions for the interviewer than 'which tools do you use?'. It moves through the job itself, the BI stack, who owns the numbers and whether people believe them, how report requests arrive and get ranked, the team and career path, and finally pay and the rounds still to come. Each note explains how a reassuring reply differs from a worrying one, or how to put the answer to use.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The job
Is this role mostly building dashboards, modeling data, or building the pipelines that feed them?
Why ask it
Business intelligence analyst, developer and engineer are used loosely, and one title can mean a chart builder at one company and a pipeline owner at the next. Ask for the rough split over the last month. 'All three, equally' from a team of one or two usually means the job is whatever broke that morning.
What would an ordinary week in this job look like?
Why ask it
A described week is tidier than a lived one, so steer the answer toward the week just gone. Count the days that went to scheduled reports, to new builds, to fixes and reruns, and to sitting with the people who asked. Three days of fixes makes it an upkeep job, and the new development in the posting is a hope.
What should I have built, fixed or retired by the end of my first 90 days?
Why ask it
Hope for something with a reader waiting on it: the sales dashboard moved onto the new model, the month-end pack automated, six versions of one report cut down to one. Whatever they pick is also the yardstick for your first review. 'Getting to know the data' with nothing after it suggests nobody has decided what this hire is for.
What is the main thing about the current reporting that you want this hire to fix?
Why ask it
Slow dashboards, numbers nobody trusts, a backlog of requests, or one person who holds it all in their head: each makes for a different first year. Once you know which it is, bring up the time you dealt with the same thing, in this round or the next. 'Nothing is broken, we need more hands' describes a job of clearing the queue, which is fine if that is the job you want.
Why is the role open, and who has kept the reports running in the meantime?
Why ask it
Whoever has been covering, often a finance analyst or an engineer doing it on the side, knows which refreshes fail and which numbers get questioned, so try to meet them before you decide. If someone left, how long they stayed and what they wrote down tells you how the handover will go. A brand-new BI role means you would be setting the standards as well as meeting them.
Which reports and dashboards would I inherit on the first day?
Why ask it
Inherited work comes with its own logic, and often nobody is left who remembers why a filter is there. Find out how many there are, whether the person who built them is still around, and whether you would be free to rebuild one that has grown tangled.
Where does the BI team's work stop and data engineering's begin?
Why ask it
The line usually runs through the warehouse: engineers land the raw data, and BI shapes it and builds on top. Listen for where a broken load gets fixed, because a BI developer who patches the pipeline 'just this once' tends to end up owning it. With no engineers at all, loading and scheduling are yours, which suits an engineer title and stretches an analyst one.
How much of the work is written in code, such as SQL, DAX or Python, and how much is done in the tool's visual editor?
Why ask it
This tells you which skills the technical round will test and which ones the job would keep sharp. Mostly visual work is a real job, though the skill is harder to carry to another tool later. If you want to move toward engineering, listen for SQL every day and something kept under version control.
Does the job end when the dashboard is published, or am I expected to say what the numbers mean?
Why ask it
Some teams want a builder who delivers to a specification, and others want someone in the meeting explaining why margin fell. Say which of the two you are before the conversation moves on. Where explaining is expected, plan for the business knowledge to take longer to pick up than the tool.
The stack
Which BI tool does the company use, and is that choice settled?
Why ask it
Power BI, Tableau, Looker and Qlik each have their own formula language and habits, so the name is your study list for the next round. If the posting already names the tool, go straight to the second half. A team partway through choosing a replacement will want you fluent in the old tool now and the new one soon, so find out which of the two they are hiring for.
What warehouse or database sits under the reports, and how does the data get into it?
Why ask it
The loading half of the answer says more than the warehouse's brand: a managed connector, scheduled SQL and scripts someone wrote years ago each fail in their own way. Reports pointed straight at a live operational database are a warning, since queries then compete with the business system and history tends to be thin.
Do dashboards read from shared, modeled tables, or does each report carry its own logic?
Why ask it
A shared model or semantic layer means a measure is defined once and every report agrees. Logic buried report by report is how two dashboards come to disagree, and untangling it may be the real job. The usual reply is 'some of each', and the share still running on private queries is the size of the cleanup.
If a dashboard needs a new table or column, would I build it myself or put in a request?
Why ask it
Building it yourself means modeling is part of the role, and the next thing to learn is the house conventions, such as star schemas or a tool like dbt. If it goes to another team, the wait decides how you would design. With a turnaround of days you build what the reader needs, and with a turnaround of months you build what the existing tables allow.
Which source systems feed the reporting, and which one gives the most trouble?
Why ask it
Expect an ERP, a CRM, perhaps a billing or HR system, and nearly always some spreadsheets. The troublesome one is where your cleanup hours would go, so ask what is wrong with it: free-text fields, late loads, or an export somebody emails over by hand.
How often does the data refresh, and who gets the alert when a refresh fails?
Why ask it
Nightly loads are common, so the useful half of the answer is who is awake when one breaks before the morning meeting. If that would be you, find out how often it has happened lately, whether there is a rotation, and how out-of-hours work is treated at this employer. A team that cannot say how often refreshes fail is not watching them.
Are reports and models kept in version control, with a development copy separate from production?
Why ask it
BI teams vary widely here, and plenty still edit the live report. A separate development workspace and a way to roll back mean a mistake costs minutes instead of a morning of apologies. Where there is neither, offering to set them up can make a strong first project, provided the team would welcome it.
How many reports still live in an older tool or in spreadsheets, and is there a plan to move them?
Why ask it
Moving old reports is steady, unglamorous work, and it teaches you the business because each report has to be understood before it can be rebuilt. Two details decide whether you want it: the share of this role it would take, and the date it is supposed to end. With no end date, the old tool tends to stay switched on for the three reports nobody dares retire.
Are any of the dashboards people open every day slow to load, and does anyone know why?
Why ask it
A slow dashboard stops being opened, however correct it is. An interviewer who can put a number of seconds on it has someone measuring. The cause tells you whose problem it is: too much data pulled into the report would be yours to fix, and a warehouse sized for a smaller company is a budget conversation.
Is the team using the AI features in the BI tool or the warehouse, and what is the rule on company data?
Why ask it
Plain-language questions over a dataset only work when the model underneath is clean and its fields are well named, so the follow-up is how often the answers come out right. As for putting company data into outside assistants, every employer draws that line itself, so learn theirs before your first day.
The numbers
Which handful of numbers does the leadership team look at every week?
Why ask it
These are the figures your work would be judged against, and the ones that bring a phone call when they look odd. A short list the interviewer reels off without thinking means the company has agreed what matters. A different list from each person you meet means the agreement is still to come, and BI will be asked to referee.
Who owns the definition of a metric such as revenue or active customer, and where is it written down?
Why ask it
The best answer is a named owner in the business and a definition that lives in the shared model, so changing it changes every report at once. If the definition belongs to whoever built the dashboard, you would be the person defending it in meetings. The story of the most recent change to a definition, and who approved it, shows which of the two this is.
When two dashboards show different figures for the same thing, how does that get settled?
Why ask it
It happens on most teams, usually because a date, a filter or a currency was handled two ways. Listen for a process: someone traces both, one is declared right, the other is fixed or removed. If each team usually keeps its own number, the BI team has no authority to end the argument.
How does the team find out a number is wrong: an automated test, an alert, or a message from someone who opened the report?
Why ask it
Tests on row counts, freshness and totals catch a bad load before the report opens. Without them the tester is whoever reads the dashboard first on Monday, and by then a figure may have gone into a decision. Either way, find out whether a report shows its readers when the data was last loaded.
Is there a data dictionary or catalog, and when was it last updated?
Why ask it
With a current dictionary, a new hire can look up what a column means without interrupting anyone. One last touched two years ago can be worse than none, because people stop checking it and go back to asking whoever has been there longest. If keeping it current falls to BI, count that as part of the workload.
Which dashboard or dataset do people trust least, and what is behind that?
Why ask it
An interviewer who names one straight away knows their own reports. Why it lost trust decides how fixable it is: a source with gaps is an engineering job, while a number that was wrong once in a board meeting takes much longer to live down. Ask whether repairing that trust falls to this role.
Is there a set of official or certified reports, and what does a report have to pass to get that label?
Why ask it
Certification separates the numbers the company stands behind from experiments in someone's workspace. Find out who grants the label and what they check before they do. Where no such line exists, readers cannot tell a tested report from a draft, and both get quoted with equal confidence.
How is access to sensitive data handled in reports, such as pay, customer details or figures not yet announced?
Why ask it
Row-level security, restricted workspaces and an approval step are the usual tools, and each is something a BI developer has to build and keep working. Which data counts as restricted, and who may see it, is set by the law where the company operates and by its own policies, so have the interviewer describe theirs. 'Everyone can see everything' deserves a follow-up.
When a source system changes a field or a process, how much warning does the BI team get?
Why ask it
A renamed column or a new order status can break a report without raising any error. Teams that sit in the change meetings for the ERP or CRM hear early. If the first sign is usually a blank chart, ask whether anyone on the source side knows which reports depend on their fields.
Who checks the dashboards against finance's official figures, and how often?
Why ask it
Finance's closed books are normally the reference, and a sales dashboard that drifts from them soon loses its readers. A regular reconciliation with a named person is the reassuring answer. If nobody does it, expect to be asked in your first month why the two differ.
Requests
Who asks for reports most often, and how does a request reach the team?
Why ask it
A ticket queue or an intake form means requests can be seen, counted and ranked. Requests that arrive as chat messages to whichever developer answered last time tend to reward the loudest team. The department that sends the most is the business you would learn first, so read up on it before the next round.
When the queue is longer than the week, who decides what gets built first?
Why ask it
You hope to hear that a manager or a small group ranks the work against something stated, such as revenue impact or a reporting deadline. The other common answer is 'whoever is most senior', which at least is a rule you can plan around. No rule at all leaves the choosing to you, with a head of sales and a head of finance each expecting to be first.
Do senior leaders open the dashboards themselves, or ask for the number in an email or a slide?
Why ask it
This is the answerable version of 'is the company data-driven?', which nearly always gets a yes. Leaders who open the dashboard notice when it is stale and tend to back the team that keeps it right. Where figures reach them as screenshots in a deck, somebody copies numbers by hand every month, and that somebody may be this role.
In a normal week, how many hours go to one-off data pulls that nobody planned for?
Why ask it
A pull that takes twenty minutes is rarely the problem. The problem is the same pull every month, done by hand because nobody has had a free day to turn it into a report. Get a number of hours if you can, and find out whether a developer here is allowed to say 'that one should be a dashboard'.
Can business users build or change their own reports, and who helps them when they get stuck?
Why ask it
Self-service that works takes clean shared datasets, some training and a place to ask questions. Without those it produces hundreds of private reports with private definitions, and BI gets called in to explain why they disagree. Find out whether training and supporting those users would be part of this job.
How many dashboards are live today, and when was one last retired?
Why ask it
Every dashboard that exists has to survive each change to the model, so the count is your maintenance load. A date for the last retirement means somebody has the authority to switch a report off and has used it. A team that has never retired one is carrying every report it ever built, and you would carry them too.
Does a request usually arrive as a problem to solve or as a finished layout to copy?
Why ask it
'Rebuild this spreadsheet as a dashboard' leaves little room for design and often carries the spreadsheet's flaws across. A problem, such as store managers not seeing stock-outs until Monday, lets you choose the right measure and the right chart. The second kind depends on a developer being allowed an hour with the requester before building.
How often do people export a dashboard to Excel and rework it there?
Why ask it
Exports are feedback: they usually mean the dashboard lacks a cut someone needs, or that the reader wants to check the number for themselves. A team that asks what was missing improves its reports. Where nobody asks, the real reporting happens in spreadsheets you never see.
Would I build reporting for the executive team or the board, and who reviews it before it goes up?
Why ask it
Executive reporting is visible work with fixed dates and little tolerance for a wrong figure. A reviewer before it is sent is protection for the person who built it. If you would be the only check, ask how the numbers were verified the last time the pack went out.
Which dashboard gets opened the most, and what do people do differently because of it?
Why ask it
The first half should be easy for anyone who reads the usage logs. The second half tests whether BI changes anything there: stock reordered earlier, a call list for the sales team, a meeting that now takes ten minutes. If nobody can say, the reports may be glanced at more than they are acted on.
What does the week of month-end close look like for the BI team?
Why ask it
Close is when every number in the pack gets read by someone senior, so it is the week BI is under most pressure. What you most want to know is how much of the pack is still assembled by hand, because manual steps are where late nights and wrong figures both come from. Whether time off in that week is frowned on varies by team, so ask about this one.
Team and growth
How big is the BI team, and who outside it also builds reports?
Why ask it
Two numbers matter: how many people could cover for you, and how many analysts in finance or sales publish their own dashboards. A sole BI developer has freedom and nobody to hand the refresh to during a week off. A large group of outside builders means part of the job is setting standards for work you do not control.
Does BI sit under IT, finance or a data team here, and who would I report to?
Why ask it
Under IT, the work tends to be judged on delivery and uptime. Under finance it leans toward close and the figures finance cares about, and under a data team it sits nearer engineering. Ask whether your manager has built reports themselves, because that decides whether your work gets a technical read.
Does anyone review a dashboard or a data model before it is published?
Why ask it
A second builder checks things a requester cannot: that totals tie back to the source, that the default filters are sensible, that access rules were tested with a restricted login. A requester's sign-off only tells you the layout is what they pictured. With no reviewer, plan to be your own, and check each new report against a figure somebody else produced before it goes out.
A year in, how would you judge whether I had done this job well?
Why ask it
Dashboards shipped is the easy thing to count, and a team judged on it ends up with hundreds nobody opens. Hope for measures a reader would recognize: reports that get used, refreshes that land on time, a monthly request that stopped coming because a report now answers it. When the reply stays general, switch to what the strongest person on the team did last year.
Where have people who held this role gone next?
Why ask it
A real example beats a career ladder on a slide. People leave BI seats in several directions: toward analytics or data engineering, toward managing a BI team, or into the finance or operations department they built reports for. If every example ends with someone leaving the company, that is the path as it stands.
Is there time or budget for training and certifications in the BI tool or the cloud platform?
Why ask it
Vendors change their tools often, and someone who learned one three years ago is behind on it now. A budget is only real if it gets spent, so find out what the team used it for last year and whether study time falls inside working hours. Whether a vendor certificate counts toward promotion is up to each employer, so get this one's answer.
What is on the BI roadmap for the next twelve months?
Why ask it
A roadmap with items on it, such as a new sales model, a finance migration or a self-service rollout, shows somebody is steering, and one of those items would be yours. With no roadmap, the team probably runs on incoming requests alone, and next year's work is whatever arrives.
Is the job remote, hybrid or on site, and where do the people who read the reports sit?
Why ask it
For a BI job, where the readers sit is the bigger half of this question. Watching someone use a dashboard, the filter they never find, the number they copy onto paper, is the best review a report gets, and it is hard to arrange from another city. If you would be remote and the readers are not, ask whether they are used to sharing a screen and showing a developer what confuses them.
Pay and next steps
What is the salary range, and how is the level decided between analyst, developer and engineer?
Why ask it
A recruiter question, and one for the first call. Analyst, developer and engineer often sit in different pay bands for overlapping work, so pin down which band this posting is in and what it would take to be hired at the next one. Rules on disclosing a range are local, and a recruiter who cannot give a figure can often still say whether your number is inside it.
Beyond base salary, what does the package include?
Why ask it
Bonus, retirement contributions, health insurance and paid leave are different at every employer and in every country, so get the details in writing before you compare offers. Two things are particular to this work: whether being the contact for failed overnight refreshes is paid or given back as time, and whether the long days at month-end are. For a bonus, what it paid in recent years says more than the target.
Is there a technical round still to come, such as a SQL test, a dashboard build or a take-home?
Why ask it
BI rounds come in more shapes than SQL on a shared screen. A dashboard build raises its own questions: which tool and version, whether the data is supplied, and whether you present the result or only send the file. For a take-home, get the expected hours in writing, since a dashboard can be polished indefinitely.
Would it be useful if I walked you through a dashboard I have built?
Why ask it
A dashboard on screen settles in two minutes what a resume cannot. Use a personal project or public data, since a former employer's figures are not yours to show. Talk through one decision, such as why a measure was left off or why a table beat a chart, because that reasoning is what the interviewer is hiring.
Having heard my background, which gap would you worry about most: the tool, the modeling, or time spent with business users?
Why ask it
Those three are where doubt about a BI candidate usually sits, and offering them as a menu makes it easier for the interviewer to pick one than a bare 'any concerns?' would. Answer with the closest thing you have built, in a sentence or two, then stop. If they pick the tool, say how long the last new one took you to learn.
Who else would I meet before a decision, and is anyone who uses the reports among them?
Why ask it
A finance or sales lead on the panel is the person who would read your reports, so if one is coming, hold back a Requests question for them. If none is, ask whether you could have fifteen minutes with a regular user of the dashboards before deciding. Leave with a date for the decision.
How to use these in a business intelligence interview
Practical guidance for the conversation itself
Before the interview
Work out which job is being advertised
The duties in the posting give the job away before the title does. 'Build and maintain dashboards' is an analyst or developer seat, 'design data models' leans toward a developer, and 'build pipelines' or 'load the warehouse' is an engineer's job under any title. Decide which of the three you want before you go in. If the posting mixes them, make the first question under The job your opener.
Plan for the non-technical interviewer
Some BI hiring panels include someone who reads the reports and has never opened the tool: a finance controller, a sales operations lead. Questions from The stack are wasted on them. Bring the ones only a reader can answer: what they asked BI for most recently, how long it took, and which number they still keep in a spreadsheet of their own. The recruiter gets Pay and next steps, and whoever sets the technical task gets The stack and The numbers.
Start one layer below the posting
Postings usually name the BI tool and often the warehouse, so asking which tool they use shows you did not read it. Ask the next thing down: 'The posting mentions Power BI. Do the reports share datasets, or does each one carry its own?' The answer is more useful and the question is harder to deflect.
Take fewer than you think
The interviewer's own questions usually fill most of the hour, and three or four of yours is a realistic count for one round. Rank them by what you cannot learn anywhere else: who owns the definitions and how the queue is ranked are not in any posting, while the tool name often is. Carry the leftovers into the next round, where a different interviewer will answer them differently.
In the room
Trace one number from source to screen
Ask the interviewer to pick one figure on a main dashboard and follow it: which system it starts in, how it is loaded, where its definition lives, who checks it and who reads it. That single thread touches most of The stack and The numbers. Pay attention to the step where the account goes vague, since that is usually the step nobody owns.
Trade a number for a number
Questions about how many dashboards are live, how long a refresh takes or how many hours go to one-off pulls can sound like an audit. Give your own real figure first: 'At my last job we had about two hundred reports and retired forty of them. What is it like here?' The interviewer gets something to compare against, and you get a number where you might have got an adjective.
Ask the builder and the reader the same thing
When the rounds include both someone who builds reports and someone who reads them, ask each which report is trusted least. The builder tends to name the one with the worst source, and the reader the one that once embarrassed them in a meeting. If they name the same report, you have found the first thing you would be asked to fix.
Reading the answers
What a report factory sounds like
Requests arrive as layouts to copy, success is counted in dashboards shipped, nothing has ever been retired, and nobody can name a report that changed what a team does. You would get fast in the tool there, and that has value early in a career. Someone who wants to design the model, or to sit with the people who read the numbers, would be restless within a year.
What a one-person data department sounds like
There are no data engineers, loads run on scripts someone wrote years ago, nobody reviews your work, and the failed-refresh alert would come to you. You would learn the whole chain quickly and carry all of it. Ask what help is planned, and check that the level and pay match the breadth of the job.
What a healthy setup sounds like
Metrics have named owners, reports draw on a shared model, something checks the data before readers do, a queue is ranked by someone other than the developer, and a dashboard was retired this year. Few teams have all five. Two or three, with a plain admission about the rest, is a good sign.
Mistakes to avoid
Asking only about tools
It is tempting to spend every turn on the tool, the warehouse and the version, because those answers are short and easy to compare with what you know. A BI job is shaped more by who owns the definitions and who ranks the queue than by the vendor on the login page. Give the stack one or two of your turns.
Treating a mess as a deal-breaker
Nearly every reporting setup has duplicate dashboards and a table people avoid, and the mess is often why the job exists. The useful test is whether the interviewer can point to it, and whether the job comes with the backing and the time to clean it up.
Redesigning their dashboard in the interview
If you are shown a report, or have seen one the company publishes, resist listing what you would change. Ask who reads it and what they use it for first. Advice offered before you know the reader tends to be wrong, and it lands as criticism of someone in the room.
Asking the developer about pay
The person who sets the SQL task often does not know the band, and may have been told to leave money to the recruiter. Salary, level and package belong in the recruiter call, early, so that the technical rounds can be spent on the work.