For Data Analysts

Data Analyst Portfolio: Show Your Work, Not Just Your Tools

Updated September 2026

What a data analyst portfolio actually needs to show

A data analyst portfolio is a collection of projects — not tools, not dashboards, not a list of software you know — that shows how you think through a problem with data. Each project is the unit of work, and each one needs five parts to count: the question you were trying to answer, the data you used, the method you chose and why, the finding that came out of it, and the decision it changed. If a project is missing any of those five, it is a demo, not a portfolio piece.

This is why "I built a dashboard" is not a project. A dashboard is an output — it is the chart at the end. It tells a hiring manager you know Tableau or Power BI, which they could already see on your résumé. What it does not tell them is whether you understood the business question behind the dashboard, whether you chose the right data to answer it, whether you cleaned that data or just connected to a pre-built view, or whether anyone actually used what you made to change a decision. A project that ends at "I built a dashboard" is a sentence with no verb.

The portfolio, then, is where each project gets its verb. It holds the narrative that connects the question to the decision: why you pulled that dataset, why you chose a cohort analysis instead of a simple average, what the stakeholder did differently because of what you found. That narrative is the thing a résumé cannot carry. A résumé lists what you did. A portfolio shows how you think — and thinking is the skill analysts are actually hired for.

This is also where a conversational portfolio becomes genuinely useful for this role. When someone hiring can ask your portfolio a question — "How did she handle missing data in that churn project?" or "Has he worked with stakeholders outside of engineering?" — and get an answer grounded in what you actually wrote, with a citation pointing back to the project or interview it came from, they are engaging with your analytical thinking, not just scanning a screenshot. The portfolio should be able to hold that conversation. Where it does not help: if an employer wants to run your notebook or interact with a live Tableau dashboard, the portfolio is the bridge to that work, not a replacement for it. It provides the context and the link; the tool provides the artifact.

How hiring managers actually read a data analyst portfolio

A hiring manager reviewing analyst candidates does not start at the top of your portfolio and read down like a book. They scan for one thing first: what question did this project answer, and what happened because of the answer? If the first project they click into opens with a clear business question — "We needed to know which customer segments were churning before renewal, and why" — they keep reading. If it opens with "I used Python, Pandas, and Matplotlib to analyze a dataset," they are already reaching for the next tab.

This is the single most important thing to understand before you build anything: the person reviewing your work is not evaluating your tools. They are evaluating your judgment. They want to know whether you can look at a messy situation, figure out the right question, find a defensible answer, and explain it to someone who does not write SQL. Every section of your portfolio either proves that or it doesn't.

What they look for first

The first scan — usually under a minute — checks two things:

• A stated question with business stakes. Not "I explored this dataset" but "The ops team was spending 14 hours a week on manual reconciliation and wanted to know which accounts were causing the most errors." The question tells them you understand why analysis exists: to change a decision.
• A finding that changed something. "We found that three vendor accounts generated 60% of reconciliation errors, and the team renegotiated terms with two of them." The finding closes the loop. Without it, the project is a homework exercise.

What they skip

Hiring managers in data roles consistently skip past three things:

• Tool lists without context. A sidebar that says "Python · SQL · Tableau · Excel · R" tells them nothing about depth or judgment. They will learn what you used when they read the project — if the project is good enough to read.
• Unnarrated dashboards. A Tableau embed with no written explanation of what it shows, why it was built, or what someone did with it is a screenshot, not a case study. Dashboards are outputs; portfolios need the thinking that led to them.
• Walls of code. A Jupyter notebook with forty cells and no markdown headings is a working file, not a presentation. If they want to see code, they will click through to your GitHub. The portfolio's job is to make them want to.

What disqualifies

Some things do not just get skipped — they end the review entirely:

• No business context on any project. If every case study starts with the dataset instead of the problem, the hiring manager concludes you do not think in terms of business impact. That is the hardest gap to coach, and most will not try.
• Fabricated or inflated results. Claiming a project "increased revenue by 30%" without any detail on how that was measured — or any indication you were in a position to measure it — reads as dishonest. Experienced reviewers catch this fast, and it poisons everything else on the portfolio.
• Three projects that all use the same Kaggle dataset with no original question. The Titanic dataset, the Iris dataset, the Boston housing dataset — they have seen them hundreds of times. The problem is not that you used public data; it is that you used someone else's question. A project on public data with your own question ("I wanted to know whether weather patterns predict 311 complaint volume in my city") shows genuine curiosity. A tutorial walkthrough with a different color scheme does not.

