Ian Klosowicz
You don't need a portfolio website to get hired as a data analyst. Individual project links placed directly on your resume work, and most entry-level analysts who land jobs use exactly that approach. The question of where to host each type of project has a clear answer for each tool you're using, and the setup for all of them is free.
This post covers where to host SQL projects, BI dashboards, Python work, and whether building a portfolio website is worth the time investment during a job search.
The standard for entry-level analyst portfolios is a projects section on the resume with 2 to 3 entries, each with a direct link to the live work. No landing page, no portfolio site, no introduction needed. The reviewer clicks the link and sees the project.
I got hired using exactly this. 3 project links on my resume -- 2 Tableau dashboards on Tableau Public and 1 Power BI project -- with no portfolio website tying them together. Each link went directly to the work. That was enough.
The risk with this approach is link reliability. A broken link on a resume is worse than no link at all. It signals either that you didn't test your own application materials or that the project was taken down. Test every link before submitting any application. Don't assume the link you bookmarked 3 weeks ago still works.
GitHub is the standard. It's free, it's where the industry expects to find code-based work, and it's already familiar to most hiring teams. A SQL portfolio project on GitHub should have:
The README is the most important element. A reviewer who lands on your GitHub repo should understand the project within 30 seconds without reading any SQL. The README is what earns the next 30 seconds of attention where they actually look at the queries.
Keep your GitHub profile clean. Pin your best 2 to 3 repositories so they're the first thing visible. A profile with 15 half-finished repos and no clear structure suggests disorganization, not prolific output. Pin the ones that are finished and strong, and leave the rest unpinned.
One note on GitHub repo names: use descriptive names that communicate what the project does, not generic names like "sql-project-1" or "analytics-work." "retail-customer-retention-analysis" tells a reviewer what they're about to see before they click in.
Power BI is the most friction-heavy tool to share publicly, which is a real limitation for portfolio use. Your options, from easiest to most reliable:
Power BI Service with a free account and public embed. Microsoft's free Power BI account lets you publish reports to the web via a public embed link. Go to File → Publish to web, generate a public link, and paste that in your resume. This is the cleanest solution when it works. The limitation: the report loads in a browser window and relies on your Microsoft account staying active. Test it before every application batch.
GitHub with the .pbix file and a PDF export. Upload the .pbix file to GitHub so reviewers can download and open it in Power BI Desktop. Alongside it, export key pages as a PDF or PNG and include those in the repo so reviewers can see the output without downloading anything. This works reliably because nothing depends on an external service staying live. The trade-off: it's not interactive in the same way.
A recorded walkthrough on YouTube or Loom. A 3 to 5 minute screen recording of you walking through the dashboard -- showing the interactivity, explaining each page, walking through the data model -- hosted publicly on YouTube or Loom and linked from your resume. This has the added benefit of demonstrating your communication skills alongside the technical work. It's a stronger move than most candidates make.
Avoid hosting Power BI dashboards only in your Microsoft organizational account. They're not publicly accessible without a Pro license and an explicit share, which creates friction that most reviewers won't push through.
Tableau Public is the answer. It's free, it hosts dashboards publicly by default, every dashboard gets a shareable URL, and it's what Tableau users in the analytics community expect. If you built it in Tableau, it goes on Tableau Public.
The limitation worth knowing: anything you publish on Tableau Public is visible to anyone. If your dashboard uses sensitive or proprietary data, Tableau Public isn't the right place for it. For portfolio work using public datasets, this isn't an issue.
Set up your Tableau Public profile properly. Add a profile photo, a brief bio, and organize your published workbooks so the best ones are featured. Tableau Public profiles show up in searches and your resume link may lead a reviewer to your profile rather than a specific dashboard. Make sure the profile looks intentional, not abandoned.
Name your Tableau Public workbooks descriptively. "Customer Retention Analysis -- E-Commerce Transactions" is better than "Dashboard 3" both for the reviewer who sees it and for Tableau's own search and discovery.
GitHub again, with Jupyter Notebooks (.ipynb files) rendered directly in the browser. GitHub renders notebooks natively, which means a reviewer can see your code, output, and markdown commentary without installing anything. This is a significant advantage over other sharing methods.
Structure a Python portfolio project on GitHub the same way as a SQL project:
Clean the notebook before publishing. A notebook with 40 cells of exploratory dead ends, commented-out code, and error outputs that were never cleared reads as unpolished. Run the notebook clean from start to finish, clear all output, re-run it, and publish that version. What you publish should be the polished output, not the working draft.
If the project involves visualization, make sure the charts render in the GitHub preview. Some chart types from matplotlib render correctly; others require additional configuration. Test the GitHub render before linking it from your resume.
Excel is the trickiest tool to share in a portfolio because the file format doesn't render interactively in a browser. Your options:
Google Sheets with view-only sharing. Upload the Excel file to Google Drive, convert it to Google Sheets, and share it with a view-only link. Reviewers can see the structure, the formulas, and the output in a browser without downloading anything. This is the most accessible option for most reviewers.
GitHub with the .xlsx file and a screenshot or PDF of key views. Same pattern as Power BI: upload the file for download and include screenshots or a PDF of the key output so reviewers can see the work without opening Excel. Include a README that explains the question and the finding.
A recorded walkthrough. For complex Excel models -- financial models, multi-sheet analyses with lookup chains -- a recorded walkthrough often communicates more than a static file. 3 to 5 minutes, screen recorded, walking through the logic.
Excel is less commonly featured as a standalone portfolio project than SQL or BI work. It's more often supplementary -- mentioned in the resume description of a project rather than linked as its own piece. If your strongest work is in Excel, host it, but understand that it's not the primary signal most hiring managers are looking for in the analyst stack.
No. Not as a prerequisite to applying. Not as a hiring requirement. Not as something that costs you interviews if you don't have it.
A portfolio website is a nice-to-have for differentiation once the core job search materials are already strong. If your resume is polished, your projects are solid, your LinkedIn is complete, and you've been applying with reasonable volume, a portfolio website might add a marginal edge. It won't fix a weak resume or a portfolio project that doesn't answer a real question.
The opportunity cost is real. Building a portfolio website takes time that most job seekers in active search mode don't have. That time is almost always better spent on SQL practice, a stronger project, more applications, or networking outreach. The analysts I see get hired fastest are the ones who spent their time on the job search itself, not on auxiliary assets.
If you do build one, keep it simple: your name, a brief intro, links to your projects with 2 to 3 sentence descriptions of each, and contact information. No animations, no elaborate design, no blog section you'll never update. Simple and functional beats complex and slow to build.
Free options that don't require web development skills: GitHub Pages (renders from a GitHub repo), Notion (shareable pages with clean formatting), Carrd (simple one-page sites), and Google Sites. Any of these work. None of them are necessary.
Broken links. This is the single most avoidable failure in the portfolio process, and it happens constantly.
A Tableau Public dashboard that was published under an account that's been inactive gets delisted. A Power BI Service embed that was published under a free account with an expired Microsoft 365 trial stops working. A GitHub repo that was set to private after a clean-up sweep. A Loom video deleted when the recording account was cleared.
The fix is simple: test every link within 24 hours of submitting any application. Not once when you build the resume. Every time you submit. Set a reminder if you need to. A broken link on a resume is the kind of detail that makes a hiring manager wonder what else you missed.
If you want a structured approach to building projects, hosting them correctly, and putting together a resume that frames the work effectively, the Analyst Hive program covers all of it in Month 1. The hosting setup is part of the project build, not an afterthought.
Is GitHub necessary for a data analyst portfolio?
Not strictly required, but it's the industry standard for code-based work. SQL and Python projects belong on GitHub because that's where hiring managers expect to find them and because GitHub renders both natively in the browser. If you don't have a GitHub account yet, creating one is free and takes 10 minutes. Your profile should be clean, your repos should be named descriptively, and your best work should be pinned.
Can I link to a Google Drive folder instead of GitHub?
You can, but it reads as less professional than GitHub for code-based projects. Google Drive works as a backup option for Excel files or PDFs of dashboard exports. For SQL queries and Python notebooks, GitHub is the right place. The difference matters to reviewers who work with these tools daily and have expectations about where code lives.
How do I make my Power BI dashboard publicly accessible?
Use File → Publish to web in Power BI Desktop after publishing to Power BI Service. This generates a public embed link that works in any browser without a Microsoft account. Alternatively, export the report pages as PDFs and host them on GitHub alongside the .pbix file. Test whichever method you use before linking it from your resume -- the Publish to web option occasionally requires organizational account settings that may not be available on free accounts.
Does Tableau Public hurt my chances if the data is public anyway?
No. Public datasets used for portfolio projects are expected to be visible. Tableau Public exists specifically for this use case and is widely accepted as the standard hosting platform for Tableau portfolio work. The only scenario where Tableau Public is inappropriate is if you're trying to show work that uses proprietary or sensitive data -- in that case, a recorded walkthrough or anonymized version is the better approach.
Should I put my portfolio link in my resume header or in a projects section?
Both, if you have a portfolio website. Put the site URL in the header alongside your LinkedIn and GitHub profile links. In the projects section, link to individual projects directly rather than to the site. Reviewers who want to see everything go to the site; reviewers who want to see a specific project go directly. If you don't have a site, link each project individually in the projects section and add your GitHub profile link in the header.
How long should a Loom or YouTube walkthrough be?
3 to 5 minutes for most portfolio projects. That's enough time to walk through the question, the data model, the key pages of the dashboard or the core queries, and the main findings. Longer than 5 minutes and most reviewers won't watch to the end. Shorter than 2 minutes and you probably haven't explained the data model or the analytical decisions. Practice the walkthrough before recording -- a halting, backtracking 4-minute walkthrough is less effective than a clean 3-minute one.
If you want a complete job search setup -- projects built, hosted correctly, resume framed, and LinkedIn ready -- the Analyst Hive program walks through all of it step by step. Daily tasks, structured around getting hired.
