Tableau Developer Interview Questions and Answers

A Tableau developer (also titled BI Developer, Analytics Engineer, or Visualization Specialist) owns the path from warehouse data to trusted dashboards stakeholders actually use—not only pretty charts.

Typical ownership:

Titles vary: some roles are 80% authoring; others include Server admin or embedded analytics. Read the job description for Server admin vs pure build weight.

Loops blend SQL, Tableau mechanics, and scenario judgment—interviewers care more about how you debug a wrong number than which menu holds a feature.

Community interview reports emphasize scenarios—"sales dropped in the dashboard; how do you investigate?"—over trivia about ribbon labels.

Three to four weeks is enough if you build and explain, not only watch videos.

Use Superstore or a public dataset—explain every design choice as if to a hiring manager: grain, chart type, why not a pie chart, etc.

Enterprise stacks evolve, but LOD, grain, and performance still dominate technical screens. Newer topics show up in conversation, not always whiteboard depth.

Increasingly mentioned:

• Tableau Pulse — AI-powered metric insights and follow-up questions for business users
• Tableau Agent — natural-language help for exploration, calculations, and visual analysis
• Tableau Next — Salesforce-native, agentic analytics direction in newer enterprise conversations
• Data Cloud / Salesforce connectors — important in Salesforce-centric deployments

Unchanged core bar: Can you explain why a number differs from Excel? Can you choose FIXED vs table calc? Can you tune a slow workbook? LOD, grain, relationships, and performance still matter most in technical rounds.

Tableau splits fields into dimensions (how you slice) and measures (what you aggregate)—the foundation of every view's level of detail.

Level of detail: Whatever dimensions are on Rows, Columns, Marks, or Detail define the granularity of the view; measures aggregate to that grain.

Interview trap: Converting a measure to a dimension (or dragging Sales to Dimensions) changes aggregation behavior—SUM(Sales) vs treating each row's sales as a category.

A strong answer is:

Dimensions slice the data and define the view's level of detail; measures aggregate at that level. I watch pill type because turning a measure into a dimension changes how numbers roll up.

Discrete and continuous control how Tableau lays out a field—not just color of the pill.

Classic example: Order Date as discrete years → one bar per year. Same field continuous → line chart flowing through time.

Wrong pill type is a top "my chart looks wrong" debugging question—check discrete vs continuous before changing chart type.

A strong answer is:

Discrete creates separate headers or bins; continuous creates a ranged axis. For trends I usually use continuous date; for comparing years side by side I use discrete date parts.

Tableau aggregates measures at the granularity of the view—whatever dimensions are in the viz define each bucket.

Example: Region on Rows:

• SUM(Sales) → total sales per region row
• AVG(Sales) → average of underlying row-level sales values in each region—not the same as "average of regional totals" in a different layout

Senior follow-up: When the business metric needs a grain different from the view (customer lifetime total on an order-level sheet), use LOD or pre-aggregate in SQL.

Changing default aggregation (Sum → Average → Count) in the pill menu affects every calculation that references that field unless you wrap in SUM() explicitly in a calculated field.

A strong answer is:

Aggregations happen at the view's level of detail. SUM and AVG answer different questions, and I use LOD or SQL when the metric must be computed at a grain other than what is on the sheet.

Show Me recommends chart types based on fields you have selected—excellent for exploration and learning.

When to ignore it:

• Stakeholder requires a corporate standard (fixed chart types, brand palette)
• Performance — dual-axis combinations Show Me suggests may create too many marks
• Accessibility — table-first or simple bar beats flashy dual-axis for some audiences
• Analytical honesty — pie chart for 15 categories is rarely the right answer

Saying "I start with the business question, not Show Me's first suggestion" signals senior judgment.

A strong answer is:

Show Me is great for exploration, but I choose chart type from the question—trend, comparison, distribution—and override Show Me when standards, performance, or clarity demand a simpler mark.

The Data Source page is where the workbook's logical model is defined—errors here break every sheet downstream.

You configure:

• Connections — live database or extract (.hyper)
• Joins or relationships between tables (and cardinality)
• Data types, rename, default properties, geographic roles
• Extract filters — optional subset at refresh time (reduces size)

Interview focus: Wrong join type or many-to-many fan-out inflates measures. Interviewers ask how you diagnose row-count explosions before blaming a calculated field.

Fix grain at the source when possible; do not patch every sheet with LOD if the model is wrong.

A strong answer is:

On the Data Source page I set connections, relationships or joins, types, and extract scope. I validate grain and row counts there because join mistakes propagate to every dashboard.

Live queries the source on interaction; extract caches a snapshot as a local .hyper file Tableau queries instead.

Incremental extract appends new rows on refresh—common for fact tables with transaction dates.

Interview narrative: "I'd use live for a small operational report refreshed every minute; I'd use a nightly extract for a 500M-row sales model with 50 dashboard users."

A strong answer is:

Live when freshness and source performance are paramount; extract when I need speed, scale, or scheduled refresh. I mention incremental refresh for large growing fact tables.

Joins combine tables into one logical flat table at model time. Relationships in Tableau's logical data model keep tables separate and let Tableau join them at query time based on fields used in the view.

Modern interviews expect you to prefer relationships for multi-fact models when cardinality is defined correctly—and to explain when a deliberate join is still right (single denormalized export).

Caution: Relationships reduce fan-out risk, but they still require correct cardinality, referential integrity assumptions, and validation of totals against SQL or a trusted report. They are not a substitute for fixing a broken grain.

A strong answer is:

Joins merge tables upfront and can fan out if grain is wrong; relationships keep tables separate and join in context with correct cardinality. I still validate totals—relationships do not magically fix every modeling issue.

Data blending links two separate published or embedded data sources by bringing fields from a secondary source into the view on a common field—the secondary source shows an orange chain icon. Useful when linking fields vary sheet by sheet or when combining published sources that cannot be merged in one model.

Use when:

• Data cannot live in one database (CRM + warehouse)
• Quick cross-system analysis without a full ETL merge

Limitations:

• Blended fields behave differently in filters and aggregations
• Performance often worse than a single modeled source
• Harder to govern than one semantic model

Modern preference: Union or join in the warehouse / Prep, then one Tableau data source. Use blending intentionally, not as a default replacement for a governed model—only when integration is genuinely separate and temporary.

A strong answer is:

Blending connects two data sources on a common key when I cannot model them together. I prefer one warehouse model or relationships when possible; blending is a deliberate cross-system shortcut with known limits, not my default.

Fan-out happens when a one-to-many join duplicates parent rows—SUM(Sales) at order level becomes inflated after joining to line items.

Detect:

• Row count jumps after joining tables on the Data Source page
• Tableau totals disagree with a SQL audit or Excel pivot at the same grain
• Average or count metrics look "too high" with no other explanation

Fix:

• Aggregate to correct grain in SQL or Prep before Tableau
• Use relationships with correct cardinality instead of a bad join
• LOD only when the viz truly needs mixed grains—not as a permanent patch for a broken model

A strong answer is:

Fan-out duplicates parent rows on a one-to-many join and inflates sums. I compare row counts and audit totals against SQL, then fix grain in the model—not only with LOD band-aids.

Very—many loops include a SQL screen or expect you to fix grain in the warehouse. Tableau is the visualization layer; wrong grain is fastest fixed in SQL, Prep, or dbt—not with ten nested LOD calcs.

SQL skills interviewers test:

• JOIN, GROUP BY, HAVING, subqueries / CTEs
• Window functions for metrics Tableau struggles to express efficiently
• Writing a query that matches the business definition of a KPI

Practice: SQL technical interview questions.

A strong answer is:

SQL is essential—I model grain and complex metrics in the warehouse or custom SQL, use Tableau for visualization and interactivity, and can defend the same number in both SQL and a crosstab.