Build your portfolio with this read-order in mind: question first, finding second, method only when they care enough to look. Everything that follows on this page is designed around that sequence.

Section-by-section anatomy of a data analyst portfolio

Order matters. A hiring manager who opens your portfolio is making a series of micro-decisions — stay or leave, scroll or close — and each section either earns the next click or loses it. What follows is the structure, section by section, with what belongs in each and sample wording you can adapt.

1. Headline and title

This is the first line a visitor reads. It should name who you are, what you do, and — if possible — the domain or scale you work in. Skip clever taglines; be literal.

• Sample wording: "Data Analyst · 4 years in e-commerce and logistics · I turn messy transactional data into decisions that stick."
• If you are early-career: "Data Analyst · SQL, Python, Tableau · Focused on public-health data and operational reporting."

The headline is not your résumé summary rewritten. It is shorter, more specific, and aimed at the person who just landed here and needs a reason to scroll.

2. About section

Two to four sentences. Not your life story — the part of your story that explains why you do this work and how you think about it. A good About section answers a question a résumé never can: what is it like to work with this person?

• Sample wording: "I spent three years as an operations coordinator before I ever wrote a query, so I learned what questions matter before I learned how to answer them with data. That background shows up in how I scope projects: I start with the decision someone needs to make, not the dataset sitting in front of me."

If you are using Skillfolio, this section draws on a short interview you complete during setup — a few questions about how you actually operate. That means the About section reflects how you think, not just what you have done, and the AI on your portfolio can answer follow-up questions about it.

3. Project case studies

This is the core of the portfolio. Each project follows the same five-part structure, and that consistency is the point — it lets a hiring manager compare your thinking across different problems without re-learning your format every time.

For each project:

• Question: What business or research question were you answering? One sentence. "Which product categories had the highest return rates, and were returns correlated with specific fulfillment centers?"
• Data: What did you work with, where did it come from, and what shape was it in? "18 months of order and return records from our Shopify and 3PL exports — roughly 240,000 rows, joined on order ID, with ~12% missing fulfillment timestamps."
• Method: What did you do, and why that approach? Name the tools, but lead with the reasoning. "Cleaned and joined the tables in SQL, flagged the missing timestamps, then built a logistic regression in Python to test whether fulfillment center was a significant predictor of returns after controlling for category and price band."
• Finding: What did you learn? State it plainly. "Two of five fulfillment centers had return rates 3.2× the company average, concentrated in fragile-goods categories. The model confirmed fulfillment center as the strongest predictor after product category."
• Decision: What changed because of this work? "The ops team rerouted fragile-goods orders away from those two centers. Returns in those categories dropped 28% over the following quarter."

Three to five projects is the right range. Fewer feels thin; more than five and a hiring manager starts skimming. Lead with your strongest.

The portfolio as connective layer

Your actual work lives in different places — a GitHub repo, a Jupyter notebook on Google Colab, a Tableau Public dashboard, a written case study in a Google Doc. That is fine. The portfolio does not replace those tools; it ties them together. Each project case study links out to the live work, but it provides the context, the summary, and the "why it matters" that a raw notebook or repo cannot. A hiring manager reads the five-part case study on your portfolio, then clicks through to the notebook if they want to see the code. They never have to open five tabs and guess which one matters.

4. Skills in context

Not a grid of logos. Not a self-rated bar chart. A short list of tools and methods, each tied to the project where you used it.

• Sample wording: "SQL (PostgreSQL) — used in every project here; primary tool for cleaning, joining, and aggregating. Python (pandas, scikit-learn) — logistic regression and clustering in the returns and segmentation projects. Tableau — built the executive dashboard in the fulfillment routing project."

This section exists so a recruiter doing a keyword scan finds what they need, but it earns credibility because every tool points back to a real project they can read.

5. Contact and link

Your email address. Your LinkedIn, if you keep it current. A line inviting them to reach out. Nothing else needs to be here.

• Sample wording: "If a project here is relevant to what you are hiring for, I would like to hear about the role — [email] · [LinkedIn]."

