Skip to main content
Hashnode
Pranaav Karthik

How College Students Can Build a Strong GitHub Portfolio

Updated 8 min readMarkdown
P
Pranaav Karthik

Most student GitHub profiles look the same. A few repos named test, project1 or untitled, no descriptions, and a README that says nothing. Anyone who opens that profile learns almost nothing about you.

A portfolio does not need to be big. It needs to be clear. Here is what I think makes a student profile worth opening, and one lesson I took from studying someone else's project.

Why GitHub counts as a portfolio

You are a student, so you probably do not have work experience to list. Your repos fill that gap. They show that you can finish something, explain it, and put it where others can run it.

I am not saying a profile gets you a job. I am saying it gives someone something concrete to look at instead of just a line on a resume.

Pick projects that solve something

Tutorials teach you tools. Projects show you can use them. Some ideas that are small enough for a college semester:

  • A tracker for something you actually use. Expenses, attendance, gym log, study hours.
  • A data project on a public dataset. Clean it with Pandas, answer a few questions, show charts.
  • A small web page or tool. A unit converter, a quiz app, a timetable generator.
  • A script that saves you time. Renaming files, merging Excel sheets, scraping a notice board (check the site's rules first).
  • A C++ or Python version of a classic. A bank system, a library manager. Fine for fundamentals, but add something of your own so it is not identical to every other one.

Rules of thumb:

  1. Choose something you can finish in a few weeks.
  2. Choose something you can explain in two sentences.
  3. Prefer one finished project over five half-done ones.

If you are unsure where to start, How to Build an Interactive Dashboard Using Python and Streamlit builds a small interactive dashboard step by step.

Keep each repo tidy

A messy repo hides good work. Here is a simple layout for a small Python project:

expense-tracker/
├── README.md
├── requirements.txt
├── .gitignore
├── app.py
├── src/
│   ├── __init__.py
│   └── tracker.py
├── data/
│   └── sample_expenses.csv
└── screenshots/
    ├── home.png
    └── report.png

What each piece is for:

Name repos in plain words: expense-tracker, not project_final_v2. Fill in the one-line description box on GitHub too. It shows up in search and on your profile.

Write a README people can use

The README is the part most visitors read, and often the only part. Assume the reader is in a hurry and has never seen your project.

Include:

  1. What it is, in one or two sentences.
  2. A screenshot or GIF.
  3. Features, as a short list. Only list what actually works.
  4. Tech used.
  5. How to install and run it. Commands they can copy.
  6. What you would improve. Honest and short.
  7. Credits and licence, if you used anyone's code or data.

Here is an example you can copy and adapt. The project name and features are made up for illustration.

# Expense Tracker

A small command-line and Streamlit app to log daily expenses and see
monthly totals by category.

![Home screen](screenshots/home.png)

## Features
- Add, edit and delete expenses
- Monthly total per category
- Export to CSV

## Tech
Python 3.10, Pandas, Streamlit

## Run it locally
```bash
git clone https://github.com/your-username/expense-tracker.git
cd expense-tracker
python -m venv .venv
source .venv/bin/activate      # Windows: .venv\Scripts\activate
pip install -r requirements.txt
streamlit run app.py
```

## Sample data
`data/sample_expenses.csv` has 50 made-up rows so you can try it.

## What I would improve
- Add tests
- Support multiple currencies

## Credits
Category icons from [source]. Dataset structure inspired by [link].

Test your install steps on a clean folder, or ask a friend to try them. If the steps fail on someone else's laptop, the project looks broken however good the code is.

Screenshots do a lot of work

Most people will not clone your repo to see what it does. A screenshot answers that in two seconds.

  • Take screenshots at normal window size, with sample data (never real personal data).
  • Save them in a screenshots/ folder and link them with relative paths.
  • For apps with several pages, show two or three of the best, not twelve.
  • A short GIF of the main action is even better. Free tools like ScreenToGif (Windows) or Peek (Linux) can record one.

Host it if you can

A live link beats a screenshot. If your project is a web page, GitHub Pages is free. If it is a Streamlit app, Streamlit Community Cloud can run it from your repo. How to Deploy a Python Streamlit Project Online (Free, Step by Step) walks through that.

Put the live link near the top of the README. If a project cannot be hosted, like a desktop or C++ program, a short demo GIF does the same job.

Pin and describe your profile

Your profile page is the front door:

  • Pin your best 3 to 6 repos.
  • Add a profile photo and a short bio: what you study, what you are learning.
  • Create a repo named exactly the same as your username. Its README shows up on your profile. A few lines about you and links to your best work is plenty.
  • Commit regularly. You do not need a green square every day, but a profile that went quiet two years ago looks abandoned.

Studying other people's projects, honestly

This part is where I want to be straight with you.

Learning from other people's code is normal. Reading a good project is one of the fastest ways to see how a real app is organised. I did this with an open-source Superstore sales dashboard by Asha Kalavagunta. It is built with Python, Pandas and Streamlit, and I went through its code to understand how the data cleaning, charts and filters fit together. What I Learned Studying a Python Sales Analytics Dashboard (Streamlit + Pandas)

What I took from it was a clear lesson about my own portfolio. A copy of someone else's project on my GitHub does not show what I can build. It shows that I found a good project. Those are different things, and a recruiter or teacher can tell the difference in about a minute.

So here is how I think it should be done:

  1. Fork or copy it openly. Use GitHub's Fork button. It keeps a visible link back to the original, so nobody has to guess where it came from.
  2. Keep the original credit. Leave the licence and the author's name in place. Check the repo's licence for what you are allowed to do. If there is no licence, ask the author before reusing the code.
  3. Say what it is in your README. Something like "Forked from X. I studied this to learn Y." Do not describe it as something you made.
  4. Keep it out of your pinned repos if it is not your work, or label it clearly as a study fork.
  5. Then build your own. Take what you learned and make a different project. Same techniques, new idea, your own code.

This is not about feeling bad. Everyone starts by reading other people's work. The only real mistake is putting that work on your profile as if you wrote it. It is easy to avoid and it keeps your profile believable.

For me, the next step is simple: use what I learned about Pandas, Streamlit and project structure to start projects of my own, and put those up front. From Learning Programming to Building Real Projects: My Student Developer Journey

A quick checklist before you share your profile

  • Every pinned repo has a description
  • Every pinned repo has a README with a screenshot
  • Install steps tested on a fresh folder
  • No passwords, API keys or .env files committed
  • Borrowed code is credited, forks are labelled
  • Repo names are readable
  • Profile bio filled in

Wrap-up

A strong student portfolio is a few finished projects that you can explain, with READMEs that someone can follow in five minutes. Pick something useful, keep the repo tidy, add a screenshot, host it if you can, and be clear about which work is yours.

You can see my profile at github.com/Pranaav717. It is a work in progress, and I will be adding my own projects there.

Comments

Join the discussion

No comments yet. Be the first to comment.

More from this blog