Tableau interview questions

What a strong answer covers

• Define a live connection: direct connection to the data source, queries run in real-time, always up-to-date.
• Define an extract: a static snapshot of the data stored in Tableau's proprietary format (.hyper), optimized for performance.
• Discuss use cases for live: real-time data needs, very large datasets where extracts are impractical, data governance requirements.
• Discuss use cases for extract: performance optimization, offline access, reducing load on source systems, combining data from multiple sources.

Where people lose the point

• ×Not mentioning the performance implications of each.
• ×Confusing when to use one over the other, e.g., suggesting live for very slow databases.
• ×Failing to mention that extracts can be refreshed.

What a strong answer covers

• Define dimensions: qualitative, categorical data (e.g., Product Name, Region, Date). They define the "level of detail" in a view.
• Define measures: quantitative, numerical data that can be aggregated (e.g., Sales, Profit, Quantity). They are the values being analyzed.
• Explain how Tableau typically assigns fields to dimensions or measures based on data type and content.
• Provide clear, distinct examples for both dimensions (e.g., Customer Name, Order Date) and measures (e.g., Sales Amount, Discount).

Where people lose the point

• ×Confusing the roles, e.g., saying "Sales" is a dimension.
• ×Not explaining how they interact to form a visualization (dimensions define the "what," measures define the "how much").
• ×Failing to mention that measures are typically aggregated.

What a strong answer covers

• Describe the process: right-click in the Data pane -> Create Calculated Field, or Analysis menu -> Create Calculated Field.
• Explain the components: a name, a formula using existing fields, functions, and operators.
• Provide a simple, concrete example, such as `[Sales] - [Profit]` for "Cost" or `IF [Region] = 'East' THEN 'Eastern Region' ELSE 'Other'` for a custom grouping.
• Mention the data type of the output of the calculated field.

Where people lose the point

• ×Not explaining *why* calculated fields are useful (e.g., creating new metrics, custom groupings).
• ×Providing an overly complex example that obscures the basic process.
• ×Forgetting to mention the formula editor interface.

What a strong answer covers

• List the key stages in the Tableau order of operations (e.g., Context Filters -> FIXED LODs -> Dimension Filters -> INCLUDE/EXCLUDE LODs -> Measure Filters -> Table Calculations).
• Explain what each stage does and how it affects the data available for subsequent stages.
• Emphasize the importance of context filters in affecting LOD calculations and other filters.
• Explain *why* it's important: to predict how filters and calculations will interact, troubleshoot unexpected results, and ensure correct data aggregation.

Where people lose the point

• ×Missing key stages or getting the order incorrect.
• ×Not explaining the practical implications (e.g., why a dimension filter might not affect a FIXED LOD).
• ×Failing to connect the order of operations to common analytical problems.

What a strong answer covers

• Define a join: combines data from *the same data source* (or different tables within the same connection) at the row level, creating a single logical table.
• Define a blend: combines data from *different data sources* at an aggregated level, linking them on common dimensions. Data is queried separately and then aggregated and combined in Tableau.
• Discuss the granularity difference: joins operate at the row level, blends operate at the aggregated level of the linking field.
• Explain when to use blending: when data sources cannot be joined directly (e.g., different databases, Excel + SQL), when you need to bring in supplementary data without altering the primary data source's granularity.

Where people lose the point

• ×Confusing the data source requirement (same vs. different).
• ×Not explaining the aggregation aspect of blending.
• ×Suggesting blending as a primary solution for performance issues when a join is possible.

What a strong answer covers

• Define LOD expressions: calculations that allow you to compute values at a specific level of detail, independent of the visualization's current dimensions.
• Explain `FIXED`: computes a value using only the specified dimensions, ignoring dimensions in the view (unless they are context filters). Example: `{FIXED [Region] : SUM([Sales])}`.
• Explain `INCLUDE`: computes a value using the specified dimensions *in addition to* the dimensions in the view. Example: `{INCLUDE [Customer Name] : SUM([Sales])}`.
• Explain `EXCLUDE`: computes a value using all dimensions in the view *except* the specified ones. Example: `{EXCLUDE [Product Category] : SUM([Sales])}`.
• Provide a clear use case for each type.

Where people lose the point

• ×Confusing how each LOD type interacts with the dimensions in the view.
• ×Not mentioning the impact of context filters on `FIXED` LODs.
• ×Failing to provide concrete examples that illustrate their distinct behaviors.

What a strong answer covers

• Dashboard Actions: Explain filter actions (clicking a mark filters another sheet), highlight actions (highlights related marks), and URL actions (navigates to a URL).
• Filters: Using quick filters on sheets, applying filters to multiple worksheets, and using parameters to drive filter logic.
• Parameters: Allowing users to dynamically change values in calculations, reference lines, or filter conditions.
• Sets: Using sets to create dynamic groups that users can interact with (e.g., "In/Out" sets).

Where people lose the point

• ×Only listing methods without explaining *how* they make it interactive.
• ×Not providing specific examples of how each method enhances user experience.
• ×Confusing basic filters with more advanced interactive elements.

What a strong answer covers

• Create a parameter: Define an integer parameter (e.g., "Top N Products") with a range of values (e.g., 1 to 20) and a default.
• Apply a Top N filter: Drag the dimension (e.g., Product Name) to the Filters shelf, go to the "Top" tab, select "By Field," choose "Top," select the parameter for the N value, and specify the measure (e.g., SUM(Sales)).
• Show the parameter control: Right-click the parameter and select "Show Parameter Control" to allow user interaction.
• Optionally, create a calculated field using `RANK(SUM([Sales])) <= [Top N Products Parameter]` and use it as a filter.

Where people lose the point

• ×Forgetting to create a parameter to make N dynamic.
• ×Trying to use a standard dimension filter for "Top N" without the parameter.
• ×Not explaining how to expose the parameter control to the user.

What a strong answer covers

• Use Performance Recorder: Explain how to enable and interpret the Performance Recorder to identify bottlenecks (query execution, layout computation, geocoding, etc.).
• Optimize Data Source: Suggest using extracts instead of live connections (if appropriate), reducing the number of rows/columns, optimizing SQL queries, and pre-aggregating data.
• Simplify Visualizations: Reduce the number of marks, use fewer sheets on a dashboard, simplify complex calculations (especially table calculations and LODs), and avoid excessive use of high-cardinality dimensions.
• Efficient Filters: Use context filters judiciously, avoid global filters where local ones suffice, and use parameters to drive filters instead of multiple quick filters.

Where people lose the point

• ×Only suggesting one or two solutions without a systematic approach.
• ×Not mentioning the Performance Recorder as the primary diagnostic tool.
• ×Suggesting solutions that might worsen performance (e.g., adding more complex LODs without justification).

What a strong answer covers

• Identify the core problem: A standard filter on Region would affect both the numerator (category sales) and the denominator (total sales), changing the percentage.
• Create a `FIXED` LOD expression for the overall total sales: `{FIXED : SUM([Sales])}`. This calculates the grand total sales across all data, independent of dimensions in the view or standard dimension filters.
• Create the percentage calculation: `SUM([Sales]) / {FIXED : SUM([Sales])}`.
• Apply the Region filter as a standard dimension filter: Drag `[Region]` to the Filters shelf. Because `FIXED` LODs are computed before dimension filters in the order of operations, the denominator will remain the global total, while the numerator (SUM([Sales])) will be filtered by region, showing the regional category sales as a percentage of the global total.

Where people lose the point

• ×Using a standard dimension filter for region and expecting the percentage to remain constant (it won't if the denominator is not fixed).
• ×Not understanding the interaction between `FIXED` LODs and the Tableau Order of Operations.
• ×Attempting to use table calculations without understanding their scope and addressing for this specific problem.

What a strong answer covers

• Visualization Handling: Explain that Tableau typically treats nulls as unknown or missing data. For dimensions, nulls often appear as a separate category. For measures, nulls are usually ignored in aggregations (e.g., SUM, AVG, COUNT) but can affect calculations like `COUNTD`.
• Calculation Handling: Describe how nulls interact with arithmetic operations (e.g., `NULL + 5` is `NULL`), logical operations (e.g., `NULL = NULL` is `NULL`), and functions (some functions handle nulls, others return null).
• Management Techniques: Filtering (exclude nulls), Replacing (use `ZN()` for measures, `IFNULL()` or `ISNULL()` for dimensions/measures), Grouping (group nulls with other values), Data Preparation (address at source), Formatting (customize appearance).

Where people lose the point

• ×Assuming nulls always behave like zeros in aggregations.
• ×Not knowing common functions like `ZN()` or `IFNULL()`.
• ×Failing to distinguish between how nulls are handled in dimensions vs. measures.

What a strong answer covers

• Define Dashboard Actions: User-driven events (e.g., clicking, hovering, selecting) that trigger a response in other parts of the dashboard or external resources.
• Enhance UX: Explain how they enable drill-down, cross-filtering, highlighting, and navigation, making dashboards dynamic and exploratory rather than static.
• Types: Briefly mention Filter, Highlight, and URL actions.
• Filter Action Example: Describe setting up a filter action where clicking on a bar in a "Sales by Region" chart filters a "Sales by Product" chart to show only products sold in the selected region. Detail the source sheet, target sheet, and how the filter applies.

Where people lose the point

• ×Confusing dashboard actions with quick filters.
• ×Not explaining the "source" and "target" sheets in an action.
• ×Failing to articulate *why* actions are valuable for user experience.

What a strong answer covers

• Define Hierarchy: A structured arrangement of dimensions that allows users to drill down from a broader category to more granular levels within a single field.
• Purpose: Facilitates exploration of data at different levels of detail, simplifies dashboard design by reducing the number of individual filters, and provides an intuitive user experience for navigating related data.
• Example: A "Date" hierarchy (Year -> Quarter -> Month -> Day) or a "Product" hierarchy (Category -> Sub-Category -> Product Name).
• How to create: Drag one dimension onto another in the Data pane.

Where people lose the point

• ×Confusing hierarchies with groups or sets.
• ×Not explaining the "drill-down" functionality.
• ×Failing to provide a clear, common example.

What a strong answer covers

• Define Group: A static collection of dimension members combined into a single new dimension. Groups are permanent and manually created or based on a fixed selection.
• Define Set: A dynamic collection of dimension members based on specific conditions or a selection. Sets can be dynamic (conditions update automatically) or static (fixed selection). They result in an "In/Out" field.
• Key Differences: Static vs. Dynamic (groups are static; sets can be dynamic); Output (groups create a new dimension; sets create an "In/Out" boolean field).
• When to use: Groups for permanent, manual categorizations. Sets for flexible, conditional, or comparative analysis (e.g., "Top N" or comparing a subset to the rest).

Where people lose the point

• ×Confusing the static nature of groups with the dynamic potential of sets.
• ×Not explaining the "In/Out" nature of sets.
• ×Failing to provide distinct use cases for each.

What a strong answer covers

• Create a Date Parameter: Define a date parameter (e.g., "End Month") that allows the user to select a specific month/year.
• Create a Filter Calculated Field: Use a calculated field to determine if a date falls within the last 12 months relative to the selected "End Month" parameter. Example: `[Order Date] <= [End Month Parameter]` AND `DATEDIFF('month', [Order Date], [End Month Parameter]) < 12`. Drag this to the Filters shelf and set to `TRUE`.
• Create a Running Total Calculation: Use a table calculation for running total of sales. Example: `RUNNING_SUM(SUM([Sales]))`.
• Set Table Calculation Scope: Ensure the running total calculation is computed along the date dimension (e.g., "Table (Across)" or "Pane (Down)" depending on layout, or specific dimensions).
• Show Parameter Control: Expose the "End Month" parameter to the user.

Where people lose the point

• ×Not using a parameter to make the end month dynamic.
• ×Incorrectly calculating the "last 12 months" range (e.g., off-by-one errors with `DATEDIFF`).
• ×Forgetting to apply the date filter *before* the running total calculation, or incorrectly setting the table calculation scope.