Keep the portfolio link itself short and professional — your name or close to it. That link goes on your résumé under your name, in application fields, and in outreach emails. It is the single URL that holds everything together, so a hiring manager never has to chase down your work across platforms.

Four illustrative sample portfolios, from bootcamp grad to career changer

The section-by-section anatomy gives you the structure. These four composites show how to fill it — different career situations, different project inventories, different things to emphasize. Each is an illustrative sample, not a real person. Use whichever one mirrors your situation as a starting template, then replace the details with your own.

1. Bootcamp graduate, no professional analyst experience, three personal projects with public data

Illustrative sample. This person finished a twelve-week data analytics bootcamp and has never held an analyst title. Their portfolio leads with their strongest project, not their education.

• Headline: "Data analyst focused on public-health questions and clear communication of findings."
• About section: Two sentences on the career switch (previously in nonprofit administration), one sentence on what kind of analytical problems they care about, one sentence on their working style — "I write findings for people who will never open the notebook."
• Project case studies (three): Each follows the five-part structure. The lead project: "Which Chicago ZIP codes lost the most primary-care access between 2018 and 2023?" — built from publicly available HRSA data, cleaned and joined in SQL, visualized in Tableau, finding that three South Side ZIPs lost every federally qualified health center within walking distance. The decision it informed: a capstone presentation to a local health nonprofit that used the map in a grant application. The other two projects are smaller but each states a question and a finding, not just a tool.
• Skills in context: SQL, Tableau, Excel, Python (pandas) — each tied to the project where they used it, not listed in a sidebar.
• Contact/link: Email, LinkedIn, and a short line: "Ask my portfolio anything about how I work — it answers from my own experience."

Why this order: With no job titles to lean on, the projects are the credibility. The About section is brief because the work has to speak first. Education (the bootcamp, a prior degree) sits below the projects, not above them.

2. Excel-to-SQL career changer, five years in operations, reframing existing work

Illustrative sample. This person has been doing analysis inside operations roles for years — building reports in Excel, pulling numbers for quarterly reviews — but has never had "analyst" in their title. They recently learned SQL and want to make the switch official.

• Headline: "Operations analyst moving into a dedicated data role — five years of turning messy internal data into decisions."
• About section: Frames the career change as a natural progression, not a restart. "I have been the person my team asks when the numbers do not make sense. I am formalizing what I have been doing informally for five years."
• Project case studies (three): Two are reframed from their operations work (anonymized — company names removed, dollar figures replaced with percentages). Example: "Why were 40% of our fulfillment delays happening on Tuesdays?" — analyzed eighteen months of shipping logs in Excel, rebuilt the analysis in SQL to show the method, found that a single vendor's pickup schedule created a bottleneck, recommended a schedule change that cut Tuesday delays by half. The third project is a personal SQL project using a public dataset, showing they can write queries outside a spreadsheet.
• Skills in context: Excel (pivot tables, VLOOKUP, conditional formatting for dashboards), SQL (joins, subqueries, window functions), basic Tableau. Each skill tied to a specific project moment.
• Contact/link: Email, LinkedIn, portfolio link.

Why this order: The headline and About section do the heaviest lifting here because the reader's first question is "why should I consider someone without an analyst title?" The reframed operations projects answer it immediately: this person has been doing the work, just under a different name.

3. Mid-level analyst, four years of experience, moving to a larger company

Illustrative sample. This person has been an analyst at a 200-person company and is applying to organizations with dedicated data teams, cross-functional stakeholders, and more complex data infrastructure.

• Headline: "Data analyst with four years of experience turning ambiguous business questions into analyses that reach the people who make the call."
• About section: Emphasizes stakeholder communication and working across departments. "At a smaller company, the analyst is also the person presenting to the VP, writing the executive summary, and defending the methodology when someone pushes back. I have done all three."
• Project case studies (two to three): These are meatier and focus on scale and impact. Lead project: "Which customer segments were most likely to churn in the next 90 days, and what could retention actually do about it?" — used internal transaction and support-ticket data (presented here with anonymized figures and a synthetic dataset that mirrors the structure), built a cohort analysis in SQL, visualized segments in Tableau, presented findings to the VP of Customer Success, and the retention team piloted a targeted outreach campaign to the highest-risk cohort. The finding: the segment most likely to churn was not the one with the most support tickets — it was the one that had gone quiet. The second project shows cross-functional work: partnering with marketing to measure campaign attribution, explaining the methodology to a non-technical team, and documenting the limits of the analysis.
• Skills in context: SQL (complex queries, stored procedures), Python (pandas, matplotlib), Tableau, dbt, stakeholder presentation. The emphasis is on what they did with each tool in a real project, not a proficiency rating.
• Contact/link: Email, LinkedIn, portfolio link, and a note: "Happy to walk through any project in detail — or ask my portfolio directly."

