Top Tableau Interview Questions & Answers (2026)

FIXED computes at the dimensions I name, regardless of the view. Example: first purchase date per customer, FIXED Customer ID with MIN of Order Date, which lets me build cohort analysis. INCLUDE adds a dimension to the view's level of detail then aggregates back up. Example: average order value per customer shown by region: INCLUDE Customer, SUM of Sales, then averaged in the view, so region shows the average customer spend, not average line value. EXCLUDE removes a dimension from the view's detail. Example: each sub-category's sales compared to its category total in a view that shows sub-categories: EXCLUDE Sub-Category, SUM of Sales. One more key point: FIXED is evaluated before dimension filters; INCLUDE and EXCLUDE after.

Roughly, Tableau processes extract filters first, then data source filters, then context filters. Then it computes Top N, conditional filters, sets and FIXED LOD expressions. Next come dimension filters, then INCLUDE and EXCLUDE expressions, then measure filters. Table calculations are computed on the results after that, and table calculation filters and reference lines come near the end. It matters because most wrong-number bugs are an order question. A FIXED total ignores a dimension filter because it runs earlier. A percent-of-total table calc still works after you hide rows with a table calc filter because it filters after computing. When a user says the number did not change when they filtered, I map their filter and calc onto this sequence first.

Table calculations run on the aggregated results already in the view, not the underlying rows. Running totals, percent of total, rank, moving average and difference from previous are typical. Partitioning defines the groups the calculation restarts in; addressing defines the direction it moves through within each partition. Compute Using is how you set that. If I have Year on columns and Region on rows with a running total, computing along Table Across restarts per region and runs across years. If the result looks wrong, it almost always means the addressing is wrong, so I check Edit Table Calculation and set specific dimensions rather than relying on Table Across, so it does not break when someone moves a pill.

I start with a Performance Recording, which shows whether time goes to executing queries, computing layouts, or geocoding and rendering. If query time dominates, I look at the data source: switch to an extract or tune the live query, hide unused fields, aggregate the extract to visible dimensions, and replace complex row-level calcs with fields computed upstream. I also reduce quick filters, especially ones showing only relevant values, because each one fires its own query. If rendering dominates, I cut the number of marks and sheets on the dashboard. High-cardinality text tables with thousands of rows are a common culprit; a summary with drill-down to detail is usually better. Then I re-record to confirm the gain.

I would use an entitlement table that maps usernames to the accounts or territories they can see, relate or join it to the data, and add a data source filter that keeps rows where the entitlement username equals USERNAME(). For group-based rules, ISMEMBEROF() against a Tableau group works well. I put the filter on the published data source rather than the workbook so every workbook built on it inherits the security, and I restrict who can edit that data source. Hiding sheets or relying on a user filter on a dashboard is not security, because anyone with web edit or download rights can get around it. I test with dedicated test accounts that mirror a real rep and a real manager.