Tableau Prep is visual data preparation—pivot, split, clean, union flows with repeatable documentation.

Use Prep when:

• Source data is messy (CSV exports, inconsistent columns, bad types)
• You need auditable ETL business users can follow
• Cleaning in calculated fields would duplicate logic across workbooks

Output: Publish to .hyper or write back to a database table for Tableau Desktop / Server.

Scenario answer: "Finance sends a wide CSV each month—I use Prep to pivot, type-cast, and output a clean fact table instead of 40 workbook-specific calcs."

A strong answer is:

I use Prep for repeatable cleaning—pivot, split, union, type fixes—when the source is messy or logic should live outside every calculated field. I publish a clean output for dashboards to share.

A calculated field is a formula saved in the data model—reusable across sheets, like a computed column.

Row-level vs aggregate:

// Row-level (each row)
[Profit Ratio Row] = [Profit] / [Sales]

// Aggregate (computed at view grain)
[Profit Ratio] = SUM([Profit]) / SUM([Sales])

IF [Sales] > 10000 THEN "High" ELSE "Low" END

Distinguish from table calculations: Calculated fields run in the query pipeline (with aggregations as defined). Table calculations run after the query on the numbers already in the view.

Mixing them without understanding order of operations causes "wrong %" bugs in interviews.

A strong answer is:

Calculated fields are reusable formulas in the model—I use aggregate forms like SUM([Profit])/SUM([Sales]) at the view grain and separate them from table calcs that run after aggregation.

Level of Detail (LOD) expressions compute an aggregation at a granularity independent of the view layout—the most tested advanced Tableau topic in mid/senior loops.

Syntax:

{ FIXED | INCLUDE | EXCLUDE [dimension list] : AGG(measure) }

Use LOD when the business question needs a metric at customer, order, or region grain while the sheet shows product or day detail.

A strong answer is:

LOD expressions aggregate at a defined grain independent of the viz—FIXED, INCLUDE, or EXCLUDE—when I need customer-level or region-level metrics on a more detailed sheet.

FIXED computes at the dimensions you list, ignoring the view's Rows/Columns (except context filters and data source filters).

Customer lifetime sales:

{ FIXED [Customer ID] : SUM([Sales]) }

Percent of customer total on an order-level sheet:

SUM([Sales]) / { FIXED [Customer ID] : SUM([Sales]) }

Each order row shows that order's sales divided by that customer's total sales—impossible with only view-level SUM without duplicating grain.

Interview tip: Mention context filter if FIXED must respect a subset (e.g., only 2024 orders).

A strong answer is:

FIXED aggregates at the dimensions I specify, ignoring the view layout. I use it for customer-level totals on order-level sheets, and I add a context filter when FIXED must respect a subset.

INCLUDE — adds dimensions to the LOD grain beyond what the view already has:

{ INCLUDE [Product] : AVG([Sales]) }

Useful when the view is at Region but you need product-level average inside that context.

EXCLUDE — removes a dimension from the view grain for the calculation:

{ EXCLUDE [Category] : SUM([Sales]) }

On a sheet with Region and Category, EXCLUDE Category gives region subtotal sales on each category row—handy for % of region comparisons.

Mnemonic: INCLUDE adds granularity; EXCLUDE rolls up past a dimension still on the viz.

A strong answer is:

INCLUDE adds dimensions to the LOD grain beyond the view; EXCLUDE removes a dimension from the calculation grain. I use EXCLUDE for region totals on a category breakdown sheet.

Rule of thumb: Need metric at defined grain regardless of sheet layout → LOD. Need running sum, rank in pane, or difference from previous row in the visible table → table calc.

Push repeated LOD to SQL when workbooks slow down.

A strong answer is:

LOD for metrics at a business grain independent of the sheet; table calcs for running totals, rank, and percent of what is already in the view. I push heavy LOD to SQL when performance suffers.

Table calculations operate on the numbers already aggregated in the view.

Common patterns:

RUNNING_SUM(SUM([Sales]))
RANK(SUM([Sales]))
LOOKUP(SUM([Sales]), -1)          // prior period in table
WINDOW_AVG(SUM([Sales]))
SUM([Sales]) / TOTAL(SUM([Sales])) // % of total (with compute using)

Compute using — defines partition (table, pane, cell, specific dimensions). Wrong setting is the #1 "table calc looks wrong" bug.

Interview debug: Open Edit Table Calculation → verify Compute using matches the business question (e.g., across months within each region).

A strong answer is:

I use table calcs for running sums, rank, LOOKUP for prior period, and percent of total—and I always set compute using to match whether the metric is table-wide or per pane.

The order of operations explains why a filter "does not affect" an LOD or why a table calc behaves unexpectedly.

Simplified pipeline:

1. Extract / data source filters
2. Context filters (if any)
3. FIXED LOD (and other LOD types in their positions)
4. Dimension filters on the view
5. Measure filters
6. Table calculations computed
7. Table calc filters

Context filter: Promotes a dimension filter to run before FIXED LOD—use when FIXED must respect a scoped subset (e.g., active customers only). Tableau applies FIXED LOD before normal dimension filters unless that filter is promoted to context.

INCLUDE and EXCLUDE behave differently from FIXED in the order of operations—do not assume every LOD ignores normal dimension filters the same way.

Drawing this pipeline on a whiteboard is a strong senior signal.

A strong answer is:

I remember data source and context filters run before FIXED LOD, dimension filters after, then table calcs. INCLUDE and EXCLUDE are not interchangeable with FIXED on filter order—I use a context filter when FIXED must honor a subset of the data.

At product grain in the view, COUNTD([Customer ID]) counts distinct customers per product row—not "customers per region."

FIXED LOD for region-level distinct count on any sheet:

{ FIXED [Region] : COUNTD([Customer ID]) }

Shows every row in that region the same regional customer count—correct for comparing to product sales at detail grain.

This is a classic grain interview question—tie to SQL COUNT(DISTINCT) at GROUP BY region.

A strong answer is:

COUNTD at the view grain is not always the business distinct count. I use { FIXED [Region] : COUNTD([Customer ID]) } when I need customers per region on a more detailed sheet.

Filters remove data at different stages—using the wrong type is a top cause of "the number looks off."

Symptom: FIXED LOD ignores a normal dimension filter → promote to context or bake filter into LOD logic.

A strong answer is:

I match filter type to the pipeline—data source for scope, context before FIXED LOD, dimension vs measure for row vs aggregate cuts, and table calc filters only after table calcs.

Parameters are single values (or lists) the user controls—thresholds, selected measure, date anchor. They do not filter data by themselves.

Wired into logic:

[Sales] > [Sales Threshold Parameter]

CASE [Metric Parameter]
  WHEN "Profit" THEN SUM([Profit])
  WHEN "Sales" THEN SUM([Sales])
END

Parameter actions pass clicked values into parameters for advanced interactivity.

A strong answer is:

Filters subset data; parameters are user inputs I reference in calculated fields or parameter actions—they do not filter until I wire them into logic.

Dashboard actions connect sheets—core skill for take-home exercises.

Scenario: "Drill from country map to city table" — filter action on shared geography field; optional highlight for context.

Test actions on published Server behavior—not only Desktop.

A strong answer is:

I use filter actions for drill-down, parameter and set actions for advanced logic, and URL actions for deep links—I test the full action chain on the published dashboard.

A set is a dynamic or static subset of dimension members—top customers, selected regions, above-target products.

Types:

• Fixed set — manually chosen members
• Computed set — rule-based (top N by sales)
• Combined sets — union / intersect for cohort logic

Set actions let users click marks to add/remove members—powerful for ad hoc cohort analysis without new filters for every question.

A strong answer is:

Sets define member subsets—fixed, computed, or combined—and I pair them with set actions so users build cohorts by clicking the viz.

Dual axis overlays two measures—often bar + line or two lines with independent scales.