Why this order: A larger company wants to see that this person can handle ambiguity, communicate across teams, and work with messier data at greater scale. The About section addresses that directly, and the projects prove it. Skills come last because at this level, the hiring manager assumes competence with the tools — they want to see judgment.

4. Analyst moving toward data science, bridging analytical work with predictive modeling

Illustrative sample. This person has three years as a data analyst and is applying to hybrid analyst/data-science roles. They have started building predictive models but have not held a data-science title.

• Headline: "Data analyst building toward data science — three years of analytical work, now adding prediction to the toolkit."
• About section: Honest about where they are in the transition. "I am not a machine-learning engineer. I am an analyst who noticed that the questions I was being asked — 'what will happen next quarter?' — required models, not just dashboards. So I started building them." This framing is more credible than claiming to be a data scientist already.
• Project case studies (three): Ordered to show trajectory. First project is pure analysis: "Which product features correlate most strongly with 30-day retention?" — SQL, cohort analysis, a clear finding presented to product leadership. Second project bridges: "Can we predict which free-trial users will convert?" — starts with exploratory analysis, then builds a logistic regression model in Python (scikit-learn), evaluates it honestly (including where it fails), and explains the business decision it supported. Third project is a personal project using a public dataset, building a more complex model — random forest or gradient boosting — with a clear write-up of feature selection, validation, and the tradeoffs they made. Each project links to a GitHub repo or a Jupyter notebook, but the portfolio itself tells the story; the repo holds the code.
• Skills in context: SQL, Python (pandas, scikit-learn, matplotlib), Tableau, basic statistics (hypothesis testing, regression). The key here is showing the progression: analysis → statistical reasoning → modeling. Each skill appears inside a project, not in a list.
• Contact/link: Email, LinkedIn, GitHub, portfolio link.

Why this order: The trajectory is the argument. By ordering projects from pure analysis to predictive modeling, the portfolio shows a clear direction without overclaiming. The About section sets expectations honestly, and the projects deliver on them. A hiring manager for a hybrid role sees someone who can already do the analytical work and is credibly building the modeling skills — not someone who took one Kaggle course and calls themselves a data scientist.

What to show when you have no track record yet

No analyst title on your résumé does not mean no analysis worth showing. It means the work you present has to carry itself — the question, the method, the finding, and why anyone should care — without a company name doing the heavy lifting. That is a higher bar, but it is one you can clear with projects you choose yourself.

Personal projects that start with a real question

The difference between a portfolio project and a tutorial walkthrough is the question. Loading the Titanic dataset and predicting survival is a classroom exercise. Pulling Census Bureau commuting data and asking "Which U.S. metro areas lost the most public-transit riders between 2019 and 2023, and does the drop correlate with remote-work adoption rates?" is an original project — even though the data is free and the tools are beginner-level. The question is yours, the analytical choices are yours, and the finding is something a reader did not already know.

Sources that work well for this: Data.gov, the Bureau of Labor Statistics, city open-data portals, sports-reference sites, public health databases. Pick something you genuinely care about — local housing costs, marathon finishing times, library usage — because curiosity shows in the writing and in the follow-up questions you think to ask.

Other work that counts

• Volunteer data work. A nonprofit that needed a donor-retention analysis or an event-attendance breakdown gave you a real stakeholder and a real decision. Frame it the same way you would frame paid work: question, data, method, finding, what changed.
• Course capstones, reframed. Strip the assignment prompt and rewrite the project as a case study. State the question in business terms, not course-catalog terms. "Final project for DATA 301" tells a hiring manager nothing; "Which pricing tier drives the highest 90-day retention for a mid-size SaaS product?" tells them exactly what you can do.

