Microsoft Data Analyst Interview Preparation Guide - Senior Level (5-12 Years)

Direct answer
Different companies score behavioral interviews against an explicit, published list of values or principles (Amazon's Leadership Principles, Google's culture questions, Netflix's Freedom and Responsibility framing, and many others). The preparation move is building a small inventory of six to ten real stories from your own work, tagging each with the one or two principles it most naturally demonstrates, then rehearsing them so they sound like your own voice, not the company's marketing language.

Structured elaboration

1. Research the company's actual, current published list. Read the real wording rather than a paraphrase from a prep article, since the specific phrasing often matters to how an interviewer will probe.
2. Build a story inventory before the interview: six to ten stories spanning different situations (a technical trade-off, a conflict, a mistake, a moment you led without formal authority, a customer-facing choice).
3. For each story, identify which one or two principles it most naturally supports. Resist forcing a story to fit a principle it doesn't genuinely show; a shallow fit is easy for an experienced interviewer to spot.
4. Rehearse the story itself, not a script that names the principle repeatedly. A good answer demonstrates the principle through the actions and choices described, and lets the interviewer recognize it.
5. Prepare to reframe the same story around a different principle if asked. Candidates who over-fit one story to one principle tend to struggle when a panel probes for a different angle.

Worked example
A candidate has a story about shipping a feature despite pushback. A first-draft framing centers on: "I pushed hard to get the feature out on time." A more principle-authentic framing, for a company whose stated principle is customer focus, instead leads with the evidence: "Support tickets showed users were repeatedly confused by the old flow, so I made the case that shipping on time mattered less than shipping the right fix, and I only pushed for speed once we had confirmed the new version actually addressed what customers were reporting." The underlying facts are identical; the second version leads with the customer evidence, which is what makes it read as authentic to the principle rather than a generic assertion of hard work.

Trade-offs and pitfalls
Over-rehearsed language that repeats the principle's name throughout a story tends to sound recited, and interviewers who run these loops regularly notice it quickly. Forcing one story into every principle bucket produces a worse answer than admitting a different story fits better and asking, where the format allows it, to use that one instead. Researching an outdated version of a company's list, then referencing a principle name that has since changed, undermines credibility even when the underlying story is strong.

Direct answer

The pyramid principle says to structure a data narrative top-down: state your main conclusion first, then the two or three arguments that support it, then the evidence beneath each argument, rather than building up to the conclusion the way you actually did the analysis. The closely related SCQA shape (Situation, Complication, Question, Answer) is a way to construct that top line: state the shared context, name what changed or went wrong, pose the question that creates, then answer it, with the Answer being the same headline the pyramid puts first.

Structured elaboration

1. Why top-down beats bottom-up for a busy decision-maker.
Analysis is naturally built bottom-up: you gather data, run tests, notice patterns, and arrive at a conclusion at the end of that process. But a decision-maker reading or hearing the result does not have time to retrace that path and does not need to; they need the conclusion first so they can decide how much of the supporting detail they actually want. Presenting bottom-up (data first, conclusion last) forces every reader to sit through the full derivation before learning the point, and it means anyone who stops reading after the first paragraph, which is common in a busy inbox or meeting, misses the actual finding.

2. The pyramid's three layers.
At the top: a single governing conclusion or recommendation, stated as a complete sentence, not a topic label ('Churn is a problem' is a topic; 'Churn among enterprise accounts rose 4 points last quarter and threatens renewal revenue, we recommend X' is a conclusion). In the middle: two to four supporting arguments, each one a reason the top conclusion is true, ideally grouped so they are mutually exclusive and collectively exhaustive of the case you're making, not an arbitrary list. At the base: the specific evidence, numbers, and analysis behind each supporting argument, which is where the detail-oriented reader or a skeptical stakeholder can drill in.

3. The SCQA framing for arriving at that top line.
Situation: state the shared, uncontested context ("Enterprise renewal rates have been stable around 92% for six quarters"). Complication: name what changed or what tension that creates ("This quarter renewal dropped to 88%, concentrated in accounts onboarded in the last year"). Question: the natural question the complication raises ("What's driving the drop, and can we intervene before renewal season peaks?"). Answer: your actual conclusion and recommendation, which becomes the pyramid's top line. SCQA is really a technique for constructing a compelling, honest top line; the pyramid is what you do with that top line once you have it.

4. Restructuring a bottom-up finding into this shape.
Take the order you actually worked in (data pull, exploratory checks, a few dead ends, the eventual pattern, the conclusion) and literally invert it for the write-up: conclusion first, then the two or three strongest reasons, then evidence for each reason. The dead ends and exploratory detours from your real process almost never belong in the final artifact at all; they belong in an appendix or nowhere, because the pyramid is a communication structure, not a lab notebook.

Worked example

An analyst investigates a support-ticket increase by pulling ticket volume by category, checking for a recent product release, cross-referencing with a signup cohort analysis, and eventually finding the pattern. Built bottom-up, the write-up would read: "We pulled ticket data for the last 90 days... we checked release notes... we then looked at signups by cohort... and found that tickets from users onboarded after the March release are 3x more likely to file a billing-related ticket." Restructured with the pyramid/SCQA shape: Situation/Answer-first: "Billing-related support tickets are up 40% quarter over quarter, driven almost entirely by users onboarded after the March release; we recommend a fix to the new billing confirmation step before the next release." Supporting arguments: (1) users onboarded after March file billing tickets at 3x the rate of earlier cohorts, (2) the March release changed the billing confirmation flow, (3) no other cohort or category shows a comparable increase, ruling out a general support-quality issue. Evidence for each argument follows beneath, in the same order, for the reader who wants to verify the claim rather than just act on it.

Trade-offs and pitfalls

• The most common mistake is writing the top line as a topic ("Q3 billing tickets") instead of a complete, decision-relevant sentence with a conclusion in it; a topic doesn't tell the reader anything they can act on.
• Forcing every supporting argument to be truly independent (mutually exclusive) takes real editing; a first draft often has 4-5 overlapping points that should collapse into 2-3 distinct ones.
• The pyramid structure is not a license to omit genuine uncertainty or counter-evidence; the top line should still be honest about confidence and limitations, not just punchy.
• Over-applying the framework to a finding that genuinely has no single clear conclusion (a mixed or inconclusive result) produces a false sense of clarity; in that case the honest top line states the ambiguity itself as the headline, rather than forcing a decisive-sounding conclusion the evidence doesn't support.

Reach for SQL whenever the task needs to run against the full underlying data rather than a manually pasted extract, needs to be exactly reproducible, or needs to combine several tables by a key. A spreadsheet's VLOOKUP and pivot table are fine for a small, single-table slice a person can eyeball once; they degrade badly as the row count, the number of source tables, or the need to repeat the calculation correctly next month all grow.

Two concrete examples

1. Joining and deduplicating across multiple sources. Combining a CRM export, a billing export, and a support-ticket export by customer_id into one row per customer. VLOOKUP handles one lookup column against one other sheet; the moment a task needs a three-way join with duplicate keys on either side, VLOOKUP returns only the first match and silently drops or miscounts the rest. A SQL JOIN handles the full match set deterministically, and a GROUP BY handles the deduplication explicitly and visibly.

2. Any calculation someone else needs to reproduce exactly, or that needs to run on a schedule. A pivot table's field configuration lives inside the spreadsheet's UI: it isn't version-controlled, isn't easy to diff, and has to be manually rebuilt correctly by whoever opens the file next. A saved SQL query (or a view) is text: it runs identically every time, can sit in source control, and can be scheduled without a human reopening a workbook.

The reverse direction: SQL's equivalent of a pivot table or VLOOKUP

A GROUP BY with aggregate functions is SQL's version of a pivot table's row-grouping plus value-aggregation. A JOIN on a shared key is SQL's version of VLOOKUP or INDEX-MATCH: instead of "look up this key in that other sheet's range," it's "match every row in table B to the row in table A that shares this key," for as many tables as needed at once.

Worked example

CREATE TABLE orders (
  order_id INTEGER PRIMARY KEY,
  region   TEXT,
  amount   NUMERIC
);

INSERT INTO orders (region, amount) VALUES
  ('East', 400), ('East', 600), ('West', 150),
  ('West', 200), ('West', 250), ('North', 2400);

SELECT
  region,
  SUM(amount) AS region_revenue,
  ROUND(100.0 * SUM(amount) / (SELECT SUM(amount) FROM orders), 1) AS pct_of_total
FROM orders
GROUP BY region
ORDER BY region_revenue DESC;

Result:

┌────────┬────────────────┬──────────────┐
│ region │ region_revenue │ pct_of_total │
├────────┼────────────────┼──────────────┤
│ North  │ 2400           │ 60.0         │
│ East   │ 1000           │ 25.0         │
│ West   │ 600            │ 15.0         │
└────────┴────────────────┴──────────────┘

A pivot table gets the region_revenue column easily. Getting pct_of_total right, as a value that stays correct if a new region is added later, needs either a spreadsheet formula referencing a moving total range (easy to break: forgetting to update the range after adding a row is a classic spreadsheet bug) or exactly this scalar subquery, which recomputes the grand total from the same source rows every time the query runs.

Trade-offs & pitfalls

• SQL is not better at everything. Ad-hoc, throwaway exploration by someone without database access, or the final polished chart for a stakeholder deck, is usually faster and clearer done in a spreadsheet or the BI layer.
• Centralize a calculation once in SQL (a shared view) instead of letting five dashboards each compute "active users" a slightly different way in their own pivot tables. This is one of the most common reasons dashboards disagree with each other.
• Common wrong turn: over-engineering a one-time, 20-row question into a SQL pipeline when a five-minute spreadsheet look would answer it. Match the tool to whether the task repeats or needs to scale, not to which tool seems more technical.

Approach: build a single composite score that balances expected value (ARR), cost (engineering PM), and uncertainty. Use normalized metrics and a risk-adjusted value / cost ratio.

Model:

1. Inputs per feature: ARR (annual incremental $), Cost (person-months), Uncertainty factor U ∈ {Low=0.9, Medium=0.7, High=0.4} (multiplier to reflect probability-weighted capture).
2. Risk-adjusted value: V = ARR * U
3. Normalize Cost to a 0–1 scale: C_norm = Cost / MaxCost
4. Compute score: Score = (V / Cost) * (1 / (1 + α * (1 - U))) where α controls penalty for uncertainty (α∈[0,2], default 1). Equivalent simpler: Score = (V / Cost) * U_adjust where U_adjust = 1/(1+α*(1-U)).

Example (three features):

• A: ARR= $600k, Cost=12 PM, Uncertainty=Low (U=0.9)
• B: ARR= $400k, Cost=6 PM, Uncertainty=High (U=0.4)
• C: ARR= $300k, Cost=4 PM, Uncertainty=Medium (U=0.7)
  MaxCost=12, α=1.

Compute V:
A: V=600k0.9=540k. V/Cost=45k per PM. U_adjust=1/(1+1(0.1))=0.909. Score=45k0.909=40.9k
B: V=400k0.4=160k. V/Cost=26.67k. U_adj=1/(1+0.6)=0.625. Score=16.67k
C: V=300k*0.7=210k. V/Cost=52.5k. U_adj=1/(1+0.3)=0.769. Score=40.38k

Rank: A (40.9k), C (40.4k), B (16.7k) → prioritize A then C.

Discussion / trade-offs:

• This emphasizes expected ROI per engineering PM and penalizes uncertainty. α tunes risk tolerance: lower α favors high-uncertainty/high-upside features; higher α favors predictable wins.
• Limitations: ignores strategic non-ARR benefits (retention, regulatory), dependencies, parallel execution constraints, and engineering capacity over time. Mitigations: add strategic multipliers, include time-to-value by discounting ARR, run sensitivity analysis (vary U and α), and Monte Carlo simulation for more sophisticated uncertainty modeling.
  Implementation notes for a Data Analyst:
• Build this in SQL/Excel/Tableau to compute scores, expose sliders for α and uncertainty mappings, and create a dashboard showing rank, sensitivity ranges, and capacity-constrained roadmap scenarios.

Direct answer. Give every table an alias, and give every ambiguous column an explicit AS alias in the SELECT list, so the result set's column names are unambiguous no matter how many joined tables happen to share a name.

Structured elaboration. SQL resolves o.id versus s.id fine inside the query itself (the alias disambiguates it for the engine), but the OUTPUT column name is a different problem: if you write SELECT o.id, s.id, most engines will happily return two columns both literally named "id", and it's up to positional order (not name) to tell them apart downstream. That's fragile for anything reading the result by column name.

Worked example. orders(id, created_at, customer_id): (1, '2025-01-01', 1). shipments(id, created_at, order_id): (9, '2025-01-03', order_id=1).

SELECT o.id AS order_id, o.created_at AS order_created_at,
       s.id AS shipment_id, s.created_at AS shipment_created_at
FROM orders o
JOIN shipments s ON s.order_id = o.id;

Result: (order_id=1, order_created_at='2025-01-01', shipment_id=9, shipment_created_at='2025-01-03'). Every column name in the output is unique and self-describing.

Trade-offs and pitfalls. Without explicit aliasing, a BI tool or downstream script consuming the result by column NAME (rather than position) will typically just grab whichever "id" or "created_at" its driver happens to return first, silently reading the wrong one, with no error at all: the query succeeds, the numbers just quietly refer to the wrong table's column. This is worse than a query that fails outright, because nothing signals the mistake. Adopting a house convention (always alias every table, always alias every column that could collide) removes the ambiguity by construction rather than relying on every consumer downstream to guess correctly.

Pick the single primary metric by scoring each candidate against four lenses: expected business impact if it moves, sensitivity (can you detect a real change with a feasible sample size), resistance to gaming, and whether it is a reliable leading indicator of the outcome that actually matters long-term. Then support that one metric with guardrails and secondary metrics so nothing important gets silently traded away.

Structured elaboration

The four lenses

Practical selection process

1. List candidate metrics spanning the stated goals (engagement, retention, revenue).
2. Score each candidate against the four lenses, weighted by how much the team's current priorities value business impact versus detectability versus long-term validity.
3. Run a rough sample-size or power check on the top 1 to 2 candidates; drop any that cannot realistically reach significance in the available traffic and time window.
4. Select one primary metric for the go/no-go decision; keep the rest as secondary or guardrail metrics.

Guardrails and secondary metrics

• Secondary metrics track outcomes the primary metric does not directly capture (revenue, longer-horizon retention) so a "win" on the primary metric can be checked against the bigger picture before shipping.
• Guardrail metrics are pre-committed abort conditions (error rate, revenue floor, opt-out rate) with thresholds set before the test runs; a breach pauses or reverses the rollout regardless of what the primary metric shows.
• The primary metric decides whether it works; guardrails decide whether it is safe to keep running; secondaries decide whether the win actually matters beyond the primary.

Worked example

A checkout redesign experiment has three engagement-adjacent candidates: checkout conversion rate, session length, and add-to-cart rate. Scoring each on the four lenses (1 is weak, 5 is strong; this is purely illustrative of how the framework is applied, not a claim about any real dataset):

Checkout conversion rate wins on business impact, gaming resistance, and leading-indicator validity, and has reasonable sensitivity given typical checkout traffic; it becomes the primary metric, with revenue per user and 30-day retention tracked as secondary metrics, and error rate and refund rate as guardrails with pre-set abort thresholds.

Trade-offs & pitfalls

• The four lenses can conflict: the highest-business-impact metric is sometimes the least sensitive, since rare, high-value events are hard to detect quickly, forcing a genuine trade-off rather than a clean winner.
• A metric that scores well today can still be gamed once teams learn the incentive it creates; gaming resistance should be revisited periodically, not scored once and forgotten.
• Choosing a primary metric that is only a proxy for the real goal (session length as a stand-in for engagement) risks optimizing the proxy at the expense of the goal it was meant to represent.
• Too many guardrails, each with strict thresholds, can make a test unlaunchable in practice by triggering false alarms; guardrail thresholds need the same rigor, based on natural variance rather than gut feeling, as the primary metric's own significance threshold.

Approach
I would use a recursive CTE. A recursive CTE is a query that repeatedly joins a result back to the base table, which is a standard way to walk a tree. I would start from each category, climb to its parent, and carry a path string plus a cycle check so bad data cannot recurse forever.

WITH RECURSIVE ancestry AS (
  SELECT
    c.category_id,
    c.category_id AS ancestor_id,
    c.parent_id,
    0 AS depth,
    CAST('>' || c.category_id || '>' AS text) AS path
  FROM categories c

  UNION ALL

  SELECT
    a.category_id,
    p.category_id AS ancestor_id,
    p.parent_id,
    a.depth + 1,
    a.path || p.category_id || '>'
  FROM ancestry a
  JOIN categories p
    ON p.category_id = a.parent_id
  WHERE POSITION('>' || p.category_id || '>' IN a.path) = 0
)
SELECT *
FROM ancestry;

How I would use it

• Build the full ancestor path by grouping the rows for each category_id.
• Roll sales up by joining facts to category_id, then summing again by ancestor_id.
• Exclude or quarantine orphans, where a parent is missing.
• Add a max-depth guard if the warehouse supports it.

Worked example
For Shoes -> Apparel -> Root, the CTE emits three rows with depths 0, 1, 2. That gives a safe path and lets sales from Shoes roll up to Apparel and Root without double counting.

Direct answer
Autonomy should track demonstrated judgment in a specific domain, not tenure or title, and it should be granted and withdrawn through visible, structural mechanisms, not just a private mental model of how much you trust someone. As someone grows from junior to senior, both the default level of guidance and the criteria for changing it should become more explicit, not less.

What determines the level, not just the person's level

• Domain-specific, not global: someone can have earned full autonomy in one area (their core service) and need more guidance in an adjacent one (security-sensitive changes) they haven't touched before. Treating autonomy as a single dial per person rather than per domain misjudges both directions.
• Base it on evidence: track record of decisions in that specific domain, not just general seniority or how long they've been on the team.

The conversation isn't enough, structure it

• Guidance and autonomy shouldn't live only in how much you check in; they should be encoded in the system itself. Concretely: mandatory review gates on certain categories of change, feature flags that let risky work ship dark before it's fully trusted, and automated checks (tests, linting, policy gates) that catch the class of mistake a specific person is prone to, rather than relying on a human remembering to look for it.
• This matters especially early: a junior engineer with a mandatory review gate on production-config changes isn't being distrusted personally, the system is compensating for a domain they haven't yet built judgment in, and that's a much less fraught conversation than "I don't trust your judgment yet."

Moving the dial, in both directions

• Define, in advance, what "graduating" out of a guardrail looks like: a number of changes in that domain reviewed without a significant issue, or a specific type of decision made correctly under supervision. Vague criteria ("when I feel comfortable") makes the process feel arbitrary to the person on the other side of it.
• The dial also needs to move backward cleanly. If someone senior makes a judgment error in a domain, temporarily reintroducing a guardrail (an extra review, a smaller blast radius) shouldn't read as a permanent demotion; it should be scoped to the specific domain and have the same kind of explicit, objective path back out.

How this shifts junior to senior

• Junior: guidance is broad and mostly structural (required reviews, smaller scoped tasks, pairing), because there isn't yet enough track record to know where the real gaps are.
• Mid-level: guidance narrows to the specific domains where judgment hasn't been tested yet, while proven domains get real autonomy.
• Senior: guidance becomes mostly about the highest-blast-radius decisions (irreversible changes, cross-team commitments) rather than day-to-day execution, and the structural safeguards that remain exist because the stakes are higher, not because trust is lower.

Worked example
A mid-level engineer had strong judgment in their core service but hadn't touched the deployment pipeline before. Rather than a blanket "you need approval on everything" or "you're trusted, go ahead," the guidance was scoped to that specific gap: full autonomy on their usual work, a mandatory review plus a feature flag for anything touching the deploy pipeline, with an explicit criterion stated up front (three pipeline changes reviewed cleanly, then the mandatory review comes off for that category specifically). That made the guardrail feel like a scoped, temporary compensation for an actual gap rather than a general judgment about their competence, and removing it was a specific, visible moment rather than something that just quietly happened.

Trade-offs and pitfalls

• Treating autonomy as all-or-nothing per person, rather than per domain, either over-restricts someone who's earned trust in most areas or over-extends them into an area they haven't proven yet.
• Relying purely on personal judgment about who to trust, without structural backstops (review gates, flags, automated checks), doesn't scale past a small team and creates inconsistency that reads as favoritism.
• Leaving the criteria for regaining autonomy vague turns a guardrail into something that feels indefinite and punitive, even when it was scoped and reasonable at the start.

Direct answer. Cohort analysis groups users by a shared starting point, most commonly the week or day they signed up, and tracks how each group behaves over time relative to that starting point. Cohort segmentation is the more general practice of slicing any analysis by these groups (or other shared attributes) instead of only looking at blended, cross-sectional averages. The reason this matters for root-cause work is that a blended metric can hide exactly the story you need: if overall retention drops, cohort analysis tells you whether it's because NEW cohorts are behaving differently (a product or acquisition-quality problem) or because an OLD cohort's behavior changed at a specific point in time (a change that hit everyone at once, like an outage or a pricing change).

Structured elaboration. Two concrete ways cohort slicing finds a root cause:

1. New-cohort-only drop. If you plot retention curves for several consecutive signup cohorts and only the most recent 1-2 cohorts show a lower curve while older cohorts look normal, the cause is almost certainly something that changed for NEW users specifically: an onboarding flow change, a shift in acquisition channel or campaign mix bringing in lower-intent users, or a broken signup-time event.
2. Cross-cohort simultaneous drop. If every cohort's retention curve, regardless of signup date, dips at the SAME calendar date, the cause is an event that hit all users at once: an outage, a pricing change, a UI regression, or a tracking break, not anything about who signed up.

Cohort dimensions worth defining beyond signup date: acquisition channel or campaign (isolates marketing-driven quality shifts), first-feature-used (isolates onboarding-path effects), platform or device (isolates a client-specific regression), and geography (isolates a market-specific or regulatory cause). The choice of cohort window (daily vs. weekly) is a bias/noise trade-off: daily cohorts pinpoint the exact day something changed but each cohort has fewer users and a noisier curve; weekly cohorts are more stable but blur the exact day.

Worked example. A subscription product's week-1 retention has been declining for a month. Plotting retention curves by signup week: cohorts from weeks 1-3 all show the SAME retention curve when re-aligned to days-since-signup, but week 4's cohort sits visibly below the others starting from day 0. That pattern (only the newest cohort is different, and it's different from day 0, not from a later day) points at something about the SIGNUP EXPERIENCE itself for that week, not a mid-lifecycle event; checking the release log finds an onboarding-flow redesign that shipped exactly at the start of week 4.

Trade-offs and pitfalls. A common mistake is reading a cohort chart from left to right instead of top to bottom: comparing where curves stand relative to each other at the SAME days-since-signup value (top to bottom) diagnoses a cohort-quality difference, while comparing what happens to one curve over calendar time can mix up product effects with market effects. Also watch for survivorship bias in very recent cohorts: the newest cohort hasn't had time to reach later retention windows yet, so an apparent 'improvement' in a young cohort's early numbers can just be incomplete data, not better retention.

Start with goals: isolate whether failures/slowness originate in upstream ETL, DW, network/gateway, dataset refresh, or visuals; collect evidence; apply quick mitigations to restore service.

1. ETL jobs

• Logs/metrics: job run history, step-level durations, error messages, row counts, source latency, CPU/memory on ETL host, retry counts.
• Tests: re-run failing job manually with subset; validate row counts/hash checksums vs. last successful run.
• Mitigations: schedule a rerun out-of-hours; fall back to last known-good snapshot; throttle parallel extractions.

2. Data warehouse

• Logs/metrics: query performance (query plans, long-running queries), blocking/locks, table/index fragmentation, growth metrics, disk I/O, recent schema changes, statistics age.
• Tests: run representative queries used by report (LIMIT sample) and full aggregated queries; check resource contention (sp_who2, sys.dm_*).
• Mitigations: rebuild stats/indexes, increase resource class for ETL, move expensive indices offline, restore partition to yesterday.

3. Network / Gateway

• Logs/metrics: gateway logs (On-prem gateway), network latency, packet loss, throughput, TLS errors, concurrent connection count.
• Tests: ping/traceroute from gateway to DW and sources; reproduce refresh from gateway diagnostic tool; test from a different gateway region/node.
• Mitigations: switch to alternate gateway, increase gateway cluster nodes, retry with direct cloud connection if available.

4. Power BI dataset refresh

• Logs/metrics: refresh history (duration, success/failure step), query diagnostics (performance analyzer, Query Folding info), Mashup engine memory/CPU, incremental refresh logs.
• Tests: refresh only specific tables; run “Refresh” in Desktop with diagnostics enabled; enable/disable privacy levels to test folding.
• Mitigations: disable non-critical queries, split dataset into smaller datasets, enable incremental refresh, reduce parallelism.

5. Frontend visuals

• Logs/metrics: Performance Analyzer timings, DAX Query Plan, timeline of visual rendering, browser devtools network and CPU, dataset size in model view.
• Tests: open report with single visual, reproduce slowness; test with optimized visual (simpler chart) or with filters; test with Aggregations/Materialized views.
• Mitigations: replace heavy visuals (high-cardinality slicers) with alternatives, add pre-aggregated tables, enable query caching, pin slow visuals to dashboard with cached tiles.

Investigation workflow:

• Correlate timestamps across logs to find where latency spikes/failures begin.
• Prioritize reproducible tests: manual ETL -> direct DW queries -> gateway checks -> Power BI Desktop refresh -> report load with Performance Analyzer.
• Communicate interim status and use temporary mitigations (rollback snapshot, incremental refresh, alternate gateway) to restore stable reporting while fixing root cause.

Key stop conditions: persistent ETL failures indicate upstream fix; DW contention suggests indexing/partitioning; gateway/network issues point to infra; long DAX/visual times point to model/visual redesign.