American Express Data Analyst

Interview Questions
(0-3 Years)
17-19 lpa
Power BI Questions

1. Difference between calculated column and measure in

Power BI (Power BI / DAX Concepts):
Problem:
In Power BI, both calculated columns and measures are used to create new data using DAX
expressions. But what are the key differences and when to use which?
Solution:
1. Calculated Column:
o Adds a new column to the table.
o Evaluated row by row in the context of that table.
o Stored in memory and increases the data model size.
o Example use: Creating a column Profit = Sales - Cost.
2. Measure:
o Calculates values dynamically based on filter context.
o Doesn’t add new columns but returns a scalar value.
o Computed on the fly, thus more memory-efficient.
o Example use: Total Sales = SUM(Sales[Amount]).
3. When to use:
o Use calculated columns when you need the new data at row level.
o Use measures when you need to aggregate or compute values on visuals.

-- Calculated Column
Profit = Sales[Revenue] - Sales[Cost]

-- Measure
Total Revenue = SUM(Sales[Revenue])
2. How do you handle missing or null values in
Power BI (Power BI / Data Preparation)
Problem:
As a Data Analyst, you often encounter datasets with missing or null values. Power BI needs
clean, complete data for accurate reporting. How can you identify and address these gaps
during your ETL process?

Solution:
1. Identify Missing Values in Power Query:
o In Power Query Editor, use the “Keep Rows” → “Remove Empty” or “Remove
Rows” → “Remove Blank Rows” options on a column to see which records are null.
o Alternatively, add a custom column with a formula like:

if [SalesAmount] = null then "Missing" else "OK"

2. Replace or Fill Values:

o Replace Values: Select the column, go to Transform → Replace Values, and
replace null with a constant (e.g., 0) or a placeholder (e.g., "Unknown").
o Fill Down/Up: For ordered data where the previous or next value makes sense, use
Transform → Fill → Down (or Up) to propagate non-null values into null cells.

3. Remove Rows with Nulls:

o If certain nulls are unacceptable (e.g., missing primary keys), use Home → Remove
Rows → Remove Blank Rows to drop those records entirely.

4. Leverage DAX for Conditional Handling:

o In cases where you want to handle nulls on the fly in measures, use DAX functions like
IF, BLANK(), and COALESCE:

CleanedSales = COALESCE(SUM(Sales[Amount]), 0)
5. Document Your Steps:
o Always annotate your applied steps in Power Query so downstream users understand
how nulls were addressed.
o Use the Advanced Editor to view or share the M code, ensuring transparency in your
ETL logic.

By proactively detecting and treating missing data in Power Query and, where needed, in DAX,
you ensure your visuals and analyses remain reliable and accurate.
3. Compare Import Mode, DirectQuery, and Composite Models
in Power BI (Power BI / Data Connectivity & Modeling)
Problem:
As a Data Analyst, you need to connect Power BI to different data sources and decide how data
should be accessed—either loaded into Power BI’s in-memory model or queried live. What are the
strengths and trade-offs of each mode?

Solution:
1. Import Mode
o How it works: Data is fully loaded into Power BI’s in-memory VertiPaq engine.
o Pros:
▪ Fast query performance and interactive visuals.
▪ Full DAX functionality, including all time-intelligence functions.
▪ Ability to work offline once the dataset is imported.
o Cons:
▪ Dataset size limited by Power BI Premium or Pro capacity (~1 GB for Pro).
▪ Requires scheduled refreshes to stay up to date (e.g., every 30 minutes for Pro).
2. DirectQuery Mode
o How it works: Queries are sent live to the underlying data source (SQL Server, Azure
Synapse, etc.) at run time.
o Pros:
▪ Always shows real-time or near-real-time data.
▪ No data size limits in Power BI model.
o Cons:
▪ Performance depends on source system; may see slower visuals.
▪ Limited DAX functionality and some modeling features disabled.
▪ Query throttling and timeouts if the source is under heavy load.
3. Composite Models
o How it works: Combines Import and DirectQuery in a single model. You can choose
for each table whether to import or query live.
o Pros:
▪ Flexibility: cache frequently used lookup/dimension tables in memory, and keep
very large fact tables in DirectQuery.
▪ Can define relationships between imported and live tables.
o Cons:
▪ Adds complexity to the model.
▪ Potential for mixed performance characteristics—some visuals fast, others
slower.
▪ Requires careful consideration of security and data freshness.
Example Scenario:
You build a sales report where product and calendar tables are imported for speed, but a huge
transactions table remains DirectQuery so you always see the latest orders.
4. Explain the CALCULATE Function and Context
Modification in DAX (Power BI / Advanced DAX)
Problem:
You need to build dynamic measures that apply different filters on the fly—such as
calculating sales for a specific region or period—so you must understand how CALCULATE
modifies filter and row contexts in DAX.

