How to get hired as a business intelligence developer in 2026-27

What a business intelligence developer actually owns, and the five roles it gets confused with

A BI developer's output is a reporting system that other people use without you in the room. Concretely it is three layers. At the bottom, the objects that feed it: SQL views and stored procedures, a dimensional warehouse, or lakehouse tables. In the middle, the semantic model: a Power BI semantic model, a Tableau published data source, a LookML project, an SSAS tabular model, a Qlik data model. At the top, the reports and dashboards that sit on that model. The middle layer is the job. Anyone can build the chart. Very few people can build a model that still returns the right number when a finance manager slices it by region, by product line, by a custom date range and against last year at the same time.

One naming note that costs people keyword matches: Microsoft renamed Power BI datasets to semantic models, and plenty of live postings still say dataset. Put both words on your resume. The same applies to workspace and app, and to dataflow and Dataflow Gen2.

The second half of the job is the part postings rarely describe and interviews always probe: operations. Refresh schedules and the on-premises data gateway. Incremental refresh partition policies. Deployment from development to test to production, and whether that goes through source control. Workspace and folder structure. Row-level security roles mapped to Entra ID or Active Directory groups. Capacity sizing and licence allocation, including watching capacity units and dealing with throttling when somebody schedules forty refreshes at 6am. Endorsing and certifying models so people stop building their own. And the unglamorous work of finding the reports nobody has opened in a year and switching them off. A candidate who cannot talk about a refresh that failed at 3am, and what they changed so it did not fail again, has not done this job.

Five roles get confused with it, and the confusion costs people interviews in both directions. A data analyst's output is an answer and a recommendation; a BI developer's output is the thing the analyst and the business both query. An analytics engineer owns the layer underneath you: warehouse transformation, marts, tests, documentation, usually in dbt and usually merged through pull requests. A data engineer gets the data to land at all: connectors, change data capture, orchestration, platform reliability. A data warehouse or ETL developer owns the warehouse build and the loads, commonly in SSIS or Azure Data Factory, and may hand the semantic layer to somebody else entirely. A report writer or BI analyst builds reports against a model somebody else owns and maintains. In small companies one person is all six. In large companies the boundaries are real and they determine your band.

The practical test for any posting is a single question: do you decide the grain and the relationships, or do you consume them? A posting that says 'develop and maintain the enterprise semantic model' is a BI developer job. A posting that says 'create reports and visualisations as requested by business users' is a report writer job with a BI developer title on it. Both are legitimate jobs and the second is a reasonable entry point, but they pay differently, they test differently, and a resume aimed at one will miss the other.

• BI developer: owns the semantic model, the reports on it, and the operations around it. Measured on whether the numbers are trusted and whether the thing refreshes.
• Analytics engineer: owns the transformation layer below the model. Measured on whether the tables can be trusted. In Microsoft-stack shops the same person often does both jobs under a BI developer title.
• Data engineer: owns ingestion and platform. Measured on freshness and uptime. Mostly Python and infrastructure, SQL as support.
• Data analyst: owns the answer and the argument. Your most important internal customer, and often the person who vetoes you in the panel round.
• Data warehouse or ETL developer: owns the warehouse build and the loads, commonly SSIS or Azure Data Factory, and may never touch the semantic layer.
• Report writer or BI analyst: builds against an existing model. The tell in a posting is the absence of any verb about modelling, relationships, performance or security.

The four BI stacks, and why one resume for all of them gets no replies

The title business intelligence developer covers four technology worlds that share almost nothing day to day. Applying to all of them with one resume is one of the most common reasons a qualified person gets no response, because an agency recruiter and a non-tech ATS are both matching literal tool strings, and because the interview in each world tests a different skill.

The Microsoft world dominates this exact title. Run the search yourself on any major board and count: most of what comes back is Power BI Desktop and the Power BI Service, DAX, Power Query and M, SQL Server and T-SQL, SSAS tabular models, SSRS and Power BI paginated reports built in Report Builder, SSIS or Azure Data Factory or Synapse, and increasingly Microsoft Fabric: OneLake, lakehouses, warehouses, Direct Lake semantic models, Dataflows Gen2, deployment pipelines and F-SKU capacity. The employers are healthcare systems, insurers, manufacturers, banks and credit unions, utilities, logistics firms, state and county government, universities, and professional services. These organisations move slowly, run large legacy estates, and have budget for multi-year modernisation. That is exactly why the work is there.