Good use: Related metrics with aligned interpretation (sales bars + profit line) with synchronized or clearly labeled axes.

Risks:

• Misleading scale — one axis compressed makes trends look correlated
• Chart junk — dual axis as default decoration
• Accessibility — harder to read than small multiples

Prefer shared axis or separate panels when honesty beats flash.

A strong answer is:

Dual axis when two related measures need overlay and axes are labeled honestly; I avoid it when small multiples or a single axis tells a clearer story.

Start with the analytical question, not the default bar chart.

Tableau interviews ask you to defend the choice: "Why not a pie? Why sorted descending? Why log axis?"

A strong answer is:

I map the business question to chart type—trend line, compare bar, distribution histogram, relationship scatter—and I defend sorting, color, and why I avoided misleading dual axis or pie charts.

A good dashboard answers one primary question per view (or clear tabs)—stakeholders should not hunt for the KPI.

Practices:

• F-pattern layout — KPIs top-left, filters left or top
• Consistent color — one accent for emphasis; colorblind-safe palettes
• Tooltips with context (comparison, definition)—not every column exported
• Device designer or responsive layout for mobile executives
• Performance — limit sheet count, mark count, high-cardinality quick filters

Decoration without decision support fails in enterprise reviews.

A strong answer is:

One clear question per dashboard, KPIs where eyes land first, consistent accessible color, purposeful tooltips, and performance discipline—I optimize for decisions, not decoration.

Maps require geographic roles and awareness of aggregation on maps.

Essentials:

• Assign Country / State / City geographic roles to dimensions
• Built-in geocoding vs custom spatial (PostGIS, shapefiles) for custom regions
• Map layers for context (streets, boundaries)

Traps:

• Null geocoding — unknown cities drop or pile in wrong place
• SUM vs AVG on map — are you showing total sales or average per store?
• Density vs filled map for skewed distributions

A strong answer is:

I assign geographic roles, validate geocoding errors, and choose map type and aggregation—sum vs average vs density—to match whether I am showing volume or intensity.

Interview: Story for quarterly business review walkthrough; Dashboard for daily sales monitoring with filters.

A strong answer is:

Dashboard for interactive monitoring and exploration; Story for a guided narrative when I present insights in a fixed sequence to executives.

Tooltips are micro-copy—they should answer "so what?" on hover, not dump the database.

Guidelines:

• Show label + 2–4 metrics with business names
• Use calculated fields for % change or vs target in tooltip
• Viz in Tooltip sparingly—each nested viz is a performance cost
• Hide internal field codes stakeholders should not see

Skills tests often ask for a custom tooltip with conditional text.

A strong answer is:

I keep tooltips short with business language and key comparisons, use calculated fields for context, and add Viz in Tooltip only when the insight justifies the performance cost.

Diagnose before guessing—Performance Recorder first, then targeted fixes.

Checklist:

1. Reduce marks — filter early; fewer dimensions on detail; aggregate in database
2. Extract or materialized view when live queries repeat heavy SQL
3. Limit LOD nesting; move logic to custom SQL / dbt model
4. Hide unused fields; narrow joins; fix fan-out at source
5. Simplify dashboards — fewer sheets; avoid high-cardinality quick filters on millions of rows
6. Review filters — context only when needed; date filters on indexed columns in DB
7. Run Workbook Optimizer before publishing to catch common design issues against performance best-practice rules

Say aloud: measure, then fix the longest query or sheet—not "add another calculated field."

A strong answer is:

I run Performance Recorder, fix the slowest query or sheet first—usually marks count, bad joins, or LOD—and run Workbook Optimizer before publish to catch design issues I might miss from timing alone.

Workbook Optimizer and Performance Recorder solve different problems—use both, but do not blindly apply every optimizer suggestion.

Workbook Optimizer might flag unused fields, inefficient filters, or chart choices that violate guidelines. Performance Recorder shows whether a specific sheet triggers a 40-second warehouse query on filter change.

