Hard Tableau Interview Questions

In the order of operations, FIXED LOD expressions are computed before dimension filters, so a normal filter on Region does not change a FIXED result. To make the filter apply first, right-click it and choose Add to Context, because context filters run before FIXED. Alternatively, include the filtered dimension inside the FIXED declaration. This is one of the most frequently asked Tableau interview questions.

Publish a certified data source to Server or Cloud with agreed calculated fields, default formats, hierarchies, folders and descriptions. Ask analysts to connect to that source instead of local copies. Maintain a data dictionary, naming conventions and a review checklist before publishing. Remove duplicate calculations from workbooks. This gives one version of truth and makes later changes in one place.

With relationships, Tableau uses performance options such as cardinality (one or many) and referential integrity (some or all records match). At query time it includes only tables needed for the fields in the view and typically uses outer join semantics, so unmatched dimension values are kept. Setting correct cardinality and integrity lets Tableau generate efficient queries and avoid unnecessary distinct counts.

Custom SQL lets you write your own query as a data source, useful for complex logic or pre-aggregation. The drawback is performance: Tableau wraps it as a subquery, so the database may not optimise filters well, and it blocks some features such as join culling. It is also harder to maintain. Prefer database views or relationships and use custom SQL only when needed.

Check the performance recording to see slow queries. Options include switching to an extract with aggregation and extract filters, adding database indexes or materialised views, removing custom SQL, enabling referential integrity assumptions, reducing the number of marks and quick filters, and using context filters wisely. If real-time is not required, a scheduled extract usually gives the biggest improvement.

Use a relationship between the tables on Region and a month key, since relationships keep each table at its own grain and avoid duplicating targets across days. In the view, aggregate sales to month level and compare with targets. If using joins, first aggregate daily sales to month in Prep or SQL. Blending on Region and MONTH(date) is another option.

Row-level calculations on large live sources run in the database for every query, so heavy string operations and nested IFs can be slow. Best practices are to use booleans and integers instead of strings, prefer CASE for fixed lists, move complex logic to the database or extract, materialise calculations in extracts, avoid unnecessary COUNTD, and keep LODs and table calculations simple.

Run a performance recording to confirm calculations are the bottleneck. Replace string comparisons with integer or boolean logic, convert long IF chains on single values to CASE, move derived columns into the database view or an extract so they are materialised, and remove unused calculations. Hide unused fields before extracting. Measure again after each change to show improvement.

Extract, data source and context filters apply before FIXED, so they change FIXED results. Normal dimension filters apply after FIXED, so they do not affect it but do affect INCLUDE and EXCLUDE. Measure filters apply later still. Therefore, to make a region filter change a FIXED total, add it to context. Knowing this order prevents incorrect percent-of-total and cohort results.

Each LOD generates a subquery joined back to the main query, so many LODs on large live data increase query complexity. FIXED on high-cardinality dimensions such as Order ID can be expensive. Keep the number of LODs small, prefer extracts, use FIXED with minimal dimensions, and check performance recordings. Sometimes pre-aggregating in the database is better than complex nested LODs.

Create First Purchase Month: {FIXED [Customer ID] : MIN(DATETRUNC('month', [Order Date]))}. Then Customer Type: IF DATETRUNC('month', [Order Date]) = [First Purchase Month] THEN 'New' ELSE 'Repeat' END. Put MONTH(Order Date) on Columns, COUNTD(Customer ID) on Rows and Customer Type on Color. Validate a few customers manually to make sure classification is correct.

Compute daily totals first with an LOD, then average: AVG({FIXED DATETRUNC('day', [Order Date]) : SUM([Sales])}). If it must respond to filters such as Region, use INCLUDE instead: AVG({INCLUDE DATETRUNC('day', [Order Date]) : SUM([Sales])}) with the view at month or region level. Averaging raw transactions would give average ticket size, which is a different metric.

