On this page
A recruiter or interviewer may open your GitHub link from your resume. If they find a clear README and code that runs, that is a good sign. If they find forty empty or copied repositories, it hurts you. This guide shows how to keep a small, tidy portfolio that helps.
A clear name, a short bio and pinned repositories.
Your two or three best projects.
What it does, how to run it, what you found.
Tidy folders, clear file names and no secrets.
A clear picture of what you can do.
How many projects to show
Two or three. Choose projects that show different things, for example one SQL analysis, one Python data cleaning script or pipeline, and one dashboard or report. Delete or hide repositories that are empty, copied from a tutorial without changes, or unfinished. You can make them private.
If you are not sure what to build, pick a project from the projects page. Each one has a README template.
What a good repository looks like
sales-report/
README.md
data/ (small sample files only)
sql/ (your queries, named by what they do)
src/ (Python scripts)
requirements.txt
.gitignoreUse clear names: monthly_revenue.sql is better than query1.sql. Keep data files small. If your data is large or private, include a small sample and a note on where to download the full data.
The README template
Most visitors read only the README. Write it for someone who has never seen the project.
# Sales report in SQL and Python
## What this does
Cleans a file of 50,000 orders and answers four questions: revenue by month, top products, repeat customers and returns.
## Data
Public sales data from <source>. Sample in /data.
## How to run it
1. pip install -r requirements.txt
2. python src/clean.py
3. Run the queries in /sql in order.
## What I found
Revenue peaks in November. 18 percent of customers ordered more than once.
## What went wrong
The first join counted some orders twice. I fixed it by joining at the order level and added a row-count check.
## What I would do next
Schedule the script to run each day.The section called What went wrong is the most useful one. It shows how you think, and it gives you a story for the interview.
Safety check before you push
- Never commit passwords, API keys, tokens or database addresses. Put them in a file that is listed in .gitignore, and read the repository once before you publish it.
- Do not upload real personal data about other people. Use public or made-up data.
- If you accidentally commit a secret, treat it as exposed. Change the key at the provider, then remove it from the repository.
- Check the licence of any dataset you use, and say where it came from.
A tidy profile
Add a photo or avatar, your name and a one-line bio such as Final-year student learning SQL, Python and data pipelines. Pin your best two or three repositories. Optionally add a short profile README with your skills and links to your projects.
Commit steadily while you work on a project. A history of small commits over a few weeks looks natural and shows how the project grew. Do not fake a streak by committing empty changes. Reviewers can tell, and it does not help.
What interviewers ask about your repository
Be ready to explain every file. Typical questions: why did you structure it this way, how would it handle ten times more data, how do you know the numbers are right, what would you change. If you copied a tutorial, say so and explain what you changed and why.
Where to start today
Open your GitHub page and list every repository. Hide or delete the ones that are empty or unfinished, then pin the best two.