When the data is confidential

If you did real analytical work — at an internship, a part-time job, even a family business — but the underlying data is proprietary, you still have a project worth showing. Three approaches that protect the data without gutting the story:

• Synthetic data. Generate a dataset with the same structure, distributions, and quirks as the original. Document that it is synthetic, then walk through the same analysis. The method and the reasoning are yours to show.
• A public dataset that mirrors the problem. If you built a churn model on internal customer data, find a public telecom or subscription dataset and replicate the approach. The portfolio case study explains that the original work was confidential and this version demonstrates the same methodology on comparable data.
• Anonymized findings. Remove company names, client names, and exact figures. Present percentage changes, directional findings, and the decision the analysis informed. "Identified that 22% of support tickets originated from a single onboarding step, leading the team to redesign that step" is specific enough to be credible and vague enough to be safe.

The point in every case is the same: show the thinking, not the access. A hiring manager reading an early-career portfolio is not looking for Fortune 500 logos. They are looking for someone who asks a clear question, picks a defensible method, finds something worth reporting, and writes it up so a non-analyst can follow along. That is the job. Your portfolio is proof you can already do it.

The mistakes that cost data analysts interviews, and the fix for each

Most portfolio problems are not about missing skills. They are about missing context. A hiring manager sees the work, cannot figure out why it matters, and moves on. These are the specific mistakes that cause that — and the fix for each one.

Projects with no stated question or business context

A project that opens with "I used Python and Pandas to clean and analyse this dataset" has already lost the reader. There is no question, no stakes, no reason to keep going. The fix: every project starts with one sentence naming the question someone needed answered and why the answer mattered. "The ops team was losing two hours a day to manual order routing — I analysed six months of order data to find which rules could be automated" gives a hiring manager something to care about before a single line of code appears.

Dashboards presented without the "so what"

A Tableau embed or a screenshot of a dashboard is not a project. It is an output. Without the question it answered and the decision it informed, it is decoration. The fix: write one paragraph above the dashboard explaining what someone did with it. "This dashboard replaced a weekly email chain between sales and finance. The CFO used the margin view to cut two underperforming product lines in Q3" turns a screenshot into evidence of impact.

Tool-name-dropping without demonstrated use

Listing "Python, SQL, Tableau, R, Power BI, dbt, Looker" in a skills section and never showing any of them in a project tells a hiring manager nothing. The fix: name the tool inside the project where you used it, in one clause. "I wrote the extraction query in PostgreSQL and built the summary view in Tableau" is proof. A standalone list is a claim.

Identical Kaggle projects with no original question

The Titanic dataset, the Iris dataset, the housing-prices competition — hiring managers have seen hundreds of these, all answering the same tutorial prompt. They do not disqualify you, but they do not distinguish you either. The fix: take the same technique and apply it to a question you actually wanted to answer. Predict something you care about using a public dataset nobody assigned you. The method can be simple; the question has to be yours.

Broken GitHub links or notebooks that do not run

A link that 404s or a Jupyter notebook that throws an import error on the first cell tells a hiring manager you did not check your own work — which is exactly the quality they are trying to evaluate. The fix: click every link in your portfolio once a month. Run every notebook from a clean environment. If a repo has dependencies, include a requirements file and say so in the README.

No narrative connecting the projects

Three unrelated projects sitting side by side with no thread between them make a hiring manager guess what kind of analyst you are. The fix: order your projects deliberately and add one sentence at the top of the section explaining the thread. "These projects show how I approach messy operational data — finding the question first, then building the simplest analysis that answers it" gives the reader a lens before they start.

Over-designed portfolios that bury the analysis

Animated transitions, full-bleed hero images, elaborate colour schemes — none of it helps if the hiring manager cannot find the project write-ups within five seconds. Analysts are not being hired for visual design. The fix: plain structure, clear headings, projects front and centre. The portfolio should read more like a well-organised report than a marketing site. If someone has to scroll past a parallax banner to reach your first case study, the banner is costing you attention you cannot afford to lose.

Every one of these mistakes has the same root: the portfolio shows what was built but not why it mattered. Audit yours against this list, fix the gaps, and the work you have already done starts carrying its own weight.

Where your projects live vs. where your portfolio lives

