How much of a data analyst's day is spent writing SQL?

Most of it. On a typical day, 3 to 5 hours go into writing, testing, and fixing SQL queries. That's the bulk of the work, not a side skill. The queries aren't glamorous—you're pulling a table, checking if the numbers match what someone expects, joining it to another table, and formatting it so a non-technical person can read it.

Do data analysts use Python every day?

Not at the entry level, and often not later either. SQL and a spreadsheet tool cover most entry-level and mid-level analyst work. Python shows up more in data engineering, machine learning, or advanced analytics roles, not in the daily grind of a standard analyst seat.

What meetings does a data analyst attend?

A typical week includes a team standup, one or two stakeholder meetings where you present or explain a number, and the occasional call where someone wants to understand a dashboard they can't read on their own. The skill that matters most in these meetings is explaining a number in one sentence to someone who doesn't care how you got it.

Is being a data analyst boring?

Some of it, yes. Most days include stretches of repetitive query writing and data cleanup that nobody would call exciting. The interesting part shows up when a chart finally answers a question someone's been asking for weeks, or when you catch an error before it reaches a director's inbox.

What's the difference between a junior and senior analyst's day?

A junior analyst spends more time on execution: writing the queries, building the dashboard, fixing the data someone else flagged. A senior analyst spends more time deciding what should get built in the first place and pushing back when a request doesn't make sense. Both still write SQL most days. The senior version just spends less time on syntax and more time on judgment.

What tools does a data analyst use daily?

In order of frequency: SQL editor, a BI tool like Tableau or Looker, spreadsheets like Excel or Google Sheets, Slack or email, and Python (occasionally). SQL editor is used most, while Python ranks lower than many expect, especially at the entry level.

Power Query vs DAX: What Each Does and When to Use Each

Power Query and DAX are both tools inside Power BI, but they do completely different things. A lot of beginners treat them as interchangeable -- "I'll just do it in DAX" or "I'll fix it in Power Query" -- and then end up with models that are harder to maintain than they need to be.

The clearest way to think about it: Power Query is where you shape your data before it loads. DAX is where you calculate things after it's loaded. Each one has a job. When you use the right one for the right task, both become simpler.

What Power Query does
What DAX does
When to use Power Query
When to use DAX
What goes wrong when you use the wrong tool
Practical approach
FAQ

What Power Query does

Power Query runs when data loads into the model. It's a transformation engine: it takes raw data from a source and reshapes it into something the model can use.

Tasks Power Query handles:

Removing columns you don't need
Renaming columns to clean up naming
Filtering rows to exclude irrelevant records
Splitting columns (a full name column into first and last, for example)
Merging tables from different sources
Unpivoting data from wide format to long format
Replacing values and cleaning inconsistent text
Adding calculated columns based on static logic that doesn't need to respond to report filters

Everything in Power Query happens before the data model is built. The result is a table (or set of tables) that gets loaded into Power BI's model.

What DAX does

DAX runs inside the model, after data is loaded. It calculates values in real time, responding to whatever filters the user has applied in the report.

Tasks DAX handles:

Aggregating rows (total sales, count of transactions, average order value)
Comparing time periods (year-over-year, month-to-date, rolling averages)
Calculating percentages and ratios across filtered contexts
Creating dynamic measures that respond to slicers and page filters
Implementing complex conditional logic that depends on the current filter context

The key difference from Power Query: DAX calculations update live as users interact with the report. When someone filters by region, every DAX measure recalculates for that region. Power Query transformations don't respond to user interaction -- they're fixed at load time.

When to use Power Query

Use Power Query for anything that's about the shape and quality of your data:

Cleaning messy source data (extra spaces, inconsistent formats, null handling)
Combining data from multiple sources into one table
Restructuring tables that came in the wrong shape for analysis
Adding reference data or lookup tables
Filtering out records you'll never need
Any transformation that should happen once, at load time, rather than recalculating on every interaction

If you find yourself thinking "I want this column to always be X," that's a Power Query task. The shape of the data is set before it hits the model.

When to use DAX

Use DAX for anything that needs to respond to the report's filter context:

Totals and aggregations (Sales Amount = SUM(Sales[Amount]))
Ratios and percentages that depend on what's filtered
Time intelligence comparisons (prior year, year-to-date)
Conditional aggregations (sales where margin > 20%)
Any calculation that changes based on what a user selects

If you find yourself thinking "I want this number to update when someone filters by product category," that's a DAX task. It needs to respond to context that doesn't exist until the report is open.

What goes wrong when you use the wrong tool

Using DAX when you should use Power Query: You end up with calculated columns that recalculate unnecessarily, or measures that are doing work that should have been done at data load. The model gets bigger and slower. The logic is harder to follow because it's scattered between the query editor and the model.

Using Power Query when you should use DAX: You create columns that are static and can't respond to what the user is doing. You try to pre-calculate aggregations that Power Query isn't designed to handle well. The logic breaks when you need it to be dynamic.

The most common version of this mistake is creating calculated columns in Power Query for things that should be DAX measures. Calculated columns add rows of data to the table. Measures respond to filters. When you need a dynamic calculation, a column can never replace a measure.

Practical approach

When you're working on a new report, a simple decision rule:

If the transformation should happen once and doesn't depend on user interaction: Power Query
If the calculation needs to respond to slicers, filters, or page context: DAX
If you're unsure, ask: "Does this need to change when someone clicks a filter?" No = Power Query, Yes = DAX

In practice, most reports use both. Power Query shapes the raw data into clean, properly structured tables. DAX calculates the measures those tables support. They're complementary, not competing.

FAQ

Can I do the same thing in both?
Sometimes, but usually one is clearly better. Adding a calculated column in Power Query is different from adding one in the data model with DAX -- the Power Query column is fixed; the DAX column recalculates when the filter context changes. For most aggregations, a DAX measure is the right approach. For structural transformations, Power Query is.

Which should I learn first?
Power Query. Most beginners need to understand how data gets shaped before they can understand what DAX is calculating. Start with Power Query until you can connect data sources, clean data, and build a basic model. Then add DAX.

Does Power Query slow reports down?
Power Query runs at load time, not at report interaction time. So Power Query complexity affects how long it takes to refresh the dataset, not how fast the report responds to filters. Heavy Power Query transformations can slow refreshes significantly. Simplify them or push the work upstream to the data source when possible.

Are there things only DAX can do?
Yes. Time intelligence (year-to-date, prior period comparisons), dynamic aggregations, and calculations that need to respond to filter context can only be done in DAX. These are things you can't replicate in Power Query because Power Query doesn't know about the report's filter context.