Pathrise Step-by-Step Guide:

GitHub Optimization
13 Steps to Getting the Best GitHub Profile Possible

GitHub

GitHub is a popular platform that technical hiring managers look at for every
coding-centric technical position. Follow every step below to maximize your
GitHub profile for Technical Recruiter outreach and increased opportunities for
technical jobs.

Prerequisites
This Guide is intended for Week 2 and later of the core Pathrise Program.
Before following the below steps, you must first have attended or watched
Pathrise Workshop 1: Profile, read through the slides or documentation on
Writing a Good Resume, spent time rewriting and focusing heavily on Context,
Impact, Quantification, and Skill Keywords of all your Experiences, have met
your Mentor to review and discuss further changes and optimizations, and
have implemented all those necessary changes to the core body content of all
your Experiences. There is a LinkedIn Optimization guide that we suggest you
also complete before starting here since there are more recruiters than there
are technical recruiters and optimizing your LinkedIn will have a wider impact.
With the above complete, the following GitHub optimization steps can be
completed.

GitHub Step-by-Step Optimizations

Your GitHub profile is an important and often overlooked element to help aid in your job search.
Remember that just as you are looking for a good company to work at, good companies are
looking for good coders too! Having a strong GitHub profile helps because it allows hiring
managers to at least gauge if you follow best practices and coding principles.

Profile
Profile Picture

1. Update your profile picture and make sure it has all the following
attributes:
a. Mostly front-facing (focus on the eyes)
i. You don’t need to be facing directly at the camera (we all
have our good sides), but the part that leads to connections
is making sure your eyes are aimed at the reader (the
camera)
b. High resolution and clear
 i. Any modern smartphone will be way more than capable
here, but some people choose a photo where they are
small, and then crop down, substantially, generally reducing
the resolution by up to 90%. Do not do this.
ii. You should not be blurry or out of focus in any way.
c. Bright
i. Edit you photo (such as in the Google Photos or Apple
Photos app) and up the Exposure, and Whites, and
potentially reduce the Blacks, to help brighten and soften
the entire photo
d. Smiling
i. Smiling candidates give off a generally friendlier vibe, and in
a recent study were selected 25% more often than non-
smiling counterparts.
2. It is absolutely worthwhile to spend 10 minutes to retake your GitHub
picture, edit it, and upload it. Many candidates at this stage think “my
current pictures are mostly good enough”, and then continue on. If you
are not meeting the requirements above, then this is non-optimal and it
is absolutely worthwhile to upload a new picture than will help with
conversions on connections and messaging.
3. You can ask your mentor if you have questions if your headshot is
appropriate
Profile Bio

4. The Profile Bio only allows for ~30 words before it stops letting you
type. This is unique compared to both the Summary section of your
resume and the About Me section in your LinkedIn profile and it forces
you to really distill your personality down to a couple of sentences. You
want to spend a good amount of time figuring out how to optimize this
area. Let your personality be your guide, but try and show a little bit of
yourself and not just list off a bunch of technologies you use. Don't copy
us! Be unique!

Profile Links
 5. The links section is easy to forget because it's small but it allows for
recruiters to bi-directionally find you – whether they are browsing
LinkedIn, your personal website, or your GitHub. Feel free to put your
personal website in the link section if you have one and if you don't, be
sure to still put your LinkedIn in there!
● Side Note: The location section occasionally confuses people.
What if you live on the East coast, but want a job on the West
coast? The simple rule of thumb here is that you should set your
location wherever you currently are looking for a job. If you're
primarily looking at places on the West coast it doesn't matter
where you live, just put somewhere on the West coast in the
location section. San Francisco, CA for example.

Bonus Tip 1: Untick “Keep my email address private” in the email settings of
your account so people (like recruiters and hiring managers) can easily contact
you.

Bonus Tip 2: Tick “Available for hire” since you’re looking for a job!
Optimizing Your Repository Hub

Pinned Repository Section

