Dave Fecak

About Dave Fecak

Dave Fecak has been recruiting software engineers for start-ups since 1998 and he has served as the founder and president of the Philadelphia Area Java Users’ Group since 2000. Dave is often cited and published on career topics for technology professionals, and he blogs at JobTipsForGeeks.com.

Hiring Indicators, OSS, and the Value of GitHub

As someone who writes about tech hiring and who has also encouraged many to participate in open source and establish a GitHub presence, a recent article caught my eye. Why GitHub is Not Your CV ¹ by James Coglan was partly inspired by another article, The Ethics of Unpaid Labor and the OSS Community by Ashe Dryden. Both articles are well-written and if you evaluate programmers for hire please read them.

Dryden’s tl;dr for me was meritocracy in OSS, explanation the lack of diversity, and ways to hire that are ‘less biased‘ than relying on OSS contribution or public code availability. Coglan references her piece and adds his own thoughts around similar topics, but his readers might disregard the value a GitHub presence provides. Neither article tried to discourage a presence, but the Coglan piece dismissed the value quite a bit.

After reading his article, a related tweet from Coglan also got my attention:

recruitertweet-copy2

Isn’t the entire hiring process a form of short cut?

Why GH profiles and not interviews? We want to know how candidates will perform over n months, yet don’t have n months to assess someone working in our environment before providing a paycheck.  An impasse. Recruiters and hiring managers look for indicators of talent based on experience with previous hires. The existence of GitHub code for many recruiters serves as a useful indicator, and forks and followers might be considered a stronger indicator (crowdsourced data). Just like everyone who makes it past the interview won’t be a good hire, there will be false positives.

Coglan wrote “using open-source software contributions in general, and GitHub profiles in particular, as a hiring filter is bad for our industry” (emphasis mine).  I appreciate his arguments against OSS contribution as a filter and see the danger there. But why GitHub accounts in particular?  Coglan has a few thoughts, including his assertion that GitHub profiles “simply don’t tell you what you think they tell you.”

Rejecting applicants solely because they lack OSS contribution or GitHub would be doing the industry as a whole a disservice, as both authors and most of the industry would probably agree. Not every good programmer has a GitHub account or participates in OSS. If either of the two articles simply stated that alone, there wouldn’t be any talk. However, hiring is not done based solely on GitHub, and Coglan’s article could lead to a couple false assumptions.

Assumption 1 – GitHub users are part of the open source ecosystem (or, GitHub accounts reflect OSS contribution)

Some like Coglan clearly are. But thousands and thousands of GitHub users are building little things for themselves that will never see the light of day, such as small vanity projects to demonstrate code for employment, occasionally fixing small bugs in the projects they follow. Coglan says GitHub accounts are not portfolios because the user has little control over the highlighted content, but many junior programmers and those not active in the OSS community actually joined GitHub for the sole purpose of building a code portfolio.  If you only have a few repos and little OSS contribution, it’s reasonably curated.

There are over a thousand FizzBuzz repos and nearly two thousand that contain the word Conway (as in Game Of Life). It’s a small sample size relatively speaking, but there are clearly many others that are similar. Anyone coding FizzBuzz isn’t likely making significant contribution to the OSS community and may know little about OSS, but rather are just trying to get jobs or hone skills. GitHub to them is a useful supplement to what may be a weak CV.

Dryden’s description of a non-biased hiring process first lists “Ask for code samples” as a step in an ideal hiring model. When someone asks for your GitHub account, maybe they aren’t asking “How much time do you do unpaid labor while being a part of a false meritocracy?”, but rather “Got any code I can read?”  

Assumption 2 – GitHub users are unpaid laborers

The people that are writing code for themselves (personal use or employment portfolio) do so for their own primary benefit. They don’t get paid to go jogging, either.

All Coglan’s talk of unpaid work and being coerced to do it ignores the fact that some of the code on GitHub is compensated work. Just because code is on GitHub doesn’t mean it was written for free. People in the industry and the authors know this, but the article does little to differentiate between the culture of 24/7 working with many unpaid hours and the fact that lots of repos were paid for on company time. I’m onboard with Coglan regarding the dangers of a 24/7 work culture and 80 hour weeks, but I don’t think we can point to OSS and most GitHub users as the source.

Coglan references Dryden’s point about OSS contribution and GitHub providing a hiring bias towards white men. In turn, eliminating GitHub as a means of hiring evidence also creates a bias and hurts certain groups the most.

What about recent graduates, students, the underemployed, and career changers?

It would seem rather unfair not to use GitHub code to judge hobbyists who are pursuing paid work, as their accomplishments in the field don’t exist. For them, GitHub is the CV. There are surely thousands of GitHub users who were employed in other industries (I’ve come to know many), and they rely on their code to get them in the door. These are the aforementioned FizzBuzzers and Game of Lifers, many lacking a CS degree or training.

Coglan seems to has a few other beliefs that are worth additional thought.

“There is really astonishingly little value in looking at someone’s GitHub projects out of context.”