Interview nuance: Optimizer rules are heuristics—a flagged sheet may be fine for your audience; Recorder proves whether users actually wait. Start with Recorder for user-reported slowness; run Optimizer as a pre-publish hygiene pass.

A strong answer is:

Workbook Optimizer is metadata-based best-practice checks before publish; Performance Recorder measures real query and render time during interaction. I use both, but I validate optimizer flags against actual Recorder results—not every rule applies to every workbook.

Performance Recorder (Desktop / Server) logs query time, layout, and rendering per sheet while you interact.

Use it to find:

• Warehouse queries taking 30+ seconds
• Expensive filters on high-cardinality fields
• Sheets that dominate dashboard load time

Senior developers cite measurement before optimization—strong interview signal.

Workflow: Record → reproduce slowness → read timeline → refactor worst offender → re-record. Pair with Workbook Optimizer before publish for metadata checks Recorder does not cover.

A strong answer is:

Performance Recorder shows query, layout, and render time per sheet. I reproduce the slow path, read the timeline, and refactor the biggest bottleneck—then run Workbook Optimizer before publish for design issues timing alone might miss.

A published data source lives on Tableau Server or Cloud as a shared, governed asset; an embedded data source is packaged inside one workbook.

Production preference: Publish a certified data source with documented grain and refresh; connect workbooks to it rather than embedding duplicate extracts.

Embedded is fine for exploration—migrate to published when stakeholders depend on the metrics.

A strong answer is:

Published sources are governed and reusable across workbooks; embedded sources stay inside one workbook for speed in prototypes. In production I publish and certify the model, then connect dashboards to that source.

Full refresh rebuilds the entire extract; incremental refresh appends or updates only new or changed rows since the last run.

Rule of thumb: Nightly full refresh for a 2M-row mart; incremental for a 500M-row fact where only yesterday's partition changes.

A strong answer is:

Full refresh rebuilds everything—simple and safe for smaller data or schema changes. Incremental refresh suits large append-only facts with a trusted watermark column; I validate the key and catch-up logic before relying on it in production.

Publishing moves workbooks and data sources to a governed server environment—not only "save to cloud."

You get:

• Projects and folder permissions
• Schedules for extract refresh (failure alerts matter)
• Permissions at project, workbook, data source level
• Certification and promoted data sources in mature orgs
• Usage metrics for adoption tracking

Developer vs admin: Know whether you own refresh failures, permission errors, or escalate to Server admin.

A strong answer is:

Publishing puts workbooks and data sources on Server or Cloud with schedules, permissions, and governance—I know how refresh and access errors surface for users.

Row-level security restricts which rows each user sees—regional managers see only their region, for example.

Common approaches:

// User filter example
[Region] = USERNAME()

// Or group-based
ISMEMBEROF('West Region Group')

Entitlement table pattern: Join a user_entitlements table mapping username → allowed regions—scales better than hard-coding hundreds of users.

Enterprise interviews test multi-tenant awareness—know how you validate RLS before go-live (see testing scenario below).

A strong answer is:

RLS limits rows per user via USERNAME(), ISMEMBEROF(), or an entitlement join. I design with an entitlement table at scale and plan explicit testing before production—not only at publish time.

RLS bugs are high severity—a regional manager seeing another region's revenue is a data breach. Test deliberately, not only with your own admin account.

Testing checklist:

Common miss: RLS works on Server but breaks when someone downloads a full extract locally—confirm download permissions align with policy.

A strong answer is:

I test with dedicated users or impersonation per role, audit the entitlement mapping in SQL, run negative cases, and verify exports—not just my own admin session.

A practical enterprise scenario—interviewers want calm triage and stakeholder communication, not panic.

Immediate steps:

1. Check refresh history / error message on Server—credential failure, timeout, or source error?
2. Source-side causes — password expired, VPN/firewall, schema change (renamed column, dropped table), warehouse outage
3. Communicate — tell stakeholders the dashboard may be stale with last successful refresh time; do not imply live data if extract is down
4. Rerun refresh after fixing credentials or SQL; watch for partial success
5. Fallback — prior-day export, backup workbook, or a simplified live view if SLA allows
6. After incident — alerting on failed schedules, runbook for on-call, document root cause

