A GitHub portfolio for data analysts: the repo structure recruiters actually read
Most GitHub portfolios are structured for the person who built them, not the recruiter who opens them for forty seconds. Here is the profile setup, the three-repo strategy, and the one repository structure that survives a recruiter's skim, plus what GitHub alone cannot show.
A recruiter who clicks your GitHub link gives it somewhere between thirty seconds and a minute. In that window they will see your profile page, maybe open one pinned repository, and read the first screen of its README. That is the whole audit. A GitHub portfolio for data analysts is therefore not a code storage problem, it is a layout problem: put the right things in that forty-second path and cut everything else.
The forty-second path, in order
Optimise the three things a visitor actually encounters, in the order they encounter them.
- 1
The profile README
Create the special repository named after your username and give it a short README. This is your homepage on GitHub, and most analysts leave it empty. One line of positioning, three linked projects each with the finding it produced, and your contact links. No skill-badge walls, no GitHub stats widgets: they read as decoration, not evidence.
Questions to ask- Who you are and the role you want, in one line
- Your 3 best projects with one-line findings
- Links: portfolio page, LinkedIn, email
- 2
Three pinned repos
Pins are the only repositories most visitors ever open, so curate them like a shopfront. Three finished projects that together cover the analyst workflow beat six mixed ones. If you are short a project or two, the briefs in 10 data analyst portfolio project ideas are designed to fill exactly these three slots.
Questions to ask- One SQL project
- One Python cleaning and analysis project
- One dashboard or end-to-end project
- 3
The first screen of each README
Before any table of contents or install section, a visitor should see what you asked, how you answered it, and what you found. If the finding is "churn is concentrated in month two and driven by onboarding drop-off", say that in the README's first screen. Recruiters hire findings, not folder trees.
Questions to ask- The business question as the title
- Approach in 2 or 3 sentences
- The key finding, stated as a number
One repo structure that works
Inside each project, use the same predictable layout every time. Consistency across your repos is itself a signal: it looks like someone who has shipped work before.
README.md
The front page. Question, approach, and finding at the top, then data source, decisions and caveats, and how to reproduce. Screenshots of key charts inline, because most visitors will never run anything.
Analysis notebooks
Numbered in reading order: 01-cleaning, 02-analysis. Run them top to bottom before committing so outputs are visible, and clear the dead-end experiments. A notebook is a narrative, not a lab bench.
Queries
Each query in its own file, named for what it answers, with a comment block up top stating the question and the grain of the result. Ten well-named files beat one 800-line script.
Exported charts
Export your best charts and dashboard screenshots here and embed them in the README. This is what makes a repo skimmable: the visitor sees the output without running a line of code.
Add a small data folder if the dataset is public and light, or a line in the README explaining where the data lives and how to get it. Never commit credentials, and use a .gitignore from day one. If Git itself is still shaky, our Git for data cheat sheet covers the dozen commands and habits that account for nearly all of an analyst's daily use.
What to cut
Deletion is half the work of a good GitHub portfolio. Every repository a visitor can see is part of the impression, and a recruiter judges the shelf by the weakest item on it.
- 3 finished projects with documented findings
- A profile README that positions you
- Screenshots and rendered outputs
- Descriptive repo names and commit messages
- A pinned order that tells a story
- Course exercise dumps and tutorial follow-alongs
- Forks you never touched
- Abandoned experiments and empty repos
- Repos named test, final-v2, or untitled
- Notebooks with no markdown and no outputs
The cleaning matters more than juniors expect. Coursework repos in particular actively hurt: they tell the visitor you are a student, when the entire point of a portfolio is to look like a colleague. Archiving is reversible and takes seconds, so when in doubt, archive; you can always restore a repo the day it earns its place back. And messy data handling is a story worth telling properly in one dedicated project, decisions documented against a real data cleaning checklist, rather than implied by twenty scrappy notebooks.
A repository is read like a landing page, not like code. If the finding is not on the first screen, it does not exist.
Getting the link in front of people
A tidy GitHub profile that nobody visits is a well-organised drawer. The link needs to sit everywhere a recruiter already looks. Put it in your CV header next to your email, not buried in a links section at the bottom. Put it in your LinkedIn profile's website slot and mention your best project, with its finding, in your About section: "analysed 500k ride-share trips and found demand pricing missed the evening peak" earns a click in a way "my GitHub" does not. When you apply for a role, reference the single most relevant project in the application itself rather than the profile as a whole, because a link to one great README converts better than a link to a list of repositories.
Two small settings compound this. First, fill in the About field of each pinned repository with the one-line finding, since that text shows on your profile under the pin. Second, add topics like sql, data-analysis, and power-bi to your repos: some technical hiring managers do search them, and the tags cost nothing.
The honest limits of GitHub alone
GitHub is necessary, but it was built for engineers reviewing code, not recruiters evaluating analysts, and the gaps show. Notebooks render slowly or not at all. Dashboards, the most persuasive analyst deliverable, cannot be experienced there. Nothing distinguishes a project that works from one that merely exists. And a wall of repositories has no visual hierarchy: your best work sits in the same grey list as everything else.
That is why the setup that wins both audiences is a pair: a hosted portfolio page as the front door, GitHub as the code layer behind it. The page gives the recruiter a visual, skimmable minute (this is the publishing step of how to build a data analyst portfolio); the repos give the technical interviewer depth when they want it. On D8A this pair is built in: each guided project you finish is checked by an automatic structural validation of your GitHub repository, then published to your public portfolio page with your own titles and descriptions, linking back to the repo. The recruiter gets the presentation, the interviewer gets the code, and you get credit for both.