For newer grads, focus on your project work; more senior developers will focus on open-source contributions here.
The first project a new grad lists should be, in this order:
Other projects listed afterward should reflect the skills and technologies in the job post or reflect the company culture (ie, if they care more about teams, perhaps list more group projects). An example layout for presenting your projects is given later in this document.
A live URL on your projects is worth a thousand GitHub repos. I would much rather EXPERIENCE a working project on a free Heroku instance than pouring through page after page of code in GitHub wondering if the code you wrote even works. Please don’t ever assume the person reading your resume has any technical experience, nor plenty of free time to figure out how to build your project to test if it does work.
If there’s no possible way to let me experience your live project, then a GitHub link will be fine, but whenever possible, use the many free tiers of online cloud hosting platforms to get your project online.
Your project names should match your GitHub repo names. If not, change the repo name. Also, don’t list a URL for a GitHub repo that points to some other user’s account. Fork the project at a minimum, but since forked repos disappear if the original gets deleted, it’s better if you create a new repo of your own and push a copy of the other repo to your own account; all contributions will be maintained, but you won’t risk losing the repo later.
If you use a service other than GitHub, like BitBucket, by all means substitute that wherever I refer to GitHub.
It’s important for me to see which of your projects were group projects, solo projects, pair programming projects, etc., but in the case of a group project it’s vital that I also know what your role was on the team. Did you act as project lead? Were you in charge of all data modeling and persistent storage? Did you implement the UI/UX of the project?
Here’s a super concise way to present a project on your resume:
The title of your project should match your github repo name; if they’re mismatched, you should consider changing your repo name.
As a hiring manager, I also get to see if this was a group or solo project, which sets my expectation around how much of this work was yours. Even if you leave this off, I might still check the “contributors” area of GitHub to see how much of this project you were actually responsible for.
Finally on this first line is a live URL. I’d much rather EXPERIENCE live code than BROWSE code, so please try to host your project online somewhere. If I care about the code, I’ll look for “My Awesome Project” within your GitHub repos. Having a live hosted project proves you can write WORKING code, which is much more important.
When it comes to describing your project, first and foremost, start describing the project with an “elevator pitch” of what the user does on the site, not “I made this excellent Flask app with Stream and React”. If you had to sell this project as a business investment to a venture capitalist, you would need to get them excited about why users will care about what you’ve built. This is known as a “user empathy” statement and shows you care about the user, not just the technology.
The first bullet point should tell the reader something geeky/fun/interesting about how you built the project. The second bullet point is only necessary for group projects and tells me your role on the team. The final bullet point is your tech stack for building the project.