6. Did you know that you can pin repositories to make them stay front-
and-center in your profile? Now you do! Handpicking your most
impressive repositories and choosing to pin them can be a great way to
showcase the accomplishments you're most proud of. Got a mix of
backend and frontend work, but you've decided to look for frontend
roles in your job search? Pin that great React project you built so people
can see it!
Bonus Tip 3: Avoid pinning tutorial-centered projects if it's obvious you didn't
write a majority of the code. Great sites like Udacity offer plug-and-play
projects that take only hours to complete but leave you with a realistic clone
of a popular app. Tread carefully because if it was a popular course it's very
likely that your recruiter has seen the project before. Everything from your
commit history to your knowledge about the technology indicates what you
really did. Work on beefy projects if you get a chance, but be careful not to
falsely advertise your accomplishments.

Delete Forks You Haven't Contributed To

7. Some people wear the number of repositories in their GitHub as a badge

of honor, but since forking a repo only takes seconds most recruiters
don't find this impressive and at Pathrise, neither do we. If you have a
ton of repositories forked but haven't ever contributed to them, then
just delete the repository. If you want to keep track of the project, use a
start – that's what they are there for. 🙄

...Speaking of Stars

8. Starred repositories ideally should reflect your interests. Take a peek at

this section and ensure that your interests are still accurately reflected.
If you learned Java ages ago and starred a bunch of repositories but
now want to work in frontend languages, you should remove these from
your starred list.
Grooming Your Pinned Repositories
Now that you've pinned your most important projects and you're ready to
showcase them, take a good look at each one and determine what is missing.
Each repository should have all of these attributes at a minimum. Let's take a
look at each of them in more detail.

A Killer ReadMe
9. For any coding project you ever work on, the most important section
will always be the Readme. You can write code that successfully passes
the Turing Test and if nobody understands your repository or what it
was you were working on then it's totally useless. While many things
can lead to a killer ReadMe, things that simply must be included inside
of each ReadMe are:

- Title: Pretty self-explanatory here, but try to keep it short and sweet. Bonus
points if it's clever in some way i.e. a Slack clone called DeEm (sounds like
DM)
- Project Overview: What did you work on? Why did you work on it? What was it
supposed to do? Be descriptive here and avoid acronyms or announcing that it
was "just a school project."
- Mark Up with Markdown: Use appropriate markdown syntax to break out your
ReadMe into logical sections.
- Illustrations: A picture is worth 1000 words, right? Got a video of your project
or a GIF of it working? Perhaps a link to a live demo? Is your application
something you can show? Don't be too quick to say "No" here. Terminal
applications are ok and the app doesn't have to be pretty or even interactive. If
you don't have it working, perhaps you have a mockup of what you were
intending to do?
 Mockup of frontend project example

Successful test suite on backend project example

- Project Status: Have a cool project that you never finished (and maybe never
will)? That's ok! Mark it as under construction and show what you have
anyways! The stage of the project doesn't preclude you from showing it.
Fellows assume that the project needs to be finished and bug-free before it
can be displayed, but since hiring managers rarely scrutinize code that closely
it's not important. If you truly made very little progress on the project, just
throw up a banner indicating that it's still in progress.
- Scope of Functionality: What does your project do? Equally important, what
does it not do? List out anything that you know is missing (e.g. Slack clone has
no support for file attachments).
- Known Bugs: Keeping a bug log may seem like a bad idea since it highlights
that you have bugs in your code, but trust us this is a great thing to see. We
already know your code has bugs in it (😂), the question is how you're handling
them. Keeping a small log of what you need to fix is a great way to show that
you're a rockstar engineer 🎸
- Prerequisites: If you include the installation section below, be sure to list
prerequisites and assumed dependencies here (Homebrew, Python3, etc).
- Installation: If it's possible to install and run locally with minimal effort
include installation instructions. Don't be the person that says "try out my
code" with no clear way of doing so. Don't forget examples of how to run it
along with any necessary configuration changes!
- Commands to Run Tests: Every good developer has tests for their bigger
personal projects. While I'm sure your repositories already have robust testing
behind them, if you know anyone else (😂) that is lacking even a simple testing
suite in a substantive project it may be worth letting them know that this is
something worthwhile to include. After doing that, be sure to show how to run
the tests in your ReadMe.
- Technologies Used: What was your stack? Why did you go with that stack? It's
ok to say that you were just wanting to learn a cool technology!
 - Pointer to the "cool" stuff: Got a lot of boiler-plate code for the project? Don't
make them guess. Directly link in the ReadMe to the cool stuff you
implemented.
- Credits: Build off of another cool project idea? Do the right thing and link to
their repo and give them credit. It doesn't make you less hirable.

Bonus Tip 4: If you made a publicly available demo of your application, but it
requires a user to sign in – or worse, make an account – please add a dummy
username and password and share it on your ReadMe close to the clickable
demo link. Very few things are more frustrating than trying to see a potential
candidate's live demo and then clicking the link only to find that we have to
go through a janky 5-minute account creation process before being able to
see anything of substance. Just list an account with dummy data that the
hiring manager can immediately log into and take a peek at.

Bonus Tip 5: If you need more inspiration/guidance on constitutes a great

ReadMe, check out this repository which contains nothing but a collection
projects that have beautiful ReadMes.

Up-to-Date License
10. This one is easy yet so many people don't include it on their
repositories. You don't have to have a working project to give people
permission to use it. The standard license is usually good enough and
shows good forward-thinking habits to be included. You can include it
as you create your project or feel free to grab one from here if you're
looking to add one retroactively.
Forward Thinking Parts of Your GitHub
Some parts of your GitHub you can't realistically edit, and even if you could it
probably wouldn't be a good idea. However, as part of your job search, you
will likely need to beef up your profile with good projects that demonstrate
hireable skills. This means projects that will take more than a day to
complete. These are perfect opportunities to make sure you're constantly
polishing your GitHub profile – making it look better with every commit!
Contributions Chart

11. The contributions chart is something that comes up often during profile
reviews as many fellows are nervous about it. The chart is intended to
detail your coding habits, but realistically, it more likely details your
version control habits. Many fellows find themselves in a situation
where they have a very sparse amount of contributions in their chart,
even if they code fairly regularly. This is ok. There are lots of valid
reasons to have very empty sections of this chart. While it's possible to
edit your contribution history and make it look better (and if you wanted
to go the extra mile, you certainly could spell something out like "hire
me" using one of the many free contribution history editors), it certainly
isn't required. No reputable company will base a hiring choice on this
chart, although it can be a positive signal to a recruiter.

Since it is a timely and unproductive use of our time to try and edit the
chart, the recommendation, is to simply understand why there are gaps
if there are gaps and being able to explain these gaps if necessary. Went
on a trip last May to France? Perfect. No one expects you to have coded
then, but make sure you remember it in case you're asked about it.
Commit History - Quantity

12. How many commits do you have for any single project? What about
branches? If you have substantive projects on your GitHub that took you
days or even weeks to complete, nothing is more disappointing for an
engineer to find on your repository than a single solitary commit or a
small number of commits. You claim to have worked on this project for
three weeks but only have three commits? This shows terrible version
control habits and probably also explains the lack of activity in the
contribution chart too. You shouldn't try editing git history to change
this, but take this as a learning opportunity and start following the
programmer's mantra "Commit early. Commit often."
Commit History - Quality

13. Ok, maybe you've worked on your project and followed good version
control habits and are commit frequently, but what's the quality of
those commits? Does each commit show clearly what you did? Does it
tell a story? A helpful way to think about Git history in general in terms
of What, Why, and How. The code in your code commit shows the How
(i.e. How you did what you did). Your commit message should reflect the
What and the Why. The adopted structure of a good code commit
typically follows the following pattern:

<What it is that you changed>

<Why it was necessary to change it.>

If you're curious why this is the convention and is considered a best

practice you can read about it in many places. I recommend Tim Pope's article
for more details here.

Bonus Tip 6: Many developers aren't even aware that you can write a
paragraph in the git commit message. This usually is because of the bad habit
of committing with the git message flag rather than with the Git editor.
Instead of doing this in your terminal when committing some code…

git commit -m "subpar way of writing a git commit message"

Try this instead...

git commit

… and this will drop you into your default editor (probably Vim). Note that
your default editor is changeable if you prefer Nano or something else. See
GIF below.
Bonus Tip 7: The paragraph below the first line in the Git message (the Why) is
hidden on GitHub by default but easily viewable with a simple click and many
developers are also unaware of this too. Check out the graphic below.

If you followed the above 13 steps and bullet points, you should now have an
amazing and optimized GitHub profile, ready to be shared with the world.
Make sure your GitHub URL is on your resume, and is clickable in pdf format,
as some people prefer viewing GitHub profiles in addition to a candidate's
resume (and often the GitHub URL is parsed out and given its own section in a
resume ATS).