Situation: a new team member struggled with LOD expressions and kept producing wrong totals. Task: help her become independent. Action: I set up weekly thirty-minute sessions, explained the order of operations with small examples, reviewed her workbooks with comments, and shared a checklist. Result: within six weeks she delivered a cohort dashboard on her own, and the checklist became part of team onboarding.

Table calculation filters apply at the end of the order of operations, after the calculation, so they hide marks without removing data from the computation. A normal dimension filter removes rows before the calc, changing running totals and ranks. To show only the last three months while keeping a running total from the start, filter with a table calc such as LAST() <= 2.

Choose an LOD when the result must be used as a dimension, a filter, in another data source level calculation, or must stay correct regardless of view layout, such as a customer's first purchase. Choose a table calculation for sequence-based logic such as running totals, ranks, moving averages and previous period values. LODs run in the database; table calcs run locally on the result set.

Table calcs run on the result set, so large numbers of marks make them slow. Reduce marks by aggregating to the needed level, filter data earlier with context or data source filters, replace some table calcs with LODs or database-side calculations, and avoid nested WINDOW functions over thousands of rows. Use a performance recording to confirm computing layouts and query time.

Use colour with a purpose: highlight key data and keep the rest neutral. Use sequential palettes for ordered values, diverging palettes around a meaningful midpoint such as zero profit, and categorical palettes with fewer than eight colours. Keep colours consistent across sheets, check colour-blind friendliness, avoid red and green only, and never use colour as the only way to convey meaning.

Put Sub-Category on Columns and SUM(Profit) on Rows, add a Running Total quick table calc, and change mark type to Gantt Bar. Create a calculation -SUM([Profit]) and put it on Size so each bar extends from the previous total. Colour by profit sign and enable Show Row Grand Totals to display the final bar.

Clarify the top five decisions the dashboard should support. Show 4 to 6 headline KPIs as cards at the top, group the others into themed sections or separate tabs, and use drill-down actions to detailed views. Use consistent formatting, small multiples and sparklines for trends. Prototype with users, gather feedback, and remove KPIs that nobody uses.

A filter action removes data from target sheets based on a selection. A set action changes membership of a set, keeping all data available, so you can compare selected versus unselected, colour them, or build proportional brushing and drill-down within the same sheet. Set actions offer more flexible interactions, such as asymmetric drill down in a hierarchy, without losing context.

Every quick filter with Only Relevant Values sends extra queries to fetch domain values, and multiple value lists on high-cardinality fields like Customer Name are expensive. Many filters also slow rendering. Use action filters from charts instead, use Apply buttons, prefer All Values in Database for large lists, filter dates with ranges, and push data source filters for fixed restrictions.

Create a float parameter, for example Selected Value. Add a reference line using that parameter. Then go to Dashboard, Actions, Add Action, Change Parameter, choose the source sheet, target parameter Selected Value, and source field SUM(Sales), with aggregation set as needed. Clicking a bar updates the parameter, and the reference line moves to compare other bars with it.

Create a set on Category. Build a calculation: IF [Category Set] THEN [Sub-Category] ELSE '' END, and place Category and this calculation on Rows. Add a set action on select that assigns values to Category Set and removes them when cleared. Clicking a category expands only its sub-categories, creating an asymmetric drill down that standard hierarchies cannot do.

Set clearing behaviour to Show all values instead of Exclude all values, add clear titles that show the current selection using dynamic text, and add an instruction line such as Click a region to filter. Use highlight actions where filtering is unnecessary. Provide a reset button through a parameter action or navigation button, and test with real users.

Implement row-level security rather than relying on filters users can change. Use a user mapping table with usernames and regions, relate it to the data, and create a data source filter USERNAME() = [Username]. Publish the data source with the filter so it cannot be removed. For large deployments, consider virtual connections with data policies. Test by impersonating users on Server.

Situation: I received eight dashboard requests in one week as the only senior BI developer. Task: deliver the most valuable work first. Action: I listed requests with business impact, effort and deadlines, reviewed them with my manager, delivered quick wins using existing data sources, and shared timelines for the rest. Result: high-impact requests were delivered on time and stakeholders appreciated the transparency.

