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.

How to Describe Data Portfolio Projects on a Resume

You describe a data portfolio project on a resume by leading with the business impact, naming the tools you used, and keeping each entry to 2 to 3 bullet points. That's it. A lot of people overthink this section and end up with a wall of technical jargon that tells the recruiter nothing useful.

One underused option many career changers overlook: your current job may have data work you can frame as a portfolio project without building anything from scratch.

I got hired without a formal portfolio site. I had 3 project links sitting on my resume, 2 Tableau dashboards on Tableau Public and 1 Power BI project, and nothing tying them together. What mattered was how I described those projects in the entries themselves.

Here's exactly how to do that.

What to include in each project entry
The right format for a resume project entry
How to write impact when you have no real-world data
Which tools to mention and how
Common mistakes that kill project descriptions
Before and after examples
FAQ

What to include in each project entry

A strong project entry answers 3 questions a hiring manager is actually asking:

What did you build? The output, a dashboard, a model, an analysis, named up front rather than buried.
What tools did you use? SQL, Excel, Tableau, Power BI, Python, stated in the bullet where you used them.
What was the scope or the question? How much data, how many sources, and what business question the work answered.

That's the whole template. Everything else is decoration.

One thing I see constantly: people describe the process instead of the output. "Cleaned data, built visualizations, presented findings" tells the reader nothing about what you actually produced or why it mattered. Flip it around. Start with the output and work backwards.

The right format for a resume project entry

Each project gets a short header line and 2 to 3 bullet points. Not a paragraph. Bullets. Recruiters are skimming, and a paragraph in the projects section is going to get skipped.

The header line should include the project name and a link if you have one. Tableau Public links are fine. A GitHub repo is fine. A Google Looker Studio link is fine. Just make sure the link actually works before you send the resume.

For the bullets, use this structure:

Bullet 1: what you built and the main tool, in context. "Built a Power BI dashboard tracking monthly revenue and churn across 3 product lines."
Bullet 2: the scope and the technical work. "Wrote SQL to clean and join 4 raw tables covering 85,000 records."
Bullet 3: the finding or the business question answered. "Surfaced that churn concentrated in the first 30 days, pointing to onboarding as the fix."

3 bullets is the ceiling. If you find yourself writing 5, you're padding. Cut it down.

If you're serious about building a resume that gets past the ATS and lands interviews, the program at analysthive.io walks you through the exact format I used, including the projects section, with templates you fill in as you build your actual projects.

How to write impact when you have no real-world data

The number one objection I hear: "My project is fake data I pulled from Kaggle. I can't write impact for that."

You can. You just have to think about it differently.

Impact on a personal project means scope and specificity, not business outcomes you couldn't have measured. Here are the kinds of numbers you can pull from any project:

The size of the dataset. "Analyzed 80,000 order records" is a real number from a real thing you did.
The number of sources or tables. "Joined 4 tables from 2 separate datasets" shows you can handle more than a single clean file.
The number of metrics or views you built. "Built a dashboard tracking 6 KPIs across 3 regions" describes real scope.
The time span the data covered. "Covered 24 months of transactions" signals you worked with trends, not a snapshot.

"Analyzed a dataset of 80,000 records" is a real number that came from a real thing you did. Use it.

The other move is to frame the business question your project would answer if the data were real. "Built a dashboard to track monthly revenue trends, customer acquisition by channel, and churn rate" tells a hiring manager exactly what kind of analysis you know how to do. The source of the data matters a lot less than the structure of the thinking.

Which tools to mention and how

Name the tools inline, in the bullet where you used them. Don't put them all in a separate "Technologies Used" line at the bottom of the project entry, recruiters and ATS systems both want to see the tool in context.

Good: "Wrote SQL queries (PostgreSQL) to extract and transform raw sales data."

Less useful: "Built a sales analysis project. Tools: SQL, Python, Tableau."

The difference is that the first version tells the reader what you used SQL for. That's the signal they're looking for. Listing tools in isolation just proves you know the word "SQL." Showing how you used it proves you know what to do with it.

