← Amazon Interview Insights

Amazon·Data Scientist·Technical Phone Screen·Senior

Senior
Jul 2026

Summary

Amazon Data Scientist interview with a Tableau-heavy technical round. Three questions, all centered on dashboard design, filter mechanics, and data viz principles. Felt more like a BI engineering interview than a data science one, which threw me off a bit.

Questions Asked (3)

Q1

What are the key differences between a JOIN, a BLEND, and a RELATIONSHIP in Tableau, and when would you use each?

Data ModelingTechnical Trade-offs
Author's notes

I knew joins cold but blends tripped me up a little.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining each concept clearly, emphasizing that JOINs operate at the data source level to combine tables, BLENDs combine data from different sources at the worksheet level, and RELATIONSHIPs are the modern logical layer that defers joins to the query level. Then, discuss when to use each based on data granularity, performance, and data source constraints, highlighting trade-offs. Finally, relate it to a data science context, such as preparing data for modeling or analysis.

Pro tip: Mention that relationships are the preferred approach in Tableau 2020.2+ because they avoid data duplication and preserve native granularity, but be prepared to explain scenarios where blending or joins are still necessary, such as when using legacy workbooks or needing cross-database joins.

1. Define JOIN

Explain that a JOIN is a physical combination of tables at the data source level, using SQL-like operations (inner, left, right, full outer) that merge rows based on matching keys, resulting in a new flattened table.

2. Define BLEND

Describe BLEND as a method to combine data from multiple sources at the worksheet level, where only matching rows are linked based on a common dimension, and non-matching rows are handled separately, often leading to limited analysis.

3. Define RELATIONSHIP

Explain that a RELATIONSHIP is a logical association between tables that does not merge them physically; instead, it defers the join to the query level, preserving the granularity of each table and allowing for context-aware joins.

4. Compare and contrast

Highlight key differences: JOINs are physical and static, BLENDs are worksheet-level and limited, RELATIONSHIPs are logical and dynamic. Discuss performance implications, data duplication, and flexibility.

5. When to use each

Provide guidance: Use JOINs when you need a single flattened table for complex transformations or when working with legacy data sources. Use BLENDs when combining data from different sources without a common join key or when you need to compare measures. Use RELATIONSHIPs for most modern analytics to maintain granularity and optimize performance.

Key Points to Mention

  • JOINs are processed at the data source level and create a new table, which can lead to data duplication and affect performance.
  • BLENDs are limited to worksheet-level and only combine data from different sources; they do not support full outer joins and can result in missing data.
  • RELATIONSHIPs are the default in Tableau 2020.2+ and allow for logical data modeling without physical merging, preserving granularity.
  • Relationships enable context-aware joins, meaning the join type is determined at query time based on the dimensions and measures used.
  • Use JOINs when you need to perform row-level operations or when data sources are already in the same database.
  • Use BLENDs when you need to combine data from different sources without a common join key, but be aware of limitations.
  • Use RELATIONSHIPs for most analytical scenarios to avoid data duplication and improve performance.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Tableau has six filter types applied in a specific order of operations. Can you walk through that order and describe a real scenario where using the wrong filter level produces incorrect results?

Product Analytics & MetricsTechnical Trade-offs
Author's notes

This is where I actually felt good.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clearly stating the six filter types in Tableau's order of operations: Extract, Data Source, Context, Dimension, Measure, and Table Calculation. Then, walk through a concrete scenario where applying a filter at the wrong level (e.g., dimension filter instead of context filter) leads to incorrect results, such as excluding data that should be included in a percentage calculation. Emphasize how understanding this order prevents misleading insights and ensures accurate analytics.

Pro tip: Mention that context filters create a temporary table that subsequent filters operate on, which can improve performance but also change results if misused. Relate this to Amazon's leadership principle of 'Insist on the Highest Standards' by highlighting how precise filter placement ensures data integrity.

1. List the filter order

State the six filter types in the correct sequence: Extract, Data Source, Context, Dimension, Measure, and Table Calculation. Briefly explain that each subsequent filter operates on the data after previous filters are applied.

2. Explain the impact of each filter level

Describe how each filter type affects the data: Extract filters reduce data at the source, Data Source filters apply to the connection, Context filters create a subset for subsequent filters, Dimension filters exclude dimension members, Measure filters exclude aggregated values, and Table Calculation filters apply after calculations.

3. Present a real scenario

Choose a scenario where using a dimension filter instead of a context filter yields incorrect results. For example, calculating the percentage of sales from a specific region: if you filter out other regions with a dimension filter, the denominator for the percentage becomes the filtered total, not the overall total, skewing the result.

4. Analyze the incorrect outcome

Explain why the wrong filter level produces incorrect results: the dimension filter removes data before the percentage calculation, so the calculation is based on a subset. The correct approach is to use a context filter to include all regions in the denominator, then apply a dimension filter to display only the region of interest.

5. Conclude with best practices

Summarize how to avoid such errors: always consider the order of operations when designing dashboards, use context filters when you need a subset for calculations, and test filter combinations to ensure accuracy.

Key Points to Mention

  • The six filter types in order: Extract, Data Source, Context, Dimension, Measure, Table Calculation.
  • Context filters create a temporary table that subsequent filters use, affecting calculations like percentages.
  • Dimension filters exclude data before calculations, which can change denominators in aggregate calculations.
  • Measure filters operate on aggregated values and can exclude marks based on thresholds.
  • Table calculation filters apply after calculations, so they don't affect the underlying data used in the calculation.
  • Real-world example: calculating regional sales percentage without context filter leads to inflated percentages because the denominator is filtered.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

A stakeholder wants to use a pie chart to display 12 product categories. What would you recommend instead and why?

Stakeholder ManagementProduct Sense & Ideation
Author's notes

Pretty standard dataviz question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Acknowledge the stakeholder's goal of comparing category shares, then explain why a pie chart fails with 12 slices (visual clutter, hard to compare angles). Recommend a horizontal bar chart sorted by value, which makes ranking and comparison effortless, and offer to prototype it quickly to align with the stakeholder.

Pro tip: Frame the recommendation around the stakeholder's decision-making needs—e.g., 'This will help you quickly see which categories dominate and which are lagging'—rather than just criticizing pie charts. This shows you're a partner, not just a chart critic.

1. Clarify the goal

Ask what decision the stakeholder wants to make with this chart—e.g., identify top categories, compare shares, or spot trends. This ensures your recommendation serves their actual need.

2. Explain the limitation

Politely point out that pie charts become ineffective beyond 5-7 slices because humans struggle to compare angles and similar-sized slices become indistinguishable.

3. Recommend an alternative

Suggest a horizontal bar chart sorted descending by value, which makes ranking and relative comparison immediate and accurate.

4. Highlight benefits

Emphasize that the bar chart allows easy labeling, handles long category names, and scales well if more categories are added later.

5. Offer to iterate

Propose to create a quick mock-up and review it with the stakeholder to ensure it meets their needs, showing flexibility and collaboration.

Key Points to Mention

  • Pie charts are poor for more than 5-7 categories due to angle comparison difficulty.
  • Horizontal bar charts sorted by value enable quick ranking and comparison.
  • Bar charts accommodate long category labels and additional categories without clutter.
  • Stakeholder's decision context should drive visualization choice.
  • Offer to prototype and iterate to build alignment.
  • Mention that if part-to-whole is critical, a stacked bar or treemap could be alternatives, but bar chart is usually best for ranking.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.