The Tableau world is concentrated in companies that standardised on Tableau in the 2010s, plus consumer tech, media, retail and merchandising analytics, and parts of public health. The stack is Tableau Desktop, Tableau Server or Tableau Cloud, published data sources, hyper extracts, level of detail expressions, table calculations, Tableau Prep, Tableau Bridge and Tableau Pulse. The title is usually Tableau Developer or Tableau Analytics Developer rather than BI developer. A pattern worth knowing when you plan a career: a visible share of current Tableau-stack work is consolidation work, moving an estate onto Power BI for licence cost reasons, which makes Tableau experience plus Power BI experience more sellable right now than either alone.

The Looker world is smaller in volume and looks like analytics engineering, because LookML is code: views, explores, models, derived tables and persistent derived tables, datagroups and caching policies, access filters and user attributes, and code review on pull requests. It sits mostly on BigQuery, sometimes Snowflake, in Google Cloud shops and in tech companies. These roles are usually placed on engineering-adjacent ladders rather than IT ladders, which is the thing that actually moves the band. If you can write LookML and review somebody else's, you are in a thinner candidate pool than any Power BI developer.

Everything else is a long tail that is easy to dismiss and should not be. Qlik Sense (load script, set analysis, the associative model) persists in manufacturing and in European-headquartered companies. MicroStrategy, Cognos, SAP BusinessObjects and SAP Analytics Cloud, and Oracle Analytics run inside large enterprises with estates older than most analytics engineers. Domo sits in mid-market. Sigma, ThoughtSpot and Omni are the newer end and show up more at tech companies. One specific warning: the SAP reporting world (BW, BEx, SAC, often alongside an S/4HANA programme) is a career of its own with its own labour market, and drifting into it by accident is a decision, not a detour.

• Read the posting for the warehouse as well as the BI tool. Power BI on SQL Server with SSIS is a different job from Power BI on Databricks with dbt, and they pay differently.
• If SSRS, SSIS or SSAS multidimensional appear, there is a legacy estate and usually a modernisation mandate attached. That is good news for a candidate who can read old work, not a warning sign.
• If Fabric, OneLake or Direct Lake appear, a migration is in flight. Ask what phase it is in on the first call: 'we are evaluating' and 'we are 40 reports into a 600 report migration' are different jobs.
• If the posting lists a capacity SKU, a gateway, deployment pipelines or workspace governance, the role includes platform ownership and the band should reflect it.
• Keep three resumes, not one: Microsoft, Tableau, and a third for whichever long-tail stack you genuinely know. Spell tool names in both short and long form, because non-tech ATS matching is literal.

Is the business intelligence developer role shrinking? The honest answer

Three things are happening at once, and most commentary picks one of them and calls it the whole story.

First, the ticket-desk tier is genuinely shrinking. The version of this job where a business user raises a request, you add a column, change a filter or build a bar chart, and close the ticket, is being absorbed. That tier was already under pressure from self-service tooling for a decade before any of the current AI features existed, and it is the easiest data work to offshore, which has also been happening for a decade. Natural-language querying over a semantic model accelerated the squeeze rather than starting it. If your entire body of evidence is screenshots of dashboards you were asked to build, you are showing the part of the job that got cheap.

Second, the title is migrating. Work that would have been posted as BI developer five years ago now appears as analytics engineer, BI engineer, analytics developer, reporting engineer, data visualization engineer, Power BI developer, data analyst with reporting in the requirements, and in Microsoft shops, Fabric analytics engineer or Fabric developer. Searching only the exact string 'business intelligence developer' hides a large number of jobs you are qualified for. Set alerts on at least seven title variants plus the tool names, and read requirements rather than titles.