Your SQL queries sit in a GitHub repo. Your Tableau dashboards live on Tableau Public. Your Python notebooks run in Google Colab or Observable. A written case study might be a Google Doc or a Medium post. None of these are your portfolio — they are the evidence your portfolio points to.

The portfolio is the connective layer: the single link that gives a hiring manager the question each project answered, the finding, and the decision it changed — then links out to the live work for anyone who wants to go deeper. Without that layer, you are asking someone to open five tabs, read an uncommented notebook, guess which Tableau workbook matters, and piece together a story you should have told yourself. Most will not bother.

How to share the link

• On your résumé: directly under your name, next to your email and phone number. It belongs in the header, not buried in a "Links" section at the bottom.
• In an application: paste the link and reference a specific project — "my portfolio includes a case study on the churn analysis I mention in my cover letter."
• In an email: one line on what they will find. "My portfolio walks through three projects, including a retention analysis that changed how we segmented trial users."
• At a networking event or on a printed résumé: a QR code that opens the portfolio on a phone in one scan.

What the link should look like

Short, professional, and close to your name. A link like skillfolio.studio/maria-chen reads as intentional. A link like sites.google.com/view/maria-data-portfolio-v3 does not. Whatever format you choose, the link should be something you can say out loud without spelling it twice.

Format comparison: where should a data analyst portfolio actually live

The format you choose determines what a hiring manager can actually do when they land on your portfolio. Some formats let them look. Some let them click around. One lets them ask questions and get answers grounded in your real work. Here is how the options compare on the things that matter for this role.

Where a conversational portfolio genuinely helps a data analyst

A hiring manager reading analyst portfolios is not just scanning for tool names — they want to understand how you approached a problem, whether you have worked with data at the scale they care about, and how you communicated findings to people who are not analysts. Those are exactly the kinds of questions a conversational portfolio can answer on its own: "Has she cleaned messy real-world data, or only worked with pre-processed datasets?" or "How did he decide which metrics to track?" The AI answers from what you actually wrote and said during setup, cites the source, and never fabricates a detail. For a hiring manager deciding whether to schedule a call, that is faster and more useful than opening a GitHub repo and reading code comments.

Fit analysis adds another layer. When an employer pastes in their job description, they get an honest read — not just the overlap, but the gaps. If the role needs Spark experience and you have not touched it, the analysis says so. That honesty is what makes the match credible when it is strong.

Where it is not a replacement

If the employer wants to interact with a live Tableau dashboard, run a Jupyter notebook, or review your SQL in a GitHub repo, the conversational portfolio is not where that happens. Those tools do what they do, and nothing should try to replace them. What the portfolio does is sit in front of all of it — giving the hiring manager the question you were answering, the finding, and the decision it changed, with a link straight to the live work. It is the connective layer, not a substitute for the artifacts themselves. A site builder can do the same linking, but it cannot answer a follow-up question about your methodology at 11 p.m. when the hiring manager is finally reading applications.

What a conversational portfolio does for a data analyst — and a real example

Skillfolio takes your résumé and turns it into a conversational portfolio — a website at your own link, built around your work and your thinking, with an AI that can answer an employer's questions about you on its own.

Here is how it works, end to end. You upload the résumé you have (or build one from scratch if yours is outdated or nonexistent). Skillfolio rebuilds it — the wording and the design — into something worth sending, and you can still export that as a normal PDF. Then it becomes a portfolio: not another PDF, not a LinkedIn profile, but your own page holding your projects, your story, and the context a résumé cannot carry. During setup, a short interview asks how you think and work — the kinds of questions that surface your approach to messy data, your instinct for what to investigate next, the way you communicate findings to people who do not speak SQL. All of that — your résumé and your interview answers — becomes what the portfolio knows about you.

When a hiring manager visits, they can ask it anything:

• "Has she worked with messy real-world data or just clean datasets?"
• "How many years of SQL experience does he have?"
• "Has she presented findings to non-technical stakeholders?"

Every answer comes back with a citation showing exactly where it came from — a line in your résumé, a sentence from your interview. It never invents anything or goes past what you actually wrote.

Fit analysis goes one step further. An employer pastes in their job description and gets an honest read of how you match the role — gaps included, not just the highlights. That honesty is what makes the good part trustworthy: when the portfolio says you are a strong fit for something, the employer knows it is not just telling them what they want to hear.