Solution:
1. Purpose of CALCULATE:
o Transitions DAX from row context to filter context (or modifies an existing filter
context).
o Applies one or more filter expressions to the data before evaluation.
2. Basic Syntax:

CALCULATE( <expression>, <filter1>, <filter2>, … )

o <expression>: any scalar DAX expression or existing measure (e.g., [Total Sales]).
o <filter>: Boolean expressions, table filters, or FILTER functions that adjust what
rows are visible.
3. How Filters Are Applied:
o Direct filters (e.g., Sales[Region] = "North") override any existing filters on that
column.
o FILTER(table, condition) lets you define row-by-row logic, often used with ALL
or ALLSELECTED to remove or ignore existing filters on the table.
4. Examples:
-- 1. Simple region filter:
Sales_North =
CALCULATE(
[Total Sales],
Sales[Region] = "North America"
)

-- 2. Year-to-date using FILTER + ALL:

Sales_YTD =
CALCULATE(
[Total Sales],
FILTER(
ALL(Calendar),
Calendar[Date] <= MAX(Calendar[Date])
)
)

-- 3. Combining multiple filters:

Sales_North_2025 =
CALCULATE(
[Total Sales],
Sales[Region] = "North America",
Calendar[Year] = 2025
 )
5. Key Considerations:
o Filter precedence: Direct column filters inside CALCULATE will override
equivalent filters already active; FILTER tables are applied afterward.
o Performance: Excessive use of row-by-row FILTER can slow down measures;
wherever possible, use direct filters or pre-filter with ALL/VALUES.
o Context transition: When used inside a calculated column or iterator (like
SUMX), CALCULATE triggers context transition, giving you the full filter context for
proper aggregations.
5. What is Query Folding and why is it important in Power BI
(Power BI / Performance Optimization)
Problem:
When working with large datasets, transformations in Power Query can become slow and
resource-intensive if each step processes all rows locally. How can you ensure that data shaping
operations are pushed down to the data source for better performance?

Solution:
1. Definition of Query Folding:
o Query folding is when Power Query translates your applied transformations (filters,
joins, aggregations) into native queries (e.g., SQL) that run on the source system,
rather than in Power BI’s local engine.
2. Benefits:
o Performance: Leverages the source database’s compute power.
o Reduced Data Movement: Only the necessary subset of data is retrieved.
o Scalability: Handles much larger datasets efficiently.
3. How to Check for Query Folding:
o In Power Query Editor, right-click on a step in the Applied Steps pane and select
View Native Query. If the option is greyed out, that step isn’t being folded.
4. Best Practices to Maximize Folding:
o Apply Filters and Joins Early: Place steps like Filter Rows or Merge Queries as early
as possible in the query sequence.
o Avoid Breaking Folding: Steps such as adding index columns, invoking custom
functions, or using certain M transforms (e.g., Table.Buffer) can prevent folding from
continuing.
o Use Native Database Objects: When possible, point to views or stored procedures
that encapsulate complex logic on the server side.
5. Example:
Suppose you connect to a SQL Server table Sales. In Power Query, apply:

Source = Sql.Database("MyServer", "MyDB"),

