The technical questions that distinguish senior Tableau developers in interviews — LOD expressions, performance optimisation, server architecture, data source strategy, and the scenario-based questions that reveal whether candidates can solve real enterprise BI problems.
Hiring a senior Tableau developer is harder than it looks. The proliferation of Tableau training courses and certifications means many candidates have learned the tool without developing the deep problem-solving ability and architectural thinking that senior roles require. Effective technical interviews distinguish candidates who can build dashboards from candidates who can architect enterprise BI environments, handle complex analytical problems, and scale Tableau across hundreds of users.
These are the questions that actually reveal capability at the senior level.
LOD Expression Questions
"Explain the difference between FIXED, INCLUDE, and EXCLUDE LOD expressions, and give me a use case where you would choose each."
Strong answer: FIXED computes at the specified dimensions regardless of view level; INCLUDE adds dimensions to the view level; EXCLUDE removes dimensions from the view level. FIXED for computing customer-level metrics in an order-level view, for percent of total, for cohort analysis. INCLUDE for average of customer averages. EXCLUDE for regional benchmark shown at state level.
Weak answer: a description of the syntax without clear use case distinctions.
"A FIXED LOD calculation is not respecting my date filter. What is happening and how do you fix it?"
This tests understanding of filter order of operations. Strong answer: FIXED is computed before dimension filters. The date filter is a dimension filter, so it does not affect FIXED. To make FIXED respect the date filter, either add the date dimension to the FIXED calculation, or move the date filter to context (Use as Context Filter). Context filters are applied before FIXED.
Weak answer: confusion about why LODs do not follow filters, or suggesting incorrect fixes.
"You need to show the percentage of total revenue that each product accounts for, but you also need the user to be able to filter by region without affecting the denominator. How do you build this?"
The denominator (total revenue) should not change when region is filtered. This requires FIXED with no dimension: {FIXED : SUM([Revenue])} for the denominator. The numerator is SUM([Revenue]) filtered by the current region. The FIXED expression computes before the region dimension filter, so it always represents total revenue.
Performance Questions
"You have a workbook with 12 sheets on a single dashboard. It loads in 45 seconds. How do you diagnose and fix it?"
Diagnosis: use Tableau's built-in Performance Recording (Help > Settings and Performance > Start Performance Recording). Reproduce the slow load. The Performance Recorder shows timing for each operation: query execution time, rendering time, layout time. Identify the slowest operations.
Common fixes: reduce the number of visible sheets on initial load (use floating containers and show/hide); switch from live connection to extract if queries are slow; simplify calculations by pushing computation to the extract; check for table calculations that reference all marks; reduce the number of marks per chart.
"What is the difference between using a live connection and an extract, and when should you use each?"
Live connection: queries the source database in real time. Every view interaction generates a query. Use when data freshness is critical (sub-hour currency required) and the source database can handle the query load.
Extract: a snapshot of data stored in Tableau's Hyper format. Queries run against the local Hyper file — significantly faster than most database queries for typical BI patterns. Hyper is columnar and optimised for the aggregation patterns BI produces. Use extracts when: data does not need to be more current than the extract schedule allows, when the source system cannot handle the query load, or when performance on complex calculated fields is critical.
"A Tableau Server environment has backgrounders that are always running at 100% utilisation. What are the possible causes and how do you investigate?"
Backgrounders handle extract refreshes, subscriptions, and flow runs. 100% utilisation means either: too many concurrent jobs for the number of backgrounder processes, individual jobs taking too long, or both.
Investigation: Tableau Server's Status > Background Tasks view shows which tasks are running and how long they are taking. Look for: extract refreshes that are consistently slow (indicates slow source query or large data volumes), tasks that run simultaneously (adjust schedules to spread load), stuck tasks (investigate the source system), or tasks that always run past their scheduled window.
Possible fixes: add backgrounder processes (requires server resources), reduce concurrent jobs via schedule spreading, optimise slow extracts, consider upgrading to faster source queries or smaller extract scopes.
Server Architecture Questions
"Walk me through the Tableau Server architecture. What are the key processes and what does each do?"
Strong answer: VizQL Server handles rendering workbooks into visualisations — this is the core query and render engine. Application Server handles web requests, authentication, and the Tableau web interface. Backgrounder handles asynchronous jobs (extract refreshes, subscriptions, flows). Data Server manages data source connections and caching for published data sources. Gateway routes requests to the appropriate process. Repository is the PostgreSQL metadata database. Cache Server handles in-memory query caching.
For distributed deployments: these processes can run on separate nodes to scale horizontally. VizQL Server is typically the first bottleneck at scale.
"What is the difference between Tableau Server and Tableau Cloud, and when would you recommend one over the other?"
Tableau Server: self-managed, on-premises or cloud-hosted VM. Full control over infrastructure, configuration, and data residency. Requires ongoing IT/admin overhead for patching, upgrades, monitoring.
Tableau Cloud: SaaS, fully managed by Tableau/Salesforce. No infrastructure management. Regular automatic updates. Requires that data can be connected from the cloud (Bridge for on-premises sources).
Recommendation framework: Tableau Cloud for organisations that want to minimise operational overhead, have data accessible to cloud connection, and can accept Tableau's SaaS release cadence. Tableau Server for organisations with strict data residency requirements, existing investment in on-premises infrastructure, or need for fine-grained server configuration control.
"You are architecting a Tableau Server environment for 500 concurrent users. What does your infrastructure look like?"
500 concurrent users is a significant load. VizQL Server processes are the primary bottleneck — each process handles 2-4 concurrent sessions. For 500 concurrent users, you likely need 5-10 VizQL processes, which can run on a single large node or distributed across multiple nodes.
Other considerations: separate backgrounder nodes for extract refresh load (so refreshes do not compete with interactive sessions), Application Server capacity for web requests, sufficient memory for the Repository database under query load, and network bandwidth for VizQL Server to serve large rendered views.
Data Source and Modelling Questions
"What is the difference between a published data source and an embedded data source? What are the governance implications of each?"
Embedded data source: the data connection is embedded in the workbook. Each workbook with an embedded connection manages its own credentials and connection string. Not reusable across workbooks.
Published data source: a data source published independently to Tableau Server or Cloud. Multiple workbooks can connect to the same published source. Credentials are managed centrally. Governance advantage: extract refresh, permissions, and schema are managed in one place. If the source system schema changes, you update one published data source rather than every workbook.
For governed environments, published data sources are strongly preferred — they create a single source of truth for the data model, enforce consistent calculations, and simplify maintenance.
"A business user says the numbers in their Tableau dashboard do not match the numbers in a report someone else built in Excel. How do you investigate?"
Structured investigation: first, identify exactly which numbers disagree (which metric, which time period, which filter conditions). Second, trace each number's calculation: for the Tableau number, look at the calculated fields, data source, filters, and aggregation. For the Excel number, understand the formula and data source. Third, identify where the logic diverges: different date range definitions? Different inclusion/exclusion criteria? Different aggregation (sum vs average vs count)? Different data source versions?
This tests both technical capability and business communication skills. Strong candidates articulate a systematic debugging approach, ask clarifying questions, and understand that "the numbers don't match" is almost always a data definition disagreement, not a Tableau bug.
For Tableau consulting and talent assessment, our Tableau consulting practice helps organisations build and evaluate their Tableau capability — contact us to discuss your Tableau team requirements.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →