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.

What Is Power Query and When to Use It

Power Query is a data connection and transformation tool built into Excel and Power BI. It lets you connect to a data source, shape the data into the format you need, and load it into your workbook or model -- without touching the source data and without writing manual formulas for every transformation step.

If you've ever spent time cleaning a spreadsheet by hand -- fixing date formats, removing blank rows, splitting a column into two, merging data from multiple files -- Power Query automates that process. You set it up once, and every time you refresh, the same steps run automatically.

Why Power Query exists
How it works
Common tasks
When to use it (and when not to)
Getting started
FAQ

Why Power Query exists

The problem Power Query solves is the gap between how data arrives and how data needs to look for analysis.

Data from source systems -- exported CSVs, database dumps, system reports -- rarely comes in the format you need. Dates are formatted inconsistently. There are extra header rows. Columns have names that don't match what your analysis expects. Some fields contain multiple pieces of information that should be split. Tables that need to be combined are in separate files.

Without Power Query, the standard approach is to clean the data manually every time it comes in. Copy it to a working sheet, delete the rows you don't need, fix the formatting, merge the sheets together. This works once. It becomes expensive when the data updates weekly or monthly and you have to repeat the same steps each time.

Power Query records the transformation steps. When data comes in again, you click Refresh and the same steps run on the new data.

How it works

Power Query works in a few stages:

Connect. You point Power Query at a data source -- a file, a folder of files, a database, a web URL, an API. Power Query reads the data and shows you a preview.

Transform. You apply transformation steps using the Query Editor interface. Most common operations are available as menu commands: remove columns, filter rows, change data types, split columns, merge queries. Each step you apply is recorded in the Applied Steps pane on the right side of the editor.

Load. Once the data is shaped the way you want it, you load it into Excel (as a table on a worksheet or directly into the Data Model) or into Power BI's data model.

Refresh. When the source data changes, clicking Refresh re-runs all the transformation steps against the new data and updates the output.

Common tasks

The tasks Power Query handles most often in practice:

Removing blank rows and extra headers. Source files often have extra rows at the top or empty rows between data sections. Power Query can filter these out once, and they'll always be removed on refresh.
Fixing data types. A column that should be a date might come in as text. Power Query converts it, and the conversion runs every time the data refreshes.
Splitting and combining columns. A full name field that needs to be split into first and last, or a date and time in one column that should be two. These are point-and-click operations in Power Query.
Merging data from multiple sources. Combining last month's sales data with this month's, or joining a customer list to a transaction table. Power Query handles both appending (stacking rows) and merging (joining on a key).
Unpivoting columns. Data that's been formatted for reading (months as column headers, with values in each column) often needs to be restructured for analysis (one row per month, with a month column and a value column). Unpivot is a single operation in Power Query.

When to use it (and when not to)

Power Query is the right tool when:

Data needs the same transformations applied repeatedly as it refreshes
You're combining data from multiple sources or files
The source data is messy in a consistent way that can be automated
You're preparing data for a Power BI model and need it in a specific structure

Power Query is not the right tool when:

You need a one-time, manual fix that won't repeat
The transformation logic depends on runtime filter context (that's a job for DAX in Power BI)
The data is already clean and just needs to be referenced in a formula

Getting started

In Excel: Data tab, Get Data button. This opens the connection options. For a simple start, connect to an Excel file or CSV.

In Power BI: Home tab, Get Data button. The available source types are broader than Excel's, including databases, cloud services, and web URLs.

Once you have data in the editor, the ribbon at the top of the Query Editor contains the most common transformation operations. Right-clicking a column header shows options specific to that column. The Applied Steps pane on the right shows the sequence of steps and lets you click back to any previous state.

The best way to learn Power Query is to import a messy dataset you actually need to clean and work through the transformations on that data. Tutorial datasets built for learning are more sanitized than real data and don't surface the kinds of problems Power Query is most useful for.

FAQ

Does Power Query change the source data?
No. Power Query reads from the source and creates a separate output in your workbook or model. The original file is not modified.

What's the difference between Power Query in Excel and in Power BI?
They use the same underlying engine and the same M language. The interface is nearly identical. The main difference is where the output goes: in Excel, it loads to a worksheet table or the Data Model; in Power BI, it loads to the model. Queries built in Excel can often be copied directly into Power BI and vice versa.

Do I need to know the M language?
Not to start. Most operations are available through the interface without writing M. But understanding the basics of M becomes useful when you need to do something the interface doesn't directly support, or when you want to parameterize a query (like making the date range a variable rather than a hardcoded value).

How do I handle a source file that changes location?
In the Applied Steps pane, click the gear icon next to the Source step. You can update the file path there. For queries that need to work across different machines or environments, using a parameter for the file path is the more robust approach.