New Dev? Job-Hunting? Avoid These GitHub Mistakes!

Enjoy content similar to this post on Arit, Developer!
Subscribe to Arit's Newsletter to receive quasi-monthly emails whenever she publishes a new story.

In recent weeks, several developers looking for their first dev job have asked me to review their resumes and/or portfolios, and give them tips on how to improve their profiles. Many of the issues I flagged appeared in most of the profiles I reviewed, so I decided to write this piece with some (unsolicited ) advice on how to avoid a flat, one-dimensional GitHub profile as a new software developer. The reality is that the market for new devs is becoming increasingly competitive, on account of more and more coding bootcamps churning out entry-level developers by the month. I think that the time spent crafting a unique, informative job-seeking profile is time well spent. So, onto the mistakes!

Mistake #1 - Stuffing every single app you've built into your GitHub
I think this behavior comes from the belief that: the more apps we have built, the more competent and versatile we appear. However, including every app you have built in your GitHub can have the opposite effect, and cause you to appear unfocused and insecure. Instead, choose only those apps that:

• Showcase your growth as a developer: To do this, you could include two iterations of one app in your portfolio: the first iteration would contain the rudimentary code you wrote at the start of your learning, and the second would have all the improvements and refactoring you've done since you first built the app. In the README of the improved version, explain the changes you made and why.
• Represent the fruit of certain struggles you faced while learning:Include apps that you struggled to build, and document these struggles and how you overcame them in the README. These apps give you ample subject matter to discuss during your interviews.
• Represent your ability to combine several functionalities and cause them to work together:Something I see over and over in new dev portfolios are apps that boast only one main functionality. For example, one app incorporates authentication; another app consumes an API; still another app implements chat between users. I suggest including apps that implement several functionalities that work seamlessly together, as this is more representative of the apps you will work with on the job.
• Showcase your passion (or was major fun to build): This point is more about being able to exude confidence and authentic emotion while speaking about your apps in interviews. No matter how technically impressive, if an app does not make you want to talk about it and field questions about it, do not include it.

Mistake #2 - Empty, Default or Scanty READMEs
When someone navigates to your GitHub repo, they see a title and a column of folders. Most will scroll down the page to the README section; only to be disappointed by the default GitHub README text or nothing at all. They may never get a sense of the awesome code living within the repo, because your undeveloped README gave a poor first impression. As a job-hunter, you want to make the process of getting to know you as simple and straight-forward as possible. Your README is your opportunity to do just that: to tell a story that will draw the hiring manager in, and make them desire to learn more about you. I think the README for every coding project included in your GitHub should include the following:

• Rationale for building the app: Nothing ground-breaking or save-the-world-ish is necessary. Just a short explanation for why you chose to spend precious time on this particular app. Maybe it was to teach yourself a certain library. Or create a solution for elderly dog-walkers.
• List of App's Functionality: A bullet list of what your app does.
• Problems Encountered & Solutions Implemented: This goes back to the point above about the quality of apps you include in your profile. In my opinion, if building an app was easy, breezy, follow-the-tutorial-prompts, you should exclude it. It is those apps that took a fair amount of effort that showcase your tenacity as a developer, and the README should detail those struggles - just not in whole paragraphs though!
• Instructions for Deploying the App Locally: This isn't true of most hiring managers, but there are some who like to deploy the apps of candidates locally, try to break it, then come up with questions to ask the candidate. So I recommend having simple steps to reproduce your app in a local environment. Be sure to state any prerequisite operating systems (like MacOS only) or software.

Mistake #3 - Including Apps that aren't Deployed Online
Like I said above, few hiring managers will attempt to deploy your app locally. But most would like to interact with your app and test its functionality. Undeployed apps are cousins to Undeveloped READMEs; by not deploying your app, you again miss that crucial opportunity to draw the interest of hiring managers, and showcase your skills in a dynamic way. So please, deploy every app you include in your GitHub.
-- What if my app is mostly back-end? No problem! Implement a very rudimentary frontend, deploy the app, then explain in the README that you focused solely on backend for the app in question, so the frontend is not intended to represent your skills, but merely to grant access to the backend functionality.

What about Unfinished or Abandoned Apps?
Several devs whose profiles I've reviewed have objected to my advice on including only high-quality apps in their GitHub. "But I'm currently working on several unfinished apps - where do I put them?" Well, there are several ways to distinguish your finished apps which are ready for exhibit, from those still under construction.

• Pin your apps for exhibit to your GitHub profile: Under "Popular Repositories" on your GitHub profile, click on the "Customize Your Pins" link to the right, then select up to six apps to be displayed. Anyone landing on your GitHub profile will see these apps upfront.
• Prefix unfinished apps: Add an "In Progress" prefix or flag to your unfinished apps. This approach indicates which apps are still being built (and hence, should be ignored or taken with a grain of salt).

NOTE: I initially included the tip "Have 2 GitHub accounts; use one for the apps (finished or unfinished) that you wish to showcase" but upon reflecting on several objections in the comments, I've decided to pull that tip out of the article.

Your choice of portfolio apps should reflect the story you wish to tell and the competence you wish to reflect as a developer, not just that you have this Swiss-army knife of skills. The goal is to convince hiring managers that you are an asset to any dev team; choose those apps that demonstrate your ability to wireframe tech-based solutions at a high-level, locate and incorporate tech solutions efficiently, and work in a self-directed, self-motivated manner.

Thanks for reading!

Enjoy content similar to this post on Arit, Developer!
Subscribe to Arit's Newsletter to receive quasi-monthly emails whenever she publishes a new story.