For the tools themselves, prioritize the ones that show up most in job postings for the roles you're targeting. SQL almost always leads. Excel matters more than people think. Tableau, Power BI, or Looker depending on what you built. Python if you used it for actual data work, not just "I installed pandas."

I work in data engineering now, Snowflake, Coalesce, pipeline architecture, and I can tell you that even at more senior levels, the question is always the same: can you show me what you built and can you explain why you built it that way? The resume is the first place you answer that question.

Common mistakes that kill project descriptions

These are the patterns I see in resume after resume from people who can't figure out why they're not getting callbacks.

Describing the process instead of the output. "Cleaned, analyzed, and visualized data" says what every analyst does, not what you produced.
Listing tools in isolation. A standalone "Tools: SQL, Python, Tableau" line proves you know the words, not that you can use them.
Writing paragraphs instead of bullets. A block of text in the projects section gets skipped by a skimming recruiter.
No link, or a broken one. A project with nothing to click is harder to trust; a dead link is worse than none.
Padding to 5 or more bullets. More bullets dilute the strong ones. Three sharp lines beat five soft ones.
Vague claims. "Found interesting insights" tells the reader nothing. Name the finding or cut the line.

Before and after examples

Here's the same project written 2 ways.

Before (what most people write):

Analyzed sales data and created visualizations to present findings.
Cleaned the data and identified trends.
Tools used: SQL, Tableau.

After (what gets interviews):

Wrote SQL (PostgreSQL) to clean and join 3 raw sales tables covering 85,000 order records.
Built a Tableau dashboard (Tableau Public) tracking monthly revenue, customer acquisition by channel, and churn rate.
Surfaced that repeat-purchase rate, not new-customer volume, drove the Q3 revenue dip.

Same project. The second version tells you what was built, what tools were used and how, what scale it operated at, and where you can see it. The first version tells you the person knows what cleaning and visualizing data means. That's not enough.

The after version also works on a real dataset or a Kaggle dataset. The number (85,000 records) came from the dataset. The SQL detail came from what you actually wrote. You don't need a corporate project to write a description like that.

Once you have 2 to 3 project entries written this way, the projects section becomes one of the strongest parts of your resume, especially when you don't have years of work history to fill the page. If you want a step-by-step plan for building those projects and formatting everything correctly, that's exactly what the program at skool.com/analysthive/about covers in Month 1.

FAQ

How many portfolio projects should I list on a resume?

2 to 3 is the sweet spot for most entry-level candidates. 1 project looks thin. 4 or more starts eating into the space you need for work history and skills. Pick your 3 strongest and describe them well rather than listing 5 mediocre entries.

Should I put portfolio projects in their own section or under experience?

Their own section, labeled "Projects" or "Data Projects." Putting personal projects under Experience next to paid jobs can confuse recruiters about your actual work history. Keep them separate so it's immediately clear what each section represents.

Do I need a portfolio website to get hired as a data analyst?

No. I got hired without one. A portfolio website is a nice-to-have, but individual project links (Tableau Public, GitHub, Google Looker Studio) on your resume do the same job. What matters is that the work is visible and the descriptions are strong.

What if my project used a Kaggle dataset? Do I have to say that?

You don't need to call out the source unless it's directly relevant. Most hiring managers care about what you built and how you approached it, not where the data came from. Just describe the project accurately, the tools, the scope, and the analysis you did.

How do I describe a project that didn't have a clear outcome?

Focus on scope and methodology instead. "Analyzed 60,000 rows of sales data to identify seasonal demand patterns" is a complete description even if you never presented it to anyone or took action on it. The analysis itself is the output.

Should I list the tools at the top of the project entry or inside the bullets?

Inside the bullets, in context. "Used SQL (PostgreSQL) and Python to clean and join 3 tables" tells the reader what you used the tools for. A standalone "Tools: SQL, Python, Tableau" line at the top of the entry just lists words without showing how you applied them.