SalesTable = Source{[Schema="dbo",Item="Sales"]}[Data],
FilteredRows = Table.SelectRows(SalesTable, each [OrderDate] >= #date(2025,1,1)),
Grouped = Table.Group(FilteredRows, {"Region"}, {{"TotalSales", each List.Sum([Amount]), type
number}})
o Both the date filter and the grouping will be folded into a single SQL statement:

SELECT Region, SUM(Amount) AS TotalSales

FROM dbo.Sales
WHERE OrderDate >= '2025-01-01'
GROUP BY Region;
o This pushes computation to SQL Server rather than importing all rows then filtering and
grouping locally.
6. What is the difference between a slicer and a
filter in Power BI? (Power BI / Report Design)

Problem:
You're designing a Power BI dashboard and need to let users filter data—but should you use a
slicer or a report/page/visual filter?
Solution:
1. Slicer:
o A visual element placed on the report canvas.
o Allows users to interactively filter data based on a field (e.g., Region, Year).
o Supports dropdowns, lists, date pickers, hierarchical filters.
2. Filter Pane:
o Set by the report creator.
o Can be applied at:
▪ Visual level: affects only one visual.
▪ Page level: affects all visuals on a page.
▪ Report level: affects all pages and visuals.
o Not visible to end users unless explicitly allowed.
3. When to use what:
o Use slicers when you want users to control filtering directly.
o Use filters when you want report creators to control what data is shown (or hidden).
Example:
You add a slicer for “Year” so users can select 2023 or 2024. But you use a page filter to limit the
page to only the “North America” region.
7. How do you create a relationship between tables
in Power BI? (Power BI / Data Modeling – Easy)
Problem:
Your data is spread across multiple tables (e.g., Sales, Products, Customers). How do you connect
them so visuals work correctly?
Solution:
1. Go to Model View in Power BI Desktop.
2. Drag and drop the key field (e.g., ProductID) from one table onto the matching key in the
other.
3. Power BI creates a relationship:
o One-to-Many or Many-to-One.
o Cross-filter direction (Single or Both).
4. You can also manually define:
o Relationship type.
o Whether it's active or inactive.
o Cardinality and filtering behavior.
Best Practice:
Build a star schema—with dimension tables (Products, Customers) around a central fact table
(Sales)—to keep your model clean and optimized.

1. For each index i in the string, expand around:

o One center: both left and right pointers start at i (odd-length palindromes).
o Two centers: left = i, right = i+1 (even-length palindromes).
2. Define a helper to expand and return the longest palindrome around the given left/right.
3. Update the global maximum substring when a longer palindrome is found
8. What is a KPI visual and how do you use it? (Power BI /
Visualization)
Problem:
Your manager wants a clear visual that shows whether current sales are ahead or behind target.
Which Power BI visual should you use?
Solution:
1. Use the KPI visual (Key Performance Indicator).
2. It needs three values:
o Indicator: main metric (e.g., SUM(Sales[Amount]))
o Trend axis: time-based field (e.g., Date)
o Target goal: value to compare against (e.g., Sales Target measure)
3. The visual will:
o Show current value.
o Compare against target.
o Display color-coded arrows and trends.
Example:

Sales Target = 500000

If the current month’s total sales is 480000, the KPI visual will show a red down arrow.
9. What is the difference between ALL, ALLEXCEPT, and
ALLSELECTED in DAX? (Power BI / Context Management)

Problem:
You need to override, preserve, or modify filters in your DAX measures. How do you choose
between ALL, ALLEXCEPT, and ALLSELECTED?
Solution:
1. ALL:
o Removes all filters from a column or table.
o Often used to calculate totals for percent of total or rank.

All Sales = CALCULATE([Total Sales], ALL(Sales))

2. ALLEXCEPT:
o Removes all filters except the ones specified.

Sales by Region = CALCULATE([Total Sales], ALLEXCEPT(Sales, Sales[Region]))

3. ALLSELECTED:
o Removes filters applied inside visuals, but preserves slicer and page filters.

Sales % of Selected =
DIVIDE([Total Sales], CALCULATE([Total Sales], ALLSELECTED(Sales)))

When to use:
• ALL: for grand totals or ignoring all filters.
• ALLEXCEPT: to compare sub-totals (e.g., all products within a region).
• ALLSELECTED: when you want a % of filtered set (from slicers).
10. How do you optimize performance in
Power BI reports? (Power BI / Optimization
Techniques)
Problem:
Your Power BI report is slow to load or refresh. What can you do to improve performance?
Solution:
Reduce Columns and Rows:
• Remove unused columns and limit rows during query (filter in Power Query).
Disable Auto Date/Time:
• Turn off “Auto Date/Time” in Options to avoid hidden date tables.
Avoid complex measures in visuals:
• Pre-calculate results using summary tables or intermediate measures.
Use Aggregated Tables:
• Import pre-aggregated data (monthly sales instead of raw transactions).
Reduce Visual Count:
• Keep visuals to under 8 per page; avoid excessive slicers and cards.
Use Variables in DAX:

VAR Total = SUM(Sales[Amount])

RETURN IF(Total > 100000, "High", "Low")
Query Folding & Scheduled Refresh:
• Make sure Power Query steps fold back to the source.
• Set refresh at off-peak hours.

11. What is a star schema and why is it preferred in Power BI?

(Power BI / Data Modeling)

Problem:
You have multiple tables—some large, some descriptive. How do you organize them for efficient
modeling and querying?

Solution:
1. Star Schema Structure:
o Central fact table (e.g., Sales, Orders) with keys.
o Surrounding dimension tables (e.g., Product, Region, Customer).
2. Why preferred:
o Easier to understand and maintain.
o Optimized for performance and DAX calculations.
o Enables clear relationship paths (one-to-many).
o Works well with Power BI’s VertiPaq engine.
3. Best Practices:
o Avoid snowflake schema (too many joins).
o Flatten hierarchies into dimension tables.
o Use surrogate keys and ensure clean relationships.
Example:

Sales (Fact Table)

├── CustomerID
├── ProductID
├── Date
└── Revenue

Customer (Dimension)
Product (Dimension)
Date (Dimension)

12. How does filter context transition work in DAX, and how is it
handled inside iterators like SUMX? (Power BI / Advanced
DAX Evaluation Context)

Problem:
When you write a measure inside an iterator like SUMX, results may differ from what you expect.
Why does that happen?

Solution:
1. Row Context vs. Filter Context:
o Iterators (e.g., SUMX, FILTER, ADDCOLUMNS) create row context.
o Measures require filter context.
o DAX automatically performs context transition when a measure is evaluated inside
a row context.
2. Example:

Total Sales = SUM(Sales[Amount])

-- Row-by-row sum with context transition

Sales Using SUMX =
SUMX(
Sales,
[Total Sales] -- measure inside SUMX triggers context transition
)
Here, [Total Sales] becomes SUM(Sales[Amount]), but is scoped to each row in Sales due to the
row context.
3. Avoiding Pitfalls:
o When using calculated columns or iterators, be aware that context transition can cause
incorrect aggregation if misunderstood.
o Use VAR to capture values and avoid multiple evaluations.
 13. Explain the concept of bidirectional filtering and when to use
it cautiously.
Problem:
You want changes in one table (e.g., filter on Product) to affect another unrelated table (e.g.,
MarketingSpend). Should you use bidirectional filtering?
Solution:
1. What it is:
o Default relationships are single-directional: filters flow from dimension to fact.
o Bidirectional filters allow filters to flow both ways, enabling tables to influence each
other across indirect joins.
2. Example Use Case:
o You have:
▪ Product → Sales
▪ MarketingSpend also has ProductID
o You want selecting a product to affect both Sales and MarketingSpend.
3. Risks:
o Can create circular relationships and ambiguous paths.
o Hurts performance in large models.
o Breaks model logic if overused.
4. Best Practice:
o Use bidirectional filters only for specific modeling scenarios (e.g., many-to-many
relationships with bridge tables).
o Validate results carefully.

14. How do you implement dynamic titles or dynamic axis labels

in Power BI?

Problem:
You want a visual’s title or axis label to change based on user selection (e.g., Year vs. Quarter vs.
Month).
Solution:
1. Create a Table with Options:

AxisOptions = DATATABLE("TimePeriod", STRING, {{"Year"}, {"Quarter"}, {"Month"}})

2. Use Slicer on TimePeriod:
o Let users choose which time period they want to visualize.
 3. Use SWITCH in Measure:

SelectedAxis = SELECTEDVALUE(AxisOptions[TimePeriod])

Sales By Selected Axis =

SWITCH(
SelectedAxis,
"Year", CALCULATE([Total Sales], VALUES(Calendar[Year])),
"Quarter", CALCULATE([Total Sales], VALUES(Calendar[Quarter])),
"Month", CALCULATE([Total Sales], VALUES(Calendar[Month]))
)
4. Dynamic Title:

Dynamic Title = "Sales by " & SELECTEDVALUE(AxisOptions[TimePeriod])

5. Apply in visual:
o Use Dynamic Title as the visual title via conditional formatting.

15. What are Calculation Groups in Power BI and how do they

simplify complex models?
Problem:
You’re building a report with multiple time intelligence measures (YTD, MTD, QTD, YoY) for multiple
KPIs. Duplicating each variation becomes unmanageable.
Solution:
1. What Are Calculation Groups?
o A Tabular Model feature that lets you define a single group of reusable
calculations (like YTD, MTD, YoY).
o Reduces measure explosion (e.g., no need for Sales_YTD, Profit_YTD, etc.).
2. How to Create (via Tabular Editor):
o Open model in Tabular Editor.
o Right-click Tables → Create Calculation Group (e.g., “Time Intelligence”).
o Define calculation items:
-- Name: YTD
CALCULATE(SELECTEDMEASURE(), DATESYTD('Date'[Date]))
o Add slicer to report using the Calculation Group.
3. How It Works:
o SELECTEDMEASURE() acts as a placeholder for any base measure.
o You apply one logic (e.g., YTD) to multiple KPIs without repeating code.
 4. Result:
One slicer lets users toggle between different time comparisons across all KPIs dynamically,
saving time and reducing model size.

16. What is the role of Aggregation Tables in Power BI and when

should you use them?
Problem:
Your dataset contains 100+ million rows of transaction data. Reports are slow. How do you improve
performance while keeping details accessible?
Solution:
1. What Are Aggregation Tables?
o Pre-summarized tables (e.g., total sales per product per month) stored in-memory.
o Used to answer queries faster before hitting large fact tables.
2. How It Works:
o Create a summarized table:
SalesAgg =
SUMMARIZECOLUMNS(
Product[ProductID],
Date[Month],
"TotalSales", SUM(Sales[Amount])
)
o In Model View, set the aggregation table as a managed aggregate for the original Sales
table.
3. Power BI will:
o Automatically use the aggregation table for queries at that granularity.
o Fall back to the detailed table for drilldowns or filters not covered in the summary.
4. When to Use:
o Large datasets.
o Repeatedly used aggregations.
o Needing fast summary dashboards but detailed drilldowns.

17. How does Power BI handle Incremental Refresh and what

are its key components?
Problem:
You work with historical transaction data that rarely changes. Full dataset refreshes are slow. How
can you improve this with incremental refresh?
Solution:
1. Enable Incremental Refresh (Premium or Pro + Deployment Pipelines):
 o Go to Power BI Desktop → Table → RangeStart and RangeEnd parameters.
o Filter data in Power Query using:

Table.SelectRows(Source, each [Date] >= RangeStart and [Date] < RangeEnd)

2. Define Policy in Service:

After publishing:
Go to Dataset settings → Incremental Refresh.
1. Best Practice:
o
o Set:
▪ Store rows for: (e.g., 5 years)
▪ Refresh rows from: (e.g., last 30 days)

2. Benefits:
o Only recent data is refreshed, not the full dataset.
o Reduces refresh time and load on data sources.
o Can combine with partitions and aggregation tables for huge performance gains.
3. Best Practice:
o Use only on datetime-partitioned tables (e.g., large fact tables).
o Avoid volatile columns or values that change frequently.

Case Studies
18. What are Dataflows in Power BI and how are they different
from Datasets?

Problem:
The Sales leadership team wants a single visual that shows both actual monthly sales (as bars) and the
target sales line overlay, so they can quickly see which months under- or over-performed. Which visual
should you use and how do you build it?

Solution:
1. Choose the Combo Chart Visual:
o In Power BI Desktop, select the “Line and Stacked Column Chart” (or “Line and
Clustered Column Chart”) from the Visualizations pane.
2. Populate the Axis and Values:
o Axis: Drag Calendar[Month].
o Column Values: Drag your measure [Actual Sales].
o Line Values: Drag your measure [Sales Target].
3. Configure Formatting:
o Under Format → Y-axis, ensure the scales make sense (e.g., set the same start at
zero).
o Under Format → Data colors, pick distinct colours for bars and line so they stand out.
o Toggle Data labels on for both the column and line (under Format → Data labels)
to show exact numbers.
4. Add Tooltips for Context:
o Drag additional fields (e.g., SalesRep, Region) into the Tooltips well so hovering shows
drill-in details.
5. Example DAX Measures:

Actual Sales = SUM(Sales[Amount])

Sales Target = SUM(Targets[MonthlyTarget])
6. Result:
o A combo chart where each month’s actual bar is visually compared to the target line.
o Under-performing months are immediately visible when bars fall below the line.

19. Case Study: Root-Cause Analysis with a Decomposition Tree

Problem:
Product management wants to understand which combination of Region, Product Category, and
Sales Channel is driving a sudden drop in overall revenue. Which visual is best and how do you
configure it?

Solution:
1. Select the Decomposition Tree Visual:
o In the Visualizations pane, choose the “Decomposition Tree”.
2. Set the Analyze and Explain By Fields:
o Analyze: Drag in [Total Revenue].
o Explain by: Add Region, then Product[Category], then Sales[Channel].
3. Drill-Down Interaction:
o Power BI will automatically show the largest contributors to your revenue drop.
o The user clicks the “+” on the root to expand by Region, then can further expand any
 region by Category, and so on.
4. Customize the AI-assisted Splits:
o Turn on “Enable AI insights” under Format → General to let Power BI propose the
next best dimension to explore.
5. Example Measure:
Total Revenue = SUM(Sales[Revenue])
6. Result:
o A drillable tree that quickly surfaces, for example, that EMEA → Electronics → Online
is the segment causing 60% of the decline, guiding deeper investigation.

20. Case Study: Interactive Scatter Chart with Dynamic Sizing

and Coloring

Problem:
The Data Science team needs a scatter plot to visualize customer segments:
• X-axis = Average Order Value
• Y-axis = Purchase Frequency
• Bubble size = Customer Lifetime Value (CLV)
• Bubble color = Segment (e.g., “Gold”, “Silver”, “Bronze”)
They also want to highlight one segment when a slicer selection changes.

Solution:
1. Insert the Scatter Chart Visual:
o Select “Scatter chart” from the Visualizations pane.
2. Assign Data Fields:
o X Axis: CustomerMetrics[AvgOrderValue]
o Y Axis: CustomerMetrics[PurchaseFrequency]
o Size: CustomerMetrics[CLV]
o Legend (Color): Customer[Segment]
3. Add a Slicer for Highlighting:
o Create a slicer on Customer[Segment].
o Under the scatter chart’s Format → Data colors, turn on “Show all”.
o Assign a distinct highlight color for the selected segment (Power BI will automatically
bold the selected legend item).
4. Enable Drill-through or Cross-highlight:
o In Format → Cross-highlighting, ensure clicking on any bubble filters other visuals
on the page for deeper insight.
5. Example Data Preparation:
AvgOrderValue = DIVIDE(SUM(Orders[TotalAmount]), DISTINCTCOUNT(Orders[OrderID]))
PurchaseFrequency = COUNTROWS(Orders)
CLV = [AvgOrderValue] * [PurchaseFrequency] * Customer[RetentionRate]
6. Result:
o An interactive scatter where bubble size and color convey multi-dimensional data.
o The slicer dynamically emphasizes the chosen segment in the plot, guiding stakeholder
attention.