We’re talking about GitHub content (based on the article) for possible hiring and talent evaluation, and by looking at projects I’ve always thought we were talking about code. In my experience, the GitHub account is provided for review upon request and not just stumbled upon in the wild without opportunity to ask the user questions, and is often reviewed live during an interview. Coglan mentions being asked for his profile by recruiters and job ads, so this affords the opportunity to provide additional context.

Coglan wrote:

“…GitHub has no way of customising your profile page, and what is shown by default is the projects with the most stars, and the projects you’ve recently pushed to… You have no say about what you consider important, or worthwhile, or interesting, or well-engineered, or valuable.”

and a bit later

“I can’t tell you that the Canopy metagrammar is the most interesting program I think I’ve written.”

I can understand why Coglan feels this way, as his GitHub is bigger than yours.  He ranks high on the list of active GitHub contributors, so visitors to his account probably won’t see exactly what he wants without a guide. The curating challenge Coglan faces is not shared by average GitHub users (recent stat is 3.5M users, 6M repos) with far less activity.

For hiring purposes, users do have a way of saying what is important and worthwhile for entire accounts and for any repo. “Here’s my GitHub link. Much of it is under construction (excuse the mess!) but I’m particularly proud of the Canopy metagrammar repo and think it is relevant to your project.” For any repo, README files can provide additional context and many do just that. This doesn’t prevent readers from seeing a mess, but if you are providing the GitHub account you have some ability to provide context. Those reviewing your content likely want to see interesting stuff, so they aren’t likely to go through your laundry to find that one half-baked repo.

I have at least a couple clients that ask for a code sample (usually GitHub) and a specific repo or two worth highlighting with some thoughts. Maybe other companies are not this fair in assessments.

“…your GitHub profile displays two things: how ‘influential’ you are, and how easily you can be coerced into constantly working. It’s honestly about as relevant to a decent hiring decision as your Klout score.”

What about code?

For average GitHub users, the profile would only show that the person has little influence whatsoever and probably hasn’t been coerced into much.  Are employers using GitHub as some measure of influence and not for code? I’ve had clients request code samples where we provide a GitHub link, and I’m yet to see rejections due to a lack of followers or repos. Most GitHub users, and particularly those that look at GitHub as a potential means to get hired (CV), are practically invisible.

“How easily you can be coerced into constantly working” never came to my mind, but it’s an interesting thought. I think you really have to ask individuals if they are contributing because they feel enormous amounts of pressure to do so, because they enjoy it, or some combination of the two. I don’t imagine that the companies I represent judge massive GitHub presence as indicative of workhorses providing much more bang for the buck, but it’s possible.

In my experience, those reviewing GitHub accounts care less about influence and followers and more about code.²  Not the volume, but the quality. The account is provided often to give the interviewers topics to discuss during an interview, where they can review the code and decision-making behind it. I’m yet to hear of interviewers asking why a GitHub user lacks more followers.

If influence and the appearance of being easily coerced are concerns, send the code sample directly.

Using Indicators

We use certain short cuts in order to try and efficiently evaluate talent, and these short cuts are the use of indicators. Interview performance is the primary indicator for most companies.

jcoglantweet2-copy

Coglan tweeted about using Stack Overflow rankings as a hiring criteria in a tweet. I hope that he is referring to SO scores as one possible indicator of knowledge and not as a requirement, but I could be wrong. I’m yet to encounter a company that requires a SO account, let alone a score over X as a criteria for consideration. Higher SO scores, just like those with a heavy GitHub presence, can indicate more free time. A high scorer doesn’t mean the person knows more than a non-user, but the high scorer usually knows something. Why would we not at least consider this as likely evidence of knowledge?

There are several indicators I use. GitHub and SO have some value just as employment by certain selective companies means you’re likely to pass tech interviews for other firms. Degrees from certain schools give some evidence, and it’s not always the ones you expect (I have had particularly good experience with Villanova CS grads). The majority of candidates that most industry recruiters or managers speak to do not boast libraries of OSS contribution, top SO scores, Google résumés, and top ten degrees.

Conclusion

The articles did make me rethink some things I’d written and thought about measuring passion and and how those measures are often skewed by free time and other societal circumstances. I feel Coglan somehow assumed that most GitHub users were heavy OSS contributors, while ignoring the usefulness of GitHub for a large enough population worth mention.

Short cuts are a necessary part of the hiring process, but you obviously can’t hire based entirely on short cuts. People will continue to use evidence provided, be it a CV, a cover letter, an interview, or a GitHub account, in order to make decisions on interviews and then on hiring.

The greatest takeaway from Coglan and Dryden is the need to give everyone a fair shake and consideration, regardless of their OSS participation or the presence of internet points.

  1. The author lives in the UK, so for US audiences think résumé (with some differences)
  2. My experience is 15 years working with startups and midsize tech firms in the Philadelphia and mid Atlantic region that hire software engineers.

 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


five × = 40



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close