Third, and this is the part the pessimistic version misses: the modelling, performance, governance and migration tier is not shrinking. The funded programmes right now are SSRS and SSAS estates being modernised, Fabric adoption, Tableau estates consolidated for licence cost, Qlik and Cognos and BusinessObjects estates being retired, and semantic layers being rebuilt specifically so a conversational feature returns correct answers. Every one of those needs somebody who can read an old model, work out what the business rules buried in it actually are, rebuild them, prove the new numbers match the old ones, and switch the old thing off without a revolt. That is a hard, unglamorous, well-paid skill and there is no shortage of demand for it.

There is also a structural fact about this role worth more than any market forecast: it is one of the most industry-diversified titles in data. Hospital systems, insurers, utilities, manufacturers, universities, state agencies, county governments, school districts, distributors and logistics firms all employ BI developers directly, and their hiring does not move with the tech sector. That diversification is a stability argument. It is simultaneously a pay ceiling argument, because those employers pay on IT bands rather than software engineering bands. Both are true and you should choose deliberately.

So the accurate sentence to carry into an interview is this: report production is being commoditised, model ownership is not, and the people getting hired are the ones who can show the model. Saying that calmly, with an example, beats both 'BI is dying' and 'nothing has changed'.

• Shrinking: ticket-driven chart building, manual report refreshes, one-off extracts, and reports whose only purpose is to show a number somebody can now ask for in plain language.
• Growing or steady: semantic model design, DAX and model performance tuning, row-level security and governance, capacity and cost management, and migration and decommissioning programmes.
• Title variants to search alongside the literal one: Power BI Developer, Tableau Developer, BI Engineer, Analytics Engineer, Analytics Developer, Reporting Engineer, Data Visualization Engineer, Fabric Analytics Engineer, Data Warehouse Developer.
• Industries that hire this title steadily regardless of the tech cycle: healthcare delivery and payers, insurance, utilities, manufacturing, higher education, state and local government, logistics, and financial services operations.
• The career move that follows from all of this: stop collecting report counts and start collecting model, performance and migration evidence.

How hiring for this role actually works, and where the jobs are really posted

There are four distinct hiring paths for this title and they behave so differently that preparing for the wrong one wastes weeks.

Path one, staffing agency into a contract or contract-to-hire requisition. This route is far more common for BI developer than it is in software engineering hiring, and it looks nothing like a tech loop. Your first call is with an agency recruiter who is matching keywords from a requisition that arrived through a vendor management system such as Fieldglass or Beeline, and who usually cannot answer a technical question. They will ask for a right-to-represent before submitting you, which means only that agency can submit you to that client, so do not sign one casually and never let two agencies submit you to the same client. Ask three things on that first call: is it W2, corp-to-corp or 1099; what is the bill rate and therefore the margin; and is it a genuine contract-to-hire with a conversion clause or a rolling contract. Timelines here are fast, sometimes days from submission to interview.

Path two, internal IT at a non-tech employer. The hiring manager is a BI manager, reporting manager or data warehouse manager inside IT, and the loop is a recruiter or HR phone screen, a technical interview with one or two BI developers, a panel including the business stakeholders you would serve, and an HR close. Three to six weeks. There is very often a take-home or a live build, and at larger firms sometimes a timed proctored SQL test. The business panel has a real veto here and is frequently underprepared for by candidates who treat it as a formality.

Path three, public sector and higher education. This is formal, scored and slow. A panel asks every candidate the same fixed questions and scores each answer against a rubric derived from the posting's listed duties, which has a direct practical consequence: answer in the vocabulary of the posting, and explicitly cover each listed duty you have done, because the scorer is ticking boxes rather than forming an impression. There is often a written or practical assessment, pay sits on a published grade table with little negotiation room, and two to four months from application to offer is normal. Hiring freezes are a real risk, so ask whether the position is funded.

Path four, tech companies, Microsoft and Salesforce partner consultancies, and large system integrators. These run something closer to a standard data loop: a SQL screen, a modelling case, a tool round and a stakeholder round. Consultancies hire in volume and will also assess whether you can sit in front of a client, scope work, and be billable from week two. If you want to compress experience fast, a partner consultancy on migration work is the highest-density learning environment in this field, at the cost of travel and utilisation targets.

