USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. What is the difference between DirectQuery and Import mode?
Short answer: Import loads data into the model (fast); DirectQuery queries the source live (fresh).
Strong answer: Import mode loads data into Power BI’s in-memory VertiPaq engine — fast and feature-rich but needs refresh and has size limits. DirectQuery queries the source at runtime — always current and handles huge data, but slower and with modeling limits. Composite models mix both. Choose by data size and freshness needs.
Likely follow-up: When would you accept DirectQuery’s slower performance?
What the interviewer is checking: Modeling trade-off understanding.
Common mistake: Using Import for data too large or too real-time.
Q2. What is the difference between a calculated column and a measure?
Short answer: Columns compute per row at refresh; measures compute at query time by context.
Strong answer: A calculated column is evaluated row-by-row and stored in the model (uses memory), good for row-level attributes. A measure is evaluated at query time based on filter context and is not stored, ideal for aggregations. Prefer measures for calculations that respond to slicers/filters; overusing calculated columns bloats the model.
Likely follow-up: Why do measures respond to slicers but stored columns don’t recompute?
What the interviewer is checking: DAX fundamentals.
Common mistake: Building aggregations as calculated columns.
Q3. Explain row context vs filter context in DAX.
Short answer: Row context iterates rows; filter context is the set of filters applied to a calculation.
Strong answer: Row context exists when iterating (calculated columns, iterators like SUMX) and refers to the current row. Filter context is the set of filters (from slicers, rows/columns, CALCULATE) restricting the data a measure sees. CALCULATE modifies filter context, and context transition converts row context to filter context. This is the crux of DAX.
Likely follow-up: What does CALCULATE do to filter context?
What the interviewer is checking: Deep DAX understanding.
Common mistake: Confusing the two contexts and getting wrong totals.
Q4. How do you design an efficient Power BI data model?
Short answer: Star schema with fact and dimension tables, not a flat or snowflaked mess.
Strong answer: Model as a star schema: central fact tables (measures) linked to dimension tables (attributes) via single-direction relationships. Avoid overly wide flat tables and unnecessary bidirectional relationships. Reduce cardinality, hide keys, and use proper data types. A clean star schema drives both performance and correct DAX.
Likely follow-up: Why is a star schema better than one flat table?
What the interviewer is checking: Modeling best practice.
Common mistake: Importing one huge denormalized table.
Q5. How do you optimize Power BI report performance?
Short answer: Trim the model, prefer measures, reduce visuals/cardinality, and check the Performance Analyzer.
Strong answer: Remove unused columns/tables, use Import where feasible, prefer measures over calculated columns, reduce visual count and high-cardinality slicers per page, and use aggregations for large models. Use the Performance Analyzer and DAX Studio to find slow visuals/queries. Model size and DAX are the usual bottlenecks.
Likely follow-up: What tool shows which visual is slow?
What the interviewer is checking: Performance-tuning skill.
Common mistake: Blaming the service instead of profiling the model/DAX.
Q6. How do you implement row-level security (RLS)?
Short answer: Define roles with DAX filters so users see only their data.
Strong answer: RLS restricts data by user: define roles with DAX filter rules on tables (e.g., [Region] = USERPRINCIPALNAME() mapping), then assign users to roles in the service. Dynamic RLS uses a mapping table plus USERPRINCIPALNAME() to filter automatically. Test roles with "View as". It secures a shared report without separate copies.
Likely follow-up: How does dynamic RLS avoid a role per user?
What the interviewer is checking: Security implementation.
Common mistake: Building separate reports per audience instead of using RLS.