When a dashboard uses multiple data sources, you can apply a filter to all related data sources if a field is related through blending or defined relationships via Data, Edit Blend Relationships. Tableau maps the field between sources, so one quick filter controls sheets from different sources. Mismatched values between sources will not filter correctly, so field values must align.

Use relative metrics such as growth percent, sales per square foot or target achievement instead of absolute sales. Consider log scale for wide ranges, separate small multiples by store size band, or independent axes. Sorting and highlighting outliers also help. Explain the chosen normalisation in the subtitle so readers understand the comparison.

Put the KPI dimension on Rows and continuous MONTH(Order Date) with SUM(Sales) on a separate column, choose line marks, and set Independent Axis Ranges for each row via Edit Axis. Remove gridlines, axes, headers and borders, and highlight the last point using a calculation such as IF LAST() = 0 THEN SUM([Sales]) END as a dual axis circle.

Agree on a business definition with stakeholders, such as a customer with at least one order in the last 90 days, and document it. Create one calculated field using an LOD on the last order date, add it to a certified published data source with a description, and deprecate old versions. Communicate the change and compare old and new numbers so users understand the difference.

Tableau Server runs processes such as Gateway for incoming requests, Application Server for the web interface and permissions, VizQL Server for rendering views, Backgrounder for extract refreshes and subscriptions, Data Server for published data sources, Data Engine (Hyper) for extracts, the Repository database for metadata, and File Store. Administrators scale by adding nodes and adjusting process counts, often isolating Backgrounder on separate nodes.

Tableau Pulse is a metrics layer that delivers personalised KPI summaries with AI-generated insights in plain language, through the web, email or chat tools. Instead of opening a dashboard and exploring, users follow metrics such as weekly revenue and get notified about changes, drivers and trends. Dashboards remain better for deep exploration, while Pulse serves quick, proactive monitoring.

Create an entitlement table with Username and Region columns, maintained by the business or IT. Relate or join it to the fact table on Region. Create a calculation USERNAME() = [Username] and add it as a data source filter set to True. Publish the data source with embedded credentials and restrict download permissions. Test with View As or user impersonation for each role.

Inventory content and usage to retire unused workbooks, map sites, projects, users, groups and permissions, and plan authentication. Set up Tableau Bridge for on-premise data, recreate schedules and subscriptions, and use migration tools to move content. Test critical dashboards for performance and row-level security, plan a pilot, communicate cut-over dates, and keep a rollback plan.

Use admin views and usage statistics to find stale or duplicate content. Agree a governance model with owners: certified data sources, project structure by department, naming standards, and a sandbox project for drafts. Archive content not viewed in 90 days after notifying owners, lock project permissions, and set a monthly review. This reduces confusion and Server load.

Assess whether the source supports frequent queries. Options are a live connection to an optimised warehouse table with pre-aggregated data, or frequent incremental extract refreshes if allowed. Keep the dashboard light with few marks, headline KPIs and a trend, and enable auto-refresh behaviour or ask users to refresh. Load test before the event and monitor during it.

Situation: a sales director asked me to remove returns from revenue on the leadership dashboard to show higher growth. Task: keep reporting accurate while meeting his need. Action: I explained the impact on other reports, showed gross and net side by side with clear labels, and escalated the definition to finance for a final decision. Result: finance confirmed net revenue, and the director accepted it.

A virtual connection is a shareable, centrally managed access point to database tables, with embedded credentials and optional extracts. A data policy attached to it applies row-level security at the table level using user functions and entitlement tables. Every workbook and data source using the connection inherits the security, so rules are defined once instead of in each data source. It requires Data Management licensing.

Use extracts where real-time data is not needed, schedule refreshes outside peak hours, and aggregate extracts to required grain. Reduce quick filters with relevant values, limit dashboards that auto-refresh, and use published data sources so caching is shared. Work with data engineers on materialised or clustered tables. Monitor query history and cost per dashboard to target the worst offenders.