On where the jobs actually appear: a large share of them never reach a tech-focused job board. Employer career portals (Workday, iCIMS, Taleo, SuccessFactors) are the primary channel for hospital systems, universities and manufacturers. USAJOBS covers US federal roles, and state and county governments post through NEOGOV-style portals. Dice is still genuinely used for this title in a way it is not for software engineering. Agency boards carry the contract market. LinkedIn carries everything but buries the non-tech employers. Set alerts on the employers you want, not only on the titles.

Finally, the route most people in this job actually took. The single most common entry is internal: you work in finance, operations, supply chain, revenue cycle, clinical analytics, student records or claims; you are the person who builds the spreadsheet everyone relies on; you build a Power BI report because it is faster; you pass PL-300; and you move into the BI team with domain knowledge an external hire would need a year to acquire. If you are already inside an organisation that has a BI team, that is by a wide margin your shortest path, and the domain knowledge is an asset to name loudly rather than apologise for.

• On an agency call, ask immediately: W2 or corp-to-corp, bill rate and margin, contract length, extension history, onsite expectation, and whether a right-to-represent is required before submission.
• In a public sector interview, structure each answer as situation, what you did, what the result was, and explicitly name the posting's duty it maps to. The panel is scoring against a sheet.
• In a business panel, expect at least one question that is really about temperament: a request you had to push back on, a number you had to defend, or a report you had to retire.
• Prepare a screen-share demo you can open in under a minute, and open the model view first, not the dashboard. Interviewers who know the job look at the relationships before they look at the colours.
• Never let two agencies submit you to the same client. It gets both submissions binned and it is the most common self-inflicted wound in the contract market.

Pay, contract versus permanent, and what actually moves the number