Senior signal: You own the refresh schedule and credentials for workbooks you publish—or you know exactly who does.

A strong answer is:

I check Server refresh history for the error, fix credentials or schema issues at the source, tell stakeholders the data is stale with last good refresh time, rerun the job, and add alerting so the next failure is not a surprise.

Tableau Certified Data Analyst and Server certifications help resume screens and prove baseline breadth—they do not replace live scenarios.

Interviews still test:

• Explaining why a LOD is FIXED vs INCLUDE
• Debugging metric vs Excel discrepancies
• Portfolio dashboards with narration

Mention certification if you have it; spend prep time on scenarios and grain, not button trivia.

A strong answer is:

Certification helps credibility, but interviews focus on scenarios, LOD, and explaining my workbook—I lead with portfolio and problem-solving, not cert trivia.

Treat it as a collaborative audit, not a debate—stakeholders usually have a partial filter or different grain.

Debug steps:

1. Align filters — date range, region, product, active flag
2. Match grain — Excel pivot rows vs Tableau crosstab dimensions
3. Check join fan-out or blend duplication
4. Live vs extract — stale refresh?
5. NULL handling — excluded rows in one tool?
6. Reproduce in crosstab with identical dimensions; export both sides
7. Document root cause — fix model or definition, update data dictionary

Favorite practical scenario in practitioner communities—shows maturity.

A strong answer is:

I align filters and grain, rebuild the number in a crosstab matching Excel, check joins and refresh, then fix the model or metric definition and document it—without dismissing the stakeholder.

YoY compares the same period in the prior year—not the previous row (which might be last month).

Table calculation approach (monthly grain, compute using on date):

(SUM([Sales]) - LOOKUP(SUM([Sales]), -12))
/ LOOKUP(SUM([Sales]), -12)

-12 assumes monthly rows—adjust offset for weekly or quarterly grain.

Alternatives:

• LOD with DATEPART('year', [Order Date]) for explicit prior-year join
• Custom SQL with window LAG for heavy models

Clarify: December vs prior December—not November. Filter context affects which months appear.

A strong answer is:

I clarify calendar YoY vs prior row, use LOOKUP with the right offset for the time grain or LOD/SQL for prior year, and verify December compares to last December—not November.

Use STAR with metric impact—Tableau hires for outcomes, not sheet count.

Structure:

• Situation — conflicting KPIs in spreadsheets; leadership lacked one view
• Task — trusted dashboard for weekly revenue and churn drivers
• Action — modeled grain in SQL, FIXED LOD for customer metrics, user testing with ops team
• Result — faster decisions, fewer ad hoc report tickets, measurable time saved

Bring a portfolio link or screenshots and a 2-minute walkthrough script.

A strong answer is:

I tell a STAR story with a clear business problem, how I fixed grain and LOD in the model, and a measurable result—fewer report requests or a decision that changed—not just that I built ten sheets.

Technical drills:

• Write FIXED, INCLUDE, EXCLUDE examples from memory
• Draw order of operations on paper (context → LOD → filters → table calcs)
• Explain live vs extract, full vs incremental refresh, relationships vs join fan-out
• Contrast published vs embedded data sources and when to certify
• Build one dashboard with parameter + filter action
• Run Performance Recorder on a slow sheet and Workbook Optimizer before publish

Cross-skill:

• Refresh SQL joins: SQL technical guide
• 3 scenario stories — metric discrepancy, deadline, vague requirements
• Portfolio link + 2-minute walkthrough script

Optional depth: data science interview questions for stats/A/B; Interview Questions category.

A strong answer is:

In the final week I drill LOD and order of operations, practice one performance debug aloud, polish portfolio with a short narrative, and rehearse three stakeholder scenarios including metric mismatch.