The whole thing takes about ten minutes. You can see how it works with three live personas — Sales, Operations, and Product — in the interactive demo.

Build the portfolio that answers the questions your résumé cannot

Your résumé lists the tools, the titles, the years. It does what a résumé is supposed to do — and then it stops. It cannot explain why you chose a logistic regression over a decision tree, how you handled a dataset full of missing values, or what happened after your analysis landed on a VP's desk. Those are the questions that decide whether someone wants to work with you, and a PDF has no way to answer them.

A portfolio shows how you think. It puts the question before the query, the finding before the dashboard, the decision before the deliverable. And a conversational portfolio goes one step further: it lets the person hiring ask those questions directly — about your experience, your methods, your fit for their role — and get real answers grounded in work you actually did.

You already have what you need to start. If you have a résumé, Skillfolio rebuilds it and turns it into a conversational portfolio — your projects, your story, and an AI that answers employer questions with citations from your real experience. If you do not have a résumé yet, it builds one from scratch. Either way, the whole thing takes about ten minutes, and the portfolio is live at your own link the moment you finish.

Stop sending a document that only says what you did. Build the portfolio that shows who you are.

Common questions

What should a data analyst portfolio include?

Projects you've worked on, the questions you answered, the findings you surfaced, and how you communicated them. Show the process—how you cleaned the data, what you tested, why you chose that method—not just the final dashboard. Include your résumé, a short bio explaining how you work, and links to any public work like GitHub repos or published analyses.

Do data analysts need a portfolio?

Not always required, but it helps. Most analyst roles ask for a résumé and expect you to talk through your work in an interview. A portfolio lets you show that work upfront—the SQL you wrote, the insight you found, the deck you built to explain it—so a hiring manager can see how you think before they meet you.

How do I make a data analyst portfolio with no experience?

Use public datasets and answer real questions with them. Pick something you're curious about—transit delays, local housing prices, sports stats—clean it, analyze it, and write up what you found. Treat each one like a short case study: the question, your method, the result, what you'd do differently. That shows you can do the work, even if it wasn't paid.

What projects should I put in a data analyst portfolio?

Two to four projects that show range: exploratory analysis, a predictive model, a dashboard or visualization, and ideally something that required messy data cleaning. For each one, explain the business question, your approach, the tools you used, and the outcome. If you can't share work projects due to NDAs, use public data or anonymize the details but keep the structure real.

Should I include code in my data analyst portfolio?

Yes, but don't make someone read all of it to understand what you did. Link to your GitHub or include key snippets with plain-English explanations of what each part does and why you wrote it that way. The goal is to show you can code and that you think through problems, not to prove you can write a hundred lines of SQL.

How long should a data analyst portfolio be?

Short enough to scan in five minutes. A hiring manager should be able to see your best work, read one project in detail, and understand how you operate without scrolling past filler. Three strong projects explained clearly will always beat six half-explained ones.

What's the difference between a data analyst portfolio and a résumé?

Your résumé lists what you did and where. Your portfolio shows how you did it—the actual analysis, the decisions you made, the way you explained the findings. A résumé says you have SQL and Tableau skills; a portfolio proves it by showing the queries you wrote and the dashboards you built, with the context that makes them meaningful.

Can I use Skillfolio to build a data analyst portfolio?

Yes. Skillfolio turns your résumé into a conversational portfolio that holds your projects, your process, and the stories behind your work. You upload your résumé, answer a few questions about how you operate, and it builds a site at your own link. The page includes an AI that answers questions about your experience—like how many years you've worked with Python or whether you've done customer segmentation—so a recruiter can explore your background without waiting for an email back.

Where should I host my data analyst portfolio?

Anywhere you control the link and the content. GitHub Pages works if you're comfortable with code. Notion or Carrd work if you want something simpler. Skillfolio works if you want a portfolio that starts from your résumé, updates everywhere the moment you change it, and can answer questions about your experience on its own.

Do I need a personal website as a data analyst?

Not required, but useful. A personal website gives you one link that holds your résumé, your projects, and your explanations of how you work—so when someone asks to see your portfolio, you send them to your own page instead of a PDF and a Google Drive folder. It also means you're not relying on LinkedIn's layout or a job board's profile limits to show what you've done.