Start with what can be verified. There is no dedicated US Bureau of Labor Statistics occupation code for business intelligence developer. The nearest SOC codes each capture part of the population and none captures it cleanly: 15-1243 Database Architects, 15-2051 Data Scientists, 15-1211 Computer Systems Analysts, 15-1299 Computer Occupations All Other. That matters practically, because national average figures published for this job title by salary aggregators are modelled estimates from self-reported and scraped data rather than survey results, and quoting one in a negotiation is weak ground. Use sources you can point at instead: salary ranges published in live postings under state pay-transparency laws (Colorado, California, New York, Washington and Illinois have them, several more states have passed their own, so check your own state's current rule); published grade and step tables for public sector and university roles, which are often downloadable PDFs; and for contracts, the hourly rate on comparable requisitions in the same metro. If you want a government-collected anchor rather than a scraped one, look up the OES figures for 15-1243 in your metro and treat them as a reference point for the warehouse-adjacent end of this work.

Understand the contract market specifically, because this title is contractor-heavy and the economics differ. The client pays a bill rate; the agency pays you a pay rate; the difference is the margin, and it is routinely a meaningful slice. On a W2 contract you get the hourly rate and usually minimal benefits, with the agency carrying employer payroll taxes. On corp-to-corp you invoice through your own entity, you carry everything including both halves of self-employment tax and any insurance, and the rate should be visibly higher to compensate. A corp-to-corp rate and a W2 rate are not comparable numbers, and treating them as comparable is how people end up worse off on a higher headline figure.

Now the levers, in rough order of how much they move the number.

Ladder and industry. The same semantic model work pays differently on an IT ladder at a regional hospital than on a data platform ladder at a software company, and that gap is larger than any skill gap you can close in a year. It is decided when you pick the employer, not when you negotiate.

Scope. Owning the model, the capacity and the governance pays more than owning reports on somebody else's model. Make the distinction explicit in your evidence, because recruiters cannot infer it.

Depth rather than tool. There are many people who can build a Power BI report and few who can take a model that times out, find the cause in VertiPaq Analyzer, fix it, and explain why the fix worked. Strong tabular modelling plus performance tuning, and LookML, are the two scarce profiles.

Migration experience. Migrations are time-boxed, urgent, visible to executives and separately budgeted, which is exactly the combination that pays. If you have migrated an estate and can describe how you proved the new numbers matched the old ones, lead with it.

Domain depth. This is a bigger lever in BI than in most data roles, because the model has to encode business rules. Healthcare revenue cycle, insurance claims and reserving, manufacturing OEE and yield, retail merchandising and allocation, higher education enrolment and census reporting: in each of these, a developer who already knows the rules is worth materially more than one who has to be told them, and the employer knows it.

Clearance. In US federal and defence contracting an active clearance gates the requisition before any skill is considered, and cleared rates sit above uncleared ones for the same work.

Geography and onsite expectation. This role is more often hybrid or onsite than analytics engineering, because the stakeholders are onsite and the data is sometimes on premises. Fully remote BI developer roles exist and draw far more applicants per opening.

• Verifiable pay sources to use: state pay-transparency ranges in live postings, published public sector and university grade tables, union and civil service schedules where they apply, BLS OES figures for 15-1243 in your metro, and comparable contract bill rates locally.
• Ask the estate questions on the first call; they tell you the real scope: how many reports, how many semantic models, what capacity SKU, how many monthly report users, who owns the warehouse.
• Certifications (PL-300, DP-600, Tableau Certified Data Analyst) pass filters. They do not move bands. Budget a few weekends for one, not a few months.
• If a role is posted as contract-to-hire, ask what share of their contractors converted in the last year. A vague answer is an answer.
• When negotiating permanent pay, anchor on scope rather than title: 'I would be owning the semantic model, capacity and row-level security for 400 users' is a different conversation from 'I am a BI developer'.

The portfolio: ship a model, not a dashboard

A portfolio matters more in this role than in most data roles, because there is no credential and because the artefact is directly inspectable. Most BI portfolios fail for one specific and fixable reason: they are screenshots of visuals, and the visual is the part that is now cheap to produce. The reviewer wants to see the model.

Start with distribution, because a brilliant file nobody can open is worth nothing. A .pbix is awkward for a reviewer: it needs Power BI Desktop and a Windows machine. Solve it by publishing three things. One, a public link to the working report (Power BI publish to web if and only if the data is genuinely public, Tableau Public, a Looker Studio report, or a three minute screen recording walking through it). Two, a public repository containing the SQL or dbt that builds the star schema, the date dimension script, and the measure definitions as text. If you save the Power BI file in the PBIP project format, the semantic model is written out as TMDL text files that a reviewer can read in the browser, which is the single easiest upgrade available to a BI portfolio right now. Three, a one page written model document. That document is what separates a portfolio from a screenshot.

Choose the dataset deliberately. Avoid Superstore, AdventureWorks, Iris and the Contoso sample: every reviewer has seen them hundreds of times, and they arrive pre-modelled, which hides the only skill you are trying to demonstrate. Pick something with a genuine transactional grain and messy edges you have to decide about: NYC taxi trip records, the Olist Brazilian e-commerce dataset, UK STATS19 road safety data, CMS Medicare provider utilisation files, UK Land Registry price paid data, a city's open procurement spend, a transit agency's on-time performance feed. These force real decisions, and real decisions are what you will be asked about.

Then build the things the interview will test.

Build a star schema, not a flat table. One or two fact tables, a date dimension you generated yourself (with fiscal periods, not just calendar), three to six dimensions, at least one slowly changing dimension type 2 if the data justifies it, and at least one many-to-many relationship resolved with a bridge table. Write down the grain of each fact table in one sentence each.

Write ten to twenty measures that cover the hard cases, not twenty variations of a sum. Include a semi-additive measure (a balance, an inventory position, a headcount snapshot), a year-over-year and a prior-period comparison, a moving average, a ratio with a correctly handled denominator of zero, and at least one measure that must deliberately ignore a filter the user has applied. Those are the measures that break, and being able to explain why yours do not is the whole demonstration. If you are in Power BI, add one calculation group in Tabular Editor rather than writing the same time intelligence pattern across fifteen measures, and run Best Practice Analyzer over the model before you publish it.

Implement row-level security with at least two roles, and write down how you tested it, including the case where a user belongs to two roles. Implement incremental refresh and state the partition policy and the late-arriving data window. These two things are almost never in a portfolio and they are both standard interview topics.

Measure performance and show the delta. Record a deliberately slow version and a tuned one, with real numbers from Power BI Performance Analyzer, DAX Studio and VertiPaq Analyzer (or Tableau's performance recorder, or Looker's query history), and name the lever you pulled: removed a high-cardinality column, split a datetime into date and time, replaced a calculated column with a measure, removed a bidirectional relationship, added an aggregation table, pushed a transformation back so Power Query could fold the query. A before-and-after with the lever named is the most persuasive single item in a BI portfolio.

Finish with the decision log: what grain you chose and why, which source you treated as authoritative when two disagreed, what you deliberately did not model and why, what you would do differently with more time. Reviewers who have done this job read that page first. One well-documented project beats five dashboards every time, and a second project is only worth building if it is in a different stack or a different industry.

• Publish: a working link or a short recording, a repository with the SQL and measure definitions (PBIP and TMDL if you are in Power BI), and a one page model document. Never a zip file of screenshots.
• Avoid the stock sample datasets. They are pre-modelled, so using one removes the evidence of the only skill being assessed.
• Include the unglamorous artefacts: the date dimension script, the row-level security roles and how you tested them, the incremental refresh policy, and the performance before-and-after.
• State the grain of every fact table in one sentence. If you cannot, the model is not finished.
• Never publish employer data, even anonymised, even if you think it is harmless. Rebuild the pattern on public data and say that is what you did.

The resume: what lands, and what gets skipped

BI developer resumes fail in a consistent way: they describe activity rather than scale, outcome or ownership. 'Designed and developed interactive dashboards for business stakeholders' tells a hiring manager nothing, because it is true of every applicant, including the ones who have never built a model. The fix is to attach a number with a unit to an artefact you owned. Use your own real numbers. The examples below are shapes to copy, not figures to borrow.

Here is what reads as real to somebody who has done this job.

Model scale and shape. Fact table row counts, number of tables in the model, compressed model size, the cardinality of the worst column before and after you fixed it, and whether the model was import, DirectQuery, Direct Lake or composite, and why. The shape to aim for: 'Rebuilt the claims model from a flat extract to a star schema with eight dimensions, taking it from X GB to Y GB.' That is a sentence that gets a call back, because only somebody who did the work knows those two numbers.

Refresh and reliability. Full refresh duration before and after incremental refresh, the number of partitions, the refresh failure rate over a quarter and what you changed to reduce it, gateway cluster configuration, and what you did about a source that changed schema without warning.

Performance. A named report that went from X seconds to Y, how you measured it, and the lever you pulled. The lever matters as much as the number, because it proves you diagnosed rather than guessed.

Consolidation and decommissioning. Reports replaced, legacy objects retired, a cube switched off, duplicate semantic models merged into one certified model. This is the work senior people are hired to do and almost nobody puts it on a resume.

Migration. How many reports, from what to what, how long you ran both in parallel, what reconciled to the penny and what carried a stated tolerance, and how you proved it. Migration evidence is disproportionately valuable right now.

Governance and reach. Number of certified or endorsed semantic models, number of row-level security roles and the group structure behind them, workspaces owned, monthly active report users, capacity SKU and whether you managed to downsize it. Reach numbers convert 'I built reports' into 'I ran a platform'.

Cost. Licence seats consolidated, capacity reduced, warehouse spend cut by moving a query or adding an aggregation. BI is one of the few data roles where cost savings are directly attributable to you, and most candidates leave it out.

On format, this role has conventions that differ from software hiring and you should follow them. Two pages is normal and fine. Put a plainly formatted tools line near the top, because agency recruiters and non-tech ATS systems search literal strings: write both 'Power BI' and 'Microsoft Power BI', both 'SSRS' and 'SQL Server Reporting Services', both 'DAX' and 'Data Analysis Expressions', and both 'semantic model' and 'dataset'. List the warehouse and the orchestration tool, not just the BI tool. If you hold an active clearance, put the level and status in the top block. If you are applying to a public sector posting, mirror the duty language from the posting, because a human is scoring you against it.

What to cut: lists of chart types, 'Microsoft Office', 'excellent communication skills', a skills section with sixty entries where half are things you used once, generic claims about being data-driven, and any bullet that starts with 'responsible for'. Also cut certifications you are 'working towards'; list them when you hold them.

• Replace 'built dashboards for the finance team' with the same sentence carrying your real figures: 'owned the finance semantic model (N tables, N million fact rows) serving N monthly users; consolidated N reports to N and cut month-end refresh from N hours to N minutes'.
• Name the measurement tool when you claim a performance result: Performance Analyzer, DAX Studio, VertiPaq Analyzer, Tableau performance recorder, Looker query history.
• For contract work, list each engagement with client industry, duration, stack and what you delivered. Agencies read that format fluently and hiring managers expect it for contractors.
• Spell long forms as well as acronyms once each, for literal ATS matching at non-tech employers.
• One line per project naming the stack beats a paragraph naming none.

The interviews, question by question

The SQL round is universal and it is not a formality, even when the job is 90 percent Power BI. Expect joins that fan out and the question of how you would detect that they had, deduplication with ROW_NUMBER, window functions (running total, rank, lag, and the difference between them), building a date spine and left joining to it so missing days appear as zero rather than vanishing, anti joins, and writing a query against a star schema rather than against normalised source tables. A frequent trap: a query that silently returns inflated totals because a one-to-many join multiplied the fact rows. Say out loud that you would check the row count before and after the join.

The modelling round is where the job is actually decided. Expect: what is the grain of this table, in one sentence. Star versus snowflake and when you would accept a snowflake. Why not one wide flat table, which you should answer in terms of compression, measure correctness and maintainability rather than taste. The three fact table types (transaction, periodic snapshot, accumulating snapshot) and which one a given business question needs. Slowly changing dimensions type 1 versus type 2, and how you would actually implement type 2 including the surrogate key and the effective date columns. Role-playing dimensions and how you handle three different dates on one fact. Degenerate dimensions. Bridge tables for many-to-many. Conformed dimensions across two fact tables, and why that matters when somebody wants to compare them. Factless fact tables, usually asked as an attendance or coverage question. Late-arriving dimension rows. And storage mode: when import is right, when DirectQuery is forced on you by a freshness or volume requirement, what a composite model with aggregations buys you, and where Direct Lake fits if the shop is on Fabric.

The DAX round, in Microsoft shops, separates people quickly. Be able to explain filter context versus row context in your own words, what CALCULATE actually does, and what context transition is. Know when to use a measure and when a calculated column is justified, and be able to say why calculated columns on large tables cost memory. ALL, ALLSELECTED, ALLEXCEPT and REMOVEFILTERS and the differences between them. Why time intelligence functions need a contiguous date table marked as a date table. Variables, and why they improve both readability and performance. Iterators such as SUMX and when they become expensive. USERELATIONSHIP and TREATAS. Semi-additive measures over a balance. Why bidirectional filtering is usually a trap and what you use instead. Calculation groups, and why writing one time intelligence pattern once beats writing it fifteen times. Expect to write a measure live, often a year-over-year or a percentage of a total that must ignore one slicer but respect another.

The Tableau round tests a different vocabulary for the same judgment. Level of detail expressions (FIXED, INCLUDE, EXCLUDE) and, critically, the order of operations: which filters apply before a FIXED expression and which after, because that is the single most common source of a wrong Tableau number. Table calculations versus LOD expressions and when each is correct. Extracts versus live connections and the consequences of each for freshness and performance. Published data sources and why you would use one rather than embedding the connection in every workbook. Diagnosing a slow dashboard with the performance recorder. Tableau Prep for shaping. Actions, parameters and sets. If the shop runs Pulse, how metrics are defined for it.

The Looker round is a code review in disguise. Views, explores and models and how they relate. Dimensions versus measures in LookML. Symmetric aggregates and why Looker can handle a fan-out that a naive SQL join cannot. Derived tables versus persistent derived tables, and datagroups and caching policies. access_filters and user attributes for row-level control. How you would review somebody else's LookML pull request, which is the question that reveals whether you have worked in a team on a shared model.

The performance round has a right structure, and the structure is more of the answer than any individual tip. Measure before you touch anything (Performance Analyzer, DAX Studio, the query log). Then look at the model: cardinality, column types, unused columns, model size by column in VertiPaq Analyzer. Then relationships: direction, cardinality, inactive relationships, bidirectional filters. Then the measure logic: unnecessary iterators, repeated subexpressions that should be variables, CALCULATE stacked on CALCULATE. Then the query layer: does Power Query fold, or is it pulling everything into memory and transforming locally. Then the source: indexes, partitions, statistics. Then, last, the capacity. Candidates who jump straight to 'buy more capacity' or 'switch to DirectQuery' fail this round regardless of how much they know.

Expect at least one question about how changes get from your laptop to production. Know what deployment pipelines do, what breaks when a semantic model and the reports on it are deployed separately, how parameters get rebound between environments, and whether you have worked with semantic models in source control (PBIP and TMDL, Fabric git integration, or a LookML repository with pull requests). A lot of BI shops still email a .pbix around. Saying out loud how you would move them off that is a senior answer.

The stakeholder round has one question that appears so often it should be rehearsed: two reports show different revenue, what do you do. The answer that lands is procedural, not technical. Reproduce both numbers yourself. Establish the grain and the exact filters each one applies, including date basis (transaction date, posting date, ship date) and currency handling. Assume a definitional difference before assuming a bug, because it usually is one. Write the two definitions down side by side in plain language. Take them to a named business owner and get one of them agreed as the definition. Then certify one model, deprecate the other with a notice period and a redirect, and tell the affected users before you switch anything off. The second common question is a VP who wants a dashboard by Friday, which tests whether you ask what decision it supports and whether you can say the narrow true thing about what is achievable. The third is a request that duplicates an existing report, which tests whether you will quietly build the duplicate or do the harder thing.

Finally, the demo. Many loops include a screen share of something you built. Open the model view first. Walk the relationships, state the grain, show two or three measures and explain one that was hard, show the row-level security roles, then show the report. Two minutes on the model buys more credibility than ten minutes on the visuals.

• Red flags interviewers listen for: calculated columns where measures belong, one flat wide table, 'I would use DirectQuery' with no reason, tuning before measuring, and blaming business users for changing requirements.
• Have one story about a number you got wrong and how you found out. Everyone in this job has one, and candidates who claim otherwise are not believed.
• Have one story about retiring a report somebody loved, including how you handled the person.
• If the take-home is silent about AI tools, ask. Then disclose what you used either way, and be ready to defend every line as if you had written it, because you are responsible for it.
• Ask your own questions about the estate: how many semantic models, who certifies them, what the capacity is, how deployment works, and what share of reports have been opened in the last 90 days. The answer to that last one tells you exactly what the job will be.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Business intelligence developer
• BI developer
• Power BI
• Power BI Desktop
• Power BI Service
• Power BI Report Builder
• DAX
• Data Analysis Expressions
• Power Query
• M language
• Semantic model
• Dataset
• Tabular model
• SSAS
• SQL Server Analysis Services
• SSRS
• SQL Server Reporting Services
• Paginated reports
• SSIS
• SQL Server Integration Services
• T-SQL
• SQL
• Microsoft SQL Server
• Azure Data Factory
• Azure Synapse Analytics
• Microsoft Fabric
• OneLake
• Direct Lake
• DirectQuery
• Composite model
• Lakehouse
• Dataflows Gen2
• Deployment pipelines
• PBIP
• TMDL
• Row-level security
• RLS
• Incremental refresh
• On-premises data gateway
• DAX Studio
• Tabular Editor
• Calculation groups
• VertiPaq Analyzer
• Performance Analyzer
• Star schema
• Dimensional modeling
• Kimball methodology
• Slowly changing dimension
• SCD Type 2
• Fact table
• Dimension table
• Grain
• Data warehouse
• ETL
• ELT
• Tableau
• Tableau Desktop
• Tableau Server
• Tableau Cloud
• Tableau Prep
• LOD expressions
• Level of detail expressions
• Hyper extract
• Tableau Pulse
• Looker
• LookML
• Explores
• Persistent derived tables
• Looker Studio
• Qlik Sense
• MicroStrategy
• Cognos
• SAP BusinessObjects
• SAP Analytics Cloud
• Snowflake
• Databricks
• Google BigQuery
• Amazon Redshift
• dbt
• Data modeling
• Data visualization
• KPI reporting
• Self-service BI
• Data governance
• Certified dataset
• Copilot in Power BI
• PL-300
• DP-600
• Microsoft Certified: Power BI Data Analyst Associate
• Fabric Analytics Engineer Associate
• Requirements gathering
• Stakeholder management

Mistakes that cost people this job

Questions people ask