Anything, really. So long as they aren't a dipwad in comments, etc, any information I can glean from a GH profile is a net positive. It's very hard to have a "bad" profile - I don't want to ding candidates for having a life outside of showcasing their work for me.
It's hard to judge by commits alone because your public profile doesn't reflect contributions to private repos, which for many of us is our 9-5 work. I look for meaningful open source contributions or a side project the engineer is passionate about, and within those repos I usually skim for code style but I check commit messages and documentation. (I don't want to work with an engineer who writes commit messages like "Misc shit WIP" or "lol 3 AM", and I don't want to maintain code written by someone whose README.md is blank or a placeholder. Part of this is the more I learn about software engineering, the more I realize that making code intelligible to other people on the team is so much more important than elegant code that only the author understands. If you're optimizing for elegance, you're trading a few bytes of compressed storage space for hours of an engineer's on-the-clock time trying to figure out what the heck you did.)
Anything that's not a bad github profile would be a good profile. Ideally, I would want someone who has done a lot of open source pull requests, or has some interesting projects, or has contributed to some big-name existing project. But even if you don't have that, a profile showing you actively work on programming as a hobby / for fun is a great way to say something about your interest in this career.
On the other hand, I've hardly ever come across a profile that felt truly "bad" to me. The one exception would be that one guy whose history of pull requests is filled political-correctness-fueled changes to comments and function names.
I am shocked by how few candidates have much of a Github profile at all. So the good news is that it is easy to stand out.
Have some projects that are finished. They don't need to be extravagant. Just show that you can ship code and know how to explain how/why to use it in the README or for extra points a nice gh-pages demo page. Once you have a few projects under your belt, you can create a nice home for them with your username by making a public repo with a project name of username.github.com - see https://pages.github.com
For front end, if you prefer codepen over Github as your online code portfolio of choice, that is fine too (at least in my opinion). Or both.
I'm shocked that employers would even think of requiring you to have a github profile, more so a public one.
Think about it: having a full-time job and a life implies that large numbers of very employable people have absolutely no time whatsoever left over to dedicate to maintaining a current set of contributions to high profile open source projects, let alone 'some finished projects'.
If a company can't figure out during the interview that a person is able to ship code then they should review their hiring practices, not pass the burden to their potential hires.
Also, you're probably de-selecting all the women developers because it's very rare indeed to come across a profile of a female on github.
The extra hilarious part of what I like to call "The GitHub Paradox" is that 99% of the companies wanting you to have a fleshed out GitHub profile don't have one themselves and none of their current employees do either.
Haven't you heard? You're supposed to put in 10 hours a day at the office, then go home and write blog posts for the company, then make meaningful contributions to multiple open source projects.
Oh, and drop half your take home pay on hardware and software so you can be up to date on whatever tech they decide to go with in the future.
I work on a team of about 25 people, all quite top notch. I think there are two github profiles of any substance out of the bunch. My own profile, for example, is basically a scratch pad where I toss random half-baked experiments that I want to show to a specific person, and the occasional fork/bugfix on someone else's project.
A well-stocked github profile can be a bonus for a candidate, but it's just asinine to reject someone for lacking one. Heck, my biggest personal project has been underway for several years and will be for several more, but I'm keeping it under wraps and very few people even know it exists. Some very good developers spend all their free time with their kids, or training for IronMan races, or doing community theater. And some people work for companies that would try to lay claim to code the person wrote on their own time, so they just don't bother.
When I'm looking at someone's GitHub profile, I like to see a few different things:
* A diversity of projects is always nice, whether in languages/technologies used or in scope. I tend to be unimpressed if a person's most active repositories are essentially iterations of the same technology/idea.
* An active contribution history, both to their own repositories and others. That doesn't mean constant contributions to a 3rd-party project or membership in it, but it's nice to see that a person is taking the time to look at and offer their skills/effort to others.
* More superficially, I really like to see personal websites. That's less of a profile thing, but it tells me that you're committed to your online presence beyond filling out GitHub's 5-minute signup.
Overall, I'd say that 80% of the profiles I see meet two out of three of those, and 60% meet all three. The only things I really hate seeing in GitHub profiles are blank repositories/repos that look slapped together for appearances.
I look for consistency, someone who either has no contributions (doesn't make them a bad developer, just not working on public things) or has regular steady contributions. Anyone who has a bunch of green dots in the last couple of weeks and a bunch of green dots months ago makes me just discard the github profile as a useful positive signal.
Anyone who has a bunch of green dots in the last couple of weeks and a bunch of green dots months ago makes me just discard the github profile as a useful positive signal.
Ooh, you just more or less described me. What makes working on public things, say, one weekend every couple of months less interesting than not working on public things at all?
It sounds like the thing being watched out for is "they clearly didn't do open source things until somebody said that open source looks good to recruiters", and so their recent work is more suspect. Not sure I agree 100%, but the "green dots start when they start job-hunting" pattern is pretty common.
I've been doing volunteer work for the GNU Project since the 1990s. My GitHub profile might not be jam-packed with dots, but I think one would be hard-pressed to seriously insinuate that my few GitHub dots align with the fleeting open source wishes of recruiters... :-)
Though anyone looking only at my GitHub profile might reasonably think so, I guess.
Considering that they don't have a job, and thus have more free time to contribute shouldn't make them look bad. I have a job, I do my job, I go home. Occasionally (like on my birthday) I donate some of my spare time to projects that I care about, and you'll see contributions for a while then I get back to regular stuff which isn't open source. If that looks bad to a potential employer then that's not the kind of employer that I want.
Yeah, usually on or around my birthday I'll donate some of my personal time to improving open source projects, I certainly don't want that looking bad for me just because I try to help.
They didn't say it was bad, they just said it wasn't a useful signal.
One thing I'm seeing more commonly is where a group of people create github profiles with a handful of projects that are obvious homework assignments, and then open and close a few issues and pull in some trivial changes to each others' repos in order to put a few green dots on their contributor graphs.
On the one hand you can put green dots in retroactively. So you could be fooled.
On the other hand a genuine contributor may be working offline each day for months then do a big commit (squashing down the intermediate local history - can't remember the git term for this).
What I think would be good is to instruct candidates to write a cover letter about their side-projects. Talk about each one briefly. With links to online repositories if available (or zip files otherwise).
Care given to onboarding new teammates is a huge plus for me. I have interviewed and screened a few hundred developers over the last 2 years. I will always dig into their code first.
I look for good naming, organization, and how easy a new developer will be able to ramp up given the environment he or she has established.
Similar question: what about using a site besides Github? I use Bitbucket and link there from my homepage. I don't contribute to any FOSS projects besides my own in my freetime, but prefer Bitbucket for various reasons (principally because I have a bunch of barely-started idea projects and practice bins and I generally only make something non-private after I get somewhere, which I can't do for free with GitHub). Am I missing out by not using Github particularly?
For discover-ability? Because the public features of BB seem to work just fine for me, and then all I have to do is change one quick setting to make it public. I know git isn't all that hard to migrate over, but even so.
GitLab CEO here, on GitLab.com you get the private repos and a calendar https://gitlab.com/u/sytses (but of course this won't show private contributions).
Empty github profiles don't say anything good or bad because of private repositories not showing up on the commit graph. I put my own junk on bitbucket anyway because there's no reason for the world to need to see it in 99.99999% of cases.
do people really need to have a github profile to get hired nowadays? Am I a bad dev if I "only" code from 9to5 in a company and do different things in my spare time then contributing to open source? It's a bit off topic I know, but I read those github profile threads everywhere.
31 comments
[ 4.7 ms ] story [ 76.1 ms ] threadOn the other hand, I've hardly ever come across a profile that felt truly "bad" to me. The one exception would be that one guy whose history of pull requests is filled political-correctness-fueled changes to comments and function names.
Have some projects that are finished. They don't need to be extravagant. Just show that you can ship code and know how to explain how/why to use it in the README or for extra points a nice gh-pages demo page. Once you have a few projects under your belt, you can create a nice home for them with your username by making a public repo with a project name of username.github.com - see https://pages.github.com
For front end, if you prefer codepen over Github as your online code portfolio of choice, that is fine too (at least in my opinion). Or both.
Think about it: having a full-time job and a life implies that large numbers of very employable people have absolutely no time whatsoever left over to dedicate to maintaining a current set of contributions to high profile open source projects, let alone 'some finished projects'.
If a company can't figure out during the interview that a person is able to ship code then they should review their hiring practices, not pass the burden to their potential hires.
Also, you're probably de-selecting all the women developers because it's very rare indeed to come across a profile of a female on github.
Oh, and drop half your take home pay on hardware and software so you can be up to date on whatever tech they decide to go with in the future.
A well-stocked github profile can be a bonus for a candidate, but it's just asinine to reject someone for lacking one. Heck, my biggest personal project has been underway for several years and will be for several more, but I'm keeping it under wraps and very few people even know it exists. Some very good developers spend all their free time with their kids, or training for IronMan races, or doing community theater. And some people work for companies that would try to lay claim to code the person wrote on their own time, so they just don't bother.
* A diversity of projects is always nice, whether in languages/technologies used or in scope. I tend to be unimpressed if a person's most active repositories are essentially iterations of the same technology/idea.
* An active contribution history, both to their own repositories and others. That doesn't mean constant contributions to a 3rd-party project or membership in it, but it's nice to see that a person is taking the time to look at and offer their skills/effort to others.
* More superficially, I really like to see personal websites. That's less of a profile thing, but it tells me that you're committed to your online presence beyond filling out GitHub's 5-minute signup.
Overall, I'd say that 80% of the profiles I see meet two out of three of those, and 60% meet all three. The only things I really hate seeing in GitHub profiles are blank repositories/repos that look slapped together for appearances.
Why do you feel an online presence is important to an employment candidate?
The question asked how I defined a "good" GitHub profile.
Ooh, you just more or less described me. What makes working on public things, say, one weekend every couple of months less interesting than not working on public things at all?
Though anyone looking only at my GitHub profile might reasonably think so, I guess.
One thing I'm seeing more commonly is where a group of people create github profiles with a handful of projects that are obvious homework assignments, and then open and close a few issues and pull in some trivial changes to each others' repos in order to put a few green dots on their contributor graphs.
Sad really.
On the other hand a genuine contributor may be working offline each day for months then do a big commit (squashing down the intermediate local history - can't remember the git term for this).
What I think would be good is to instruct candidates to write a cover letter about their side-projects. Talk about each one briefly. With links to online repositories if available (or zip files otherwise).
I look for good naming, organization, and how easy a new developer will be able to ramp up given the environment he or she has established.