Junior and intermediate coding professionals today are likely to be asked during a job search, "Can we see your GitHub?" by recruiters and hiring managers, and the youngest in the industry may be unaware of how relatively new this practice is. Being that this is a recent trend in the evaluation of developers, many wonder what employers are looking for and what a good GitHub account generally looks like.
But first, how did GitHub become a widely used developer evaluation tool in the first place?
A portfolio of code
In past decades, engineers were chosen for interviews based on their résumé content and positive referrals from colleagues. Given the available technology up until the early 2000s, demonstrations of coding prowess were often limited to answering technical questions or writing and editing relatively short programs in an interview setting. Few professional programmers had code that wasn't directly related to their day job (and was often proprietary), and even personal websites were a rarity.
As technology trends changed, so too did some of the concepts around hiring. The rise of the open-source movement, the drastic reduction in barriers (both cost and complexity) to hosting, general public access to publishing on mobile app markets, and the popularity of repository sites all contributed to a programmer's new ability to show a portfolio of code to employers.
... but GitHub is NOT your résumé
That new ability to show code gave birth to some unfortunate expectations, and a number of employers began equating GitHub repos and open-source contribution as an exclusive requirement for employment consideration. The "GitHub is your résumé" trope emerged in response to employers doing this. alongside a number of excellent posts explaining why this idea needed to die.
For the most part, it has—the overwhelming majority of employers today are not under the impression that a robust GitHub is necessary to prove one is a worthy hire. Quality GitHub projects, particularly for experienced applicants, are likely viewed as supplemental evidence of coding ability and conversation pieces for interviews.
Which job seekers benefit most from GitHub projects?
Recent college graduates—Discussions regarding the marketability of new grads typically boil down to a few topics: school or program reputation, GPA, internships, and projects (read: GitHub). A healthy assortment of projects that are readily accessible to recruiters and hiring managers can potentially compensate for any perceived deficiencies in the other areas.
Bootcampers and autodidacts—Those who learned to code through accelerated immersive learning programs or self-directed study are often at a significant disadvantage for entry-level positions due to the way many in the industry currently view those methods. The reputation of bootcamps as a whole is still emerging, and the rates of success or failure of their graduates over time will contribute to that reputation, but today questions remain regarding the general preparedness of their students. Questions as to whether bootcampers or the self-taught can code may be answered with a simple URL to a public repo.
Experienced developers seeking transition—Although one may generally assume that experienced developers will see the least value in having projects available for review, there are some rather widespread biases and stigmas that may be addressed and possibly overcome through the sharing of personal projects. The able programmer who is wildly underchallenged by his or her day job may find it impossible to identify professional accomplishments worthy of a résumé bullet.
A developer who (based on corporate policy) is forced to write in proprietary or out-of-favor languages will quickly discover that this experience is not often coveted by employers using the latest and greatest across their stack. Will managers at a Python or Ruby shop give the time of day to a career enterprise Java developer without some relevant code? Sometimes the answer is no, unless they have code projects that prove their programming flexibility.
What makes a 'good GitHub'?
Many entry-level and junior developers feel the answer to "Do I need a GitHub?" is clearly yes, and they skip right to "What types of things should I have in my GitHub?" Assuming one is planning ahead and building one's project portfolio in advance of a job search (and not relying on previous work), the possibilities are infinite, and the sheer volume of choices can lead to inaction. With options ranging from a simple Perl script to a complex social network, how does one choose?
Perhaps the biggest portfolio mistake made by candidates is the tendency toward overly ambitious efforts that would be nearly impossible even for a team of more experienced programmers. Employers don't expect anyone (let alone recent graduates) to independently conceptualize, design, and implement the next Facebook or Twitter. By setting the bar too high for themselves, many juniors end up with a portfolio of half-baked ideas that will never be near completion.
First we will focus on realistic project ideas and common GitHub content, and then share some hints on the repos themselves.
Common GitHub Content
Website—This is the most common project. Even if web development isn't your thing, there are plenty of templates and tools to make it rather painless. Websites may not be the best bet for showing off skills, depending on where your interests lie.
Stereotypical programming exercises—FizzBuzz, Conway's Game of Life, and all those other exercises junior programmers may be asked about during the hiring process. The solutions won't be unique, but it will strengthen your knowledge of basic algorithms.
Games—Many programmers are familiar with and enjoy various types of games. Game development projects don't need to be original. While some may be intimidated by the effort required to write a graphics-intensive artistic offering with realistic physics, a simple turn-based card game can showcase your understanding of key programming concepts just as well. There's nothing wrong with building your own implementation of Pong or Asteroids.
Mobile app—Professional mobile developers and those looking to enter that field are often judged by their available titles. Those that do publish apps should focus on usability and function and not give a thought to download stats or popularity.
Scripts, utilities, plug-ins—When it comes to repos, size doesn't matter. A useful automation script, scraper, or productivity tool will catch the eye of a select type of engineer, and luckily these are the ones you want to impress. This genre of project is indicative of a hacker mentality, and the ROI for these projects is substantial.
Employer-targeted code—One unique way to get an employer's attention is to write something related directly to its business. These projects can serve to both demonstrate skills and flatter the employer with a level of interest. Examples might include projects that call the company's API or a visualization of its data sets.
Contributions to other users' projects — A contribution will show up on a GitHub public profile if it meets a list of criteria established by GitHub and depending on the user's privacy settings. In addition to showing technical chops, these contributions may also demonstrate a commitment to open source which will be valued by others sharing that commitment. For most at the junior and intermediate level, contributions make up a tiny fraction (if any) of their GitHub activity.
What you'll be graded on
Variety—Several projects utilizing the same tech stack and tools will be less impressive than demonstrating fluency across a palette of tools. Bootcamp graduates might typically have three or four similar projects (often using Ruby on Rails). One simple way to add some diversity to a GitHub portfolio is to implement the same solution over again using different languages or paradigms. Build a game in Python, rewrite it in Java.
Completeness—Many candidates have GitHub accounts strewn with several projects that were never finished. Most employers would rather see a few repos that appear polished than dozens of sketches that need lots of attention.
Functionality—Does the code actually do what it should?
Performance—Does the code do what it should remotely well?
Readability—Those evaluating a repo are doing so under the premise that this could be the code of a future co-worker. Nobody wants to work with someone who writes unreadable code. It's a good idea to have repos reviewed for readability before sending them off, even if code compiles and performs well.
Documentation/information—A repo without a simple README is a wasted opportunity. Although the code is what will ultimately be judged, some minimal explanation of the repo and directions on usage will go a long way.
Show you can code
A portfolio of code is primarily used to demonstrate basic programming ability and an understanding of fundamental concepts. It can also serve as a catalyst during interviews that helps facilitate deep explorations into the thought process behind a technical decision. These conversations are what make for great interviews, and the opportunity to discuss familiar material (your GitHub repos) will be far more comfortable than fielding random technical questions.
The GitHub portfolio is certainly not the be-all and end-all when it comes to a job search, but it's clearly an advantage that helps answer the critical "Can you code?" question by showing instead of telling.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
