Scenario-Based Tableau Interview Questions

First compare filters, date ranges and data refresh time between both sources. Check the aggregation used, for example SUM versus AVG, and whether joins have duplicated rows, which inflates totals. Use View Data to inspect underlying rows and COUNT the records. Check null handling and whether Excel has hidden rows or manual adjustments. Document the cause and fix it at the data source level.

Employee ID is numeric, so Tableau classified it as a measure. Right-click it in the Data pane and choose Convert to Dimension, and optionally Convert to Discrete. Now it acts as a label rather than an aggregated number. If you need the number of employees, use COUNTD(Employee ID) instead of SUM. Fixing default properties early avoids wrong numbers across all sheets.

Create a string parameter with the values Sales, Profit and Quantity. Create a calculated field: CASE [Measure Selector] WHEN 'Sales' THEN SUM([Sales]) WHEN 'Profit' THEN SUM([Profit]) ELSE SUM([Quantity]) END. Use this field on the axis, show the parameter control, and put the parameter in the title so users know which measure they see. Number formatting can be handled with separate calculations if needed.

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.

The join type or grain caused duplication. If Returns has multiple rows per order, an inner or left join repeats each order line, so SUM(Sales) inflates. Fix it by using a relationship instead of a join, aggregating Returns to order level before joining, or using an LOD to deduplicate. Always check row counts before and after a join to catch this problem early.

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 wildcard union on the folder with a pattern such as Sales_*.xlsx so new files are included automatically on refresh. Alternatively, build a Tableau Prep flow with a wildcard input and schedule it with Prep Conductor. Ensure every file has the same column names and types. Use the Path or Table Name field to derive the month if it is not in the data.

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.

The formula mixes a row-level field with an aggregated one, such as IF [Sales] > AVG([Sales]). Either aggregate everything, for example IF SUM([Sales]) > 1000, or make everything row level. If you need to compare a row with an overall average, use an LOD such as [Sales] > {FIXED : AVG([Sales])}, which returns a row-level value that can be mixed safely.

Right-click the date field, choose Default Properties, then Fiscal Year Start, and select April. Tableau then shows FY quarters and years based on April. For a label such as FY 2025-26, create a calculation: IF MONTH([Order Date]) >= 4 THEN STR(YEAR([Order Date])) + '-' + RIGHT(STR(YEAR([Order Date]) + 1), 2) ELSE STR(YEAR([Order Date]) - 1) + '-' + RIGHT(STR(YEAR([Order Date])), 2) END.

Try changing the data type to Date first; Tableau may parse it automatically. If not, use DATEPARSE with the pattern: DATEPARSE('dd-MM-yyyy', [Date String]). For extracts and most databases this works reliably. Alternatively use MAKEDATE with INT of SPLIT parts. Then check for nulls, which indicate rows with a different format that need cleaning.

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.

If you used a quick table calculation, the total is computed on the filtered view, so it changes. Replace it with a FIXED LOD for the total, which ignores dimension filters, or use EXCLUDE for the filtered dimension. Make sure any filters that should affect the total are added to context. Test with and without filters and document the behaviour.

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.

FIXED returns a value repeated on every row at the fixed level. If the view is at a finer level, or at the total level, SUM adds the repeated values, multiplying the result. Use MIN, MAX or AVG to bring back the single value, or make sure the view level matches the FIXED dimensions. This is a frequent mistake when using table-level totals.

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.

Calculate category max: {FIXED [Category] : MAX({FIXED [Category], [Product Name] : SUM([Sales])})}. Then flag: IF {FIXED [Category], [Product Name] : SUM([Sales])} = [Category Max] THEN 'Top' END and filter to Top. A simpler alternative is a RANK table calculation computed along products within each category, filtering rank equal to 1.

The table calc was probably set to Table Across or Table Down, which depends on layout. When fields move between Rows and Columns, the direction changes. Edit the table calculation and set Compute Using to Specific Dimensions with the correct addressing fields. Then the calculation stays correct even if users or developers reorganise the sheet.

Normal filters remove rows before the rank is computed, so rank recalculates on the filtered set. Either replace the filter with a table calculation filter such as LOOKUP(MIN([Product]), 0), which hides rows after ranking, or compute rank with an LOD-based approach. Explain both behaviours to the user and confirm which rank they actually need.

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.

Place MONTH(Order Date) discrete on Columns and YEAR(Order Date) on Color with SUM(Sales) on Rows. Add a quick table calculation Percent Difference, compute using Year, relative to previous. Each month now shows growth versus the same month last year. Alternatively calculate with LOOKUP(SUM([Sales]), -1) partitioned by month and addressed by year.

Explain that a pie with 15 slices is hard to read because people compare angles poorly. Suggest a sorted horizontal bar chart showing values and percentages, which makes ranking clear, or group the smallest categories into Others and show the top five. If they still want a pie, limit it to a few slices. Offer both and let them choose based on readability.

Click the unknown indicator and choose Edit Locations. Tableau shows unmatched names; correct spellings such as Bengaluru versus Bangalore, set the correct country and state context, or map them manually. Make sure State is in the view to resolve duplicate city names. For permanent fixes, clean names at the source or add latitude and longitude columns.

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.

Right-click the filter pill or quick filter and choose Apply to Worksheets, then either All Using Related Data Sources, All Using This Data Source, or Selected Worksheets. Pick the sheets on the dashboard. If sheets use different sources, ensure the field is related or use a parameter. Test each sheet after applying.

Top N filters run before normal dimension filters, so Top 10 is computed on all regions, and then the region filter removes some of those products. Add the Region filter to context, so it runs first and Top 10 is calculated within the selected region. The Region pill turns grey to show it is a context filter.

Create a date parameter with dynamic current value from a calculation such as MAX([Order Date]) or TODAY()-1, refreshing when the workbook opens. Filter the data with a calculation [Order Date] = [Selected Date] set to True. Show the parameter control. Users get yesterday by default and can pick another date without editing the workbook.

Measure first with performance recording. Reduce the number of quick filters and replace some with dashboard filter actions. Change Only Relevant Values to All Values in Database where cascading is not needed. Add an Apply button to multi-select filters, convert high-cardinality filters to wildcard search, and move fixed restrictions to data source filters. Re-test after changes.

Create a float parameter Price Change with a slider range of -20 to 20 percent. Build calculations: New Revenue = SUM([Sales]) * (1 + [Price Change]) and New Profit = New Revenue - SUM([Cost]). Optionally include an elasticity parameter for demand change. Show current versus projected profit side by side, and label assumptions clearly on the dashboard.

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.

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.

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.

CONTAINS is case-sensitive in many sources, so Phone or PHONE will not match. Use CONTAINS(LOWER([Product]), 'phone') to normalise case. Also trim extra spaces and check for nulls. If you need complex patterns, use REGEXP_MATCH where the data source supports it. Test the result by counting matched rows and reviewing samples.

The dashboard probably uses Automatic or Range size, so objects reflow on different resolutions. Set a fixed size suitable for the audience, such as 1366 by 768 or 1200 by 900, or use Range carefully with tiled containers. Avoid floating objects that overlap. Create a device layout for phones if needed and test on common screen sizes before sharing.

Check the background task and job history for the error message. Common causes are expired or changed database passwords, firewall or VPN issues, schema changes like renamed columns, timeout because the query is too large, or Backgrounder overload at peak time. Fix credentials, update the data source, optimise the query or move the schedule. Set up failure email notifications.

Compare data connection, since Server may use a live connection through a slower network or different credentials. Record performance on Server using the performance recording parameter. Check concurrent load, VizQL and cache settings, the number of quick filters and marks, and whether extracts are refreshing at the same time. Ask the Server admin for resource usage and background job schedules.

Use Tableau's embedding API or the Tableau web component to embed views in the portal, with single sign-on such as SAML or connected apps for authentication so users do not log in twice. Ensure users have licences and correct permissions, apply row-level security, set the dashboard size to fit the portal, and use the API to pass filters or parameters from the page.

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.

Control capabilities through permissions: allow Download Summary Data but deny Download Full Data, or deny downloads entirely for some groups. Remove sensitive fields from the data source or hide them, and apply row-level security so downloaded data is limited to the user's scope. Provide a dedicated crosstab sheet with approved fields for export and document what is allowed.

Ask which questions they need answered first. Follow a top-down layout: KPIs at the top, main trend and comparison charts in the middle, details at the bottom or on drill-through. Remove decorative elements, reduce colours, align objects in containers, use white space and consistent fonts, and move secondary filters into a collapsible panel using show and hide buttons.

Turn on Data Interpreter on the data source page, which detects headers, removes title rows and handles sub-tables. Review the interpreter results sheet it produces. If it still fails, clean the file in Excel or Tableau Prep by removing merged cells and keeping one header row. Ask the data owner for a clean, tabular format for future files.

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.

Create Orders per Customer: {FIXED [Customer ID] : COUNTD([Order ID])}. Summing a row-level 1 or 0 flag would count order lines, not customers, so instead use COUNTD(IF [Orders per Customer] > 1 THEN [Customer ID] END) / COUNTD([Customer ID]). Format as percentage and break it down by region or segment to compare loyalty.

Grand totals in Tableau are computed at a higher level using the same aggregation, so for averages or ratios the total is recomputed rather than summed. For table calculations or LODs, results can look inconsistent. Right-click the measure, choose Total Using and select Sum to add displayed values, or create a custom calculation using WINDOW_SUM. Confirm with the manager which total makes sense.