Github is Your New Resume(code.dblock.org)
code.dblock.org
Github is Your New Resume
http://code.dblock.org/ShowPost.aspx?id=232
151 comments
Building this bot should get a job for the right person.
It's not only a coding project in its own right, but it's also a very clever form of lateral thinking that shows a certain cheekiness and savvy that can be appreciated by plenty of businesses out there.
The trick is that you have to make sure you're not hiring for any of their plagiarized projects. What if they plagiarized the bot itself?
It's not only a coding project in its own right, but it's also a very clever form of lateral thinking that shows a certain cheekiness and savvy that can be appreciated by plenty of businesses out there.
The trick is that you have to make sure you're not hiring for any of their plagiarized projects. What if they plagiarized the bot itself?
Surely building the bot would prove a certain proficiency. (I think they train educators to say this.)
Yes, but a lot less than would be required to code the things that are actually being stolen.
That's the art of plagarism - knowing enough to steal well.
That's the art of plagarism - knowing enough to steal well.
To make it more interesting, feed the bot 'profanity' list for git commits..
http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-c...
http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-c...
I fail to see how that is any different from someone lying on their resume.
If the hiring manager is too stupid to be able to detect the person is lying about their skill level after a 15 minute conversation, caveat emptor.
If the hiring manager is too stupid to be able to detect the person is lying about their skill level after a 15 minute conversation, caveat emptor.
Lying on your resume is an explicit attempt to deceive a prospective employer.
Lying on Github (and then presumably not using it on an actual job application), you're only fooling those who are willing to be fooled.
If someone is going to scrape data off the web about people and evaluate it for prospective candidates, the burden of separating the signal from the noise is on them, the internet is full of bullshit. You're obviously mucking with their process, but you didn't ask to be included in it either. No different than assuming all the content on blogs isn't plagiarized and then trying to use that to proposition people to be authors.
Lying on Github (and then presumably not using it on an actual job application), you're only fooling those who are willing to be fooled.
If someone is going to scrape data off the web about people and evaluate it for prospective candidates, the burden of separating the signal from the noise is on them, the internet is full of bullshit. You're obviously mucking with their process, but you didn't ask to be included in it either. No different than assuming all the content on blogs isn't plagiarized and then trying to use that to proposition people to be authors.
Oh, I think plagiarism is less ethical than lying on one's resume. ;) Unless, of course, it is done by a fictional character as part of poking fun at people who insist on reading other people's personality traits from their Github accounts.
Because, to the extent that this amusing exercise has a point, it is that your Github account is not a resume; it may just be a miscellaneous collection of code that you find useful, none of which is necessarily yours. And there's nothing wrong with that. That's Github's design. You should feel free to use Github as a tool, not as an advertisement for yourself.
And if you insist on pretending that the contents of someone's Github account, bookshelf, or sock drawer is necessarily some kind of representative sample of their character or skill, you deserve to get punked. A person who is lying on their resume has set out to lie to you. A person with a nonrepresentative Github repo is merely guilty of misleading the stranger who is looking over their shoulder.
Because, to the extent that this amusing exercise has a point, it is that your Github account is not a resume; it may just be a miscellaneous collection of code that you find useful, none of which is necessarily yours. And there's nothing wrong with that. That's Github's design. You should feel free to use Github as a tool, not as an advertisement for yourself.
And if you insist on pretending that the contents of someone's Github account, bookshelf, or sock drawer is necessarily some kind of representative sample of their character or skill, you deserve to get punked. A person who is lying on their resume has set out to lie to you. A person with a nonrepresentative Github repo is merely guilty of misleading the stranger who is looking over their shoulder.
I hope Nicolai also has some amazing blog posts on his blog too.
[deleted]
And some witty one-liners on Twitter.
This sounds scarily like what happens to my projects :-/
I recently interviewed at a Fortune 100 company's new "Innovation" group. I pointed them to the various projects I have on Github as examples of my work. They reviewed it and liked what they saw.
However, my interviewer told me "we've seen your code on Github. It's great, but just so you know, you won't be able to keep that up if you work here."
I asked more about what he meant by this and he told me that the company is extremely secretive and would not allow me to post any code to Github. Some other developers had already been told to take down some (very general, non-proprietary) code they had posted to Github.
What came out is that my public work on Github helped me get an offer but I wasn't going to be able to contribute any new code during my years at this company.
I certainly don't want a three-year blank spot in my public code "resume", so I turned down the offer.
This is a bit of the tangent from the OP's point, but I think its related: Companies need to realize that the benefit of allowing employees to contribute to open-source isn't merely getting the community to work or review your team's code, but rather, open-source is a marketing and recruiting tool.
Say you let your employees create and maintain open-source software. Say it is successful and other people start using that software. If it used widely enough, your employees are asked to speak at meetups and conferences and say "Look at this great software I built while working at company X. Company X is so cool, come work here!" (and every contributor to the project becomes a potential employee who will already know a portion of your code.)
tl;dr - Companies: allow your employees to freely work on open-source and it will improve your recruiting.
However, my interviewer told me "we've seen your code on Github. It's great, but just so you know, you won't be able to keep that up if you work here."
I asked more about what he meant by this and he told me that the company is extremely secretive and would not allow me to post any code to Github. Some other developers had already been told to take down some (very general, non-proprietary) code they had posted to Github.
What came out is that my public work on Github helped me get an offer but I wasn't going to be able to contribute any new code during my years at this company.
I certainly don't want a three-year blank spot in my public code "resume", so I turned down the offer.
This is a bit of the tangent from the OP's point, but I think its related: Companies need to realize that the benefit of allowing employees to contribute to open-source isn't merely getting the community to work or review your team's code, but rather, open-source is a marketing and recruiting tool.
Say you let your employees create and maintain open-source software. Say it is successful and other people start using that software. If it used widely enough, your employees are asked to speak at meetups and conferences and say "Look at this great software I built while working at company X. Company X is so cool, come work here!" (and every contributor to the project becomes a potential employee who will already know a portion of your code.)
tl;dr - Companies: allow your employees to freely work on open-source and it will improve your recruiting.
Companies: allow your employees to freely work on open-source and it will improve your recruiting.
Apple barely lets their employees blog even, and last I checked they're doing OK by all counts.
Unfortunately, the intersection for people who are passionate about their 9to5 work and those that are passionate about their side-project seems to actually be fairly small.
Apple barely lets their employees blog even, and last I checked they're doing OK by all counts.
Unfortunately, the intersection for people who are passionate about their 9to5 work and those that are passionate about their side-project seems to actually be fairly small.
So I agree with you in the case of Apple. But let's dissect for a minute why this is the case.
Apple can be incredibly secretive and still hire with no problems because
1) they are literally creating world-changing products and people want to be involved with that
2) they have a reputation for hiring extremely bright people. If you take a job at Apple you will interact with them (/ be one of them)
But outside of the big technology names (msft, google, fb, etc.) there's a huge collection of companies where either a) the brand is known but the company isn't know for being an innovative place in the hacker community or b) the company isn't known and neither is the team.
In both of type (a) and (b) companies you hear a lot of moaning from managers right now about how they can't find any good folks to hire.
So I'll qualify my advice a little bit: If you find you're having a hard time finding "rockstar-ninja-l88t programmers" by posting to Monster.com, maybe consider that you're approaching hiring in the wrong way.
Apple can be incredibly secretive and still hire with no problems because
1) they are literally creating world-changing products and people want to be involved with that
2) they have a reputation for hiring extremely bright people. If you take a job at Apple you will interact with them (/ be one of them)
But outside of the big technology names (msft, google, fb, etc.) there's a huge collection of companies where either a) the brand is known but the company isn't know for being an innovative place in the hacker community or b) the company isn't known and neither is the team.
In both of type (a) and (b) companies you hear a lot of moaning from managers right now about how they can't find any good folks to hire.
So I'll qualify my advice a little bit: If you find you're having a hard time finding "rockstar-ninja-l88t programmers" by posting to Monster.com, maybe consider that you're approaching hiring in the wrong way.
[deleted]
Some years back there was a discussion of how Free Software was saving IBM's research labs.
The problem being that there's a lot of cool stuff you can work on at the labs, but unless there's a $50m or $100m market for it, there's no interest in productizing the project.
What creating a culture of allowing work on Free Software projects allowed, among other things, was satisfaction and motivation among the lab engineers in being able to produce work which, even if not immediately transformed into IBM products, was available to others. Some eventually did get rolled in to at least consulting services work (particularly in the Apache space).
Sounds like your F100 was all about killing golden-egg laying geese. And I understand your response entirely.
The problem being that there's a lot of cool stuff you can work on at the labs, but unless there's a $50m or $100m market for it, there's no interest in productizing the project.
What creating a culture of allowing work on Free Software projects allowed, among other things, was satisfaction and motivation among the lab engineers in being able to produce work which, even if not immediately transformed into IBM products, was available to others. Some eventually did get rolled in to at least consulting services work (particularly in the Apache space).
Sounds like your F100 was all about killing golden-egg laying geese. And I understand your response entirely.
"Companies: allow your employees to freely work on open-source and it will improve your recruiting."
It will also make it harder/more costly for them to retain their top talent (since external groups will be able to identify them for poaching), so good luck getting many of them to buy into this.
It will also make it harder/more costly for them to retain their top talent (since external groups will be able to identify them for poaching), so good luck getting many of them to buy into this.
Which is no different from having your top talent poached based on resumes or word of mouth.
Quiz: if you're worried about your best employees being recruited away, how do you react?
1. Give them more opportunities to grow, learn, advance, and increase their earnings. 2. Try to chain them to your company with restrictive policies.
If you said "#2", I can tell you why your people are looking elsewhere.
Quiz: if you're worried about your best employees being recruited away, how do you react?
1. Give them more opportunities to grow, learn, advance, and increase their earnings. 2. Try to chain them to your company with restrictive policies.
If you said "#2", I can tell you why your people are looking elsewhere.
What data do you have to support this? I think it's the exact opposite.
It's telling that their "Innovation group" is shackled with the same restrictions as the rest of the company.
What about:
- those that use different VCSs?
- people who don't have the time (due to their job or other circumstances) to work on things they can open source?
- people who work at companies that essentially own everything they might do so you can't work on open source? and
- companies where hiring goes through HR who won't know what the hell Github is?
Having work on Github is probably a good idea for college students and recent grads but once people are employed it's value drops off significantly (IMHO). From a hiring perspective, you're also greatly limited your field of candidates if you only look at Github profiles.
- those that use different VCSs?
- people who don't have the time (due to their job or other circumstances) to work on things they can open source?
- people who work at companies that essentially own everything they might do so you can't work on open source? and
- companies where hiring goes through HR who won't know what the hell Github is?
Having work on Github is probably a good idea for college students and recent grads but once people are employed it's value drops off significantly (IMHO). From a hiring perspective, you're also greatly limited your field of candidates if you only look at Github profiles.
Regarding different VCSs, the point is that code is the new resume and Github happens to be the most popular place to find it. Links to bitbucket, sourceforge, google code, etc etc are all equally valuable and would have the same impact.
Personal time commitments are understandable, but I feel like they are just an excuse in 90% of the cases. As 37signals puts it, "No time is no excuse". If you are serious about improving your abilities and buy into the craftmanship model at all, you can surely find a few hours of month to work on something, anything. Trade an hour of TV watching for an hour of writing your own blog engine or a Todo list app. Or write something to improve some small bit of your life (a program that emails you once a month to remind you to take your SO out for a nice dinner), put that on github. Don't make it out like you have to write the next Rails or jQuery to put code online.
The rest of your issues are largely related to workplace culture.
If you work at a company that uses any open source code (and I know there are some cases that don't due to federal validation and redtape etc etc), you have probably found a bug at some point. Put in an issue on github - send a pull request if you feel ambitious or if you had to monkeypatch the code for your project anyways. I have a feeling that people that work for closed/IP-hungry companies will go to the same kind of company when they change jobs. And that is fine, for some people software is just a job; but those are not the kind of people that read HN or software blogs anyways.
I know you are probably playing devil's advocate here, but every time someone posts about why developers should have side projects or github accounts, these points all get brought up and it bugs me.
Personal time commitments are understandable, but I feel like they are just an excuse in 90% of the cases. As 37signals puts it, "No time is no excuse". If you are serious about improving your abilities and buy into the craftmanship model at all, you can surely find a few hours of month to work on something, anything. Trade an hour of TV watching for an hour of writing your own blog engine or a Todo list app. Or write something to improve some small bit of your life (a program that emails you once a month to remind you to take your SO out for a nice dinner), put that on github. Don't make it out like you have to write the next Rails or jQuery to put code online.
The rest of your issues are largely related to workplace culture.
If you work at a company that uses any open source code (and I know there are some cases that don't due to federal validation and redtape etc etc), you have probably found a bug at some point. Put in an issue on github - send a pull request if you feel ambitious or if you had to monkeypatch the code for your project anyways. I have a feeling that people that work for closed/IP-hungry companies will go to the same kind of company when they change jobs. And that is fine, for some people software is just a job; but those are not the kind of people that read HN or software blogs anyways.
I know you are probably playing devil's advocate here, but every time someone posts about why developers should have side projects or github accounts, these points all get brought up and it bugs me.
You're expressing a prejudice here and advocating discrimination based on it. It seems ideological. You're saying "Don't hire people if they don't contribute to open source projects." You assume they are watching TV, rather than, say, working on an iOS game that they are selling.
Resumes are for deciding who you're going to interview. If github is the new resume, then you're not going to know about the side projects.
Resumes are for deciding who you're going to interview. If github is the new resume, then you're not going to know about the side projects.
I don't want to turn this into a game of forum post logical proofs.
I don't advocate "don't hire if no OSS". I work with smart people that get stuff done and don't have a Github account. That's fine, it's a personal choice how you use your time.
What rubs me the wrong way is when people say "It's unfair to look at Github as the new resume because I don't have enough time to do open source". Like I said originally, I'm sure someone is going to come along and post about how every hour of their day is being used for meaningful activities, but for the majority of people I don't think that's true.
I don't advocate "don't hire if no OSS". I work with smart people that get stuff done and don't have a Github account. That's fine, it's a personal choice how you use your time.
What rubs me the wrong way is when people say "It's unfair to look at Github as the new resume because I don't have enough time to do open source". Like I said originally, I'm sure someone is going to come along and post about how every hour of their day is being used for meaningful activities, but for the majority of people I don't think that's true.
People are very different. It takes all kinds. The kind of hacker you are, is not the only kind of hacker there is. There can be very bright, excellent engineers, who spend their entire off-duty time watching TV. They don't have a duty to contribute to open source software and choosing not to does not tell you anything about their skills as an engineer.
I remember once a new coworker telling me -- on his first day, no less- that he didn't have a computer at home. He was proud of this. He was a new CS graduate, and for him, computers were not an interest, at all. It was just a job. I asked him what he was into, and it was sports, naturally.
I didn't like that, it rubbed me the wrong way. I probably would have given him the thumbs down if I'd been in the hiring loop then.
Turned out he was a good engineer. Better than that, the sport he was into was one I got into as well and we spent a fair bit of time over the years in our off hours far away from any computers.
I remember once a new coworker telling me -- on his first day, no less- that he didn't have a computer at home. He was proud of this. He was a new CS graduate, and for him, computers were not an interest, at all. It was just a job. I asked him what he was into, and it was sports, naturally.
I didn't like that, it rubbed me the wrong way. I probably would have given him the thumbs down if I'd been in the hiring loop then.
Turned out he was a good engineer. Better than that, the sport he was into was one I got into as well and we spent a fair bit of time over the years in our off hours far away from any computers.
Let me guess - Brazilian Jujitsu.
I guess repeating exactly what he said while managing to sound both disagreeable and condescending is a change from your outright misrepresenting and troll like posts earlier in this thread I'm not sure it's a change for the better.
It bugs you because you don't get get it, freely stereotype and readily tell people how to spend their free time.
I work for a bigco that doesn't contribute to open source. I used to work for a bigco that was one of the biggest contributors to open source. I spend spare time working on an reasonably sized open source project, of which I was one of the founders, hosted on, yes, github. I have interesting (to me, atleast) side projects, mostly hardhacks, which I don't necessarily build to share. I do it for fun. Obviously, I read HN.
I never require open source experience when I hire, because my experience in both the 'closed' and 'open' worlds tells me that great scientists and engineers exist in both worlds and using a VCS account as a filter is crude. This is just another facet.
I work for a bigco that doesn't contribute to open source. I used to work for a bigco that was one of the biggest contributors to open source. I spend spare time working on an reasonably sized open source project, of which I was one of the founders, hosted on, yes, github. I have interesting (to me, atleast) side projects, mostly hardhacks, which I don't necessarily build to share. I do it for fun. Obviously, I read HN.
I never require open source experience when I hire, because my experience in both the 'closed' and 'open' worlds tells me that great scientists and engineers exist in both worlds and using a VCS account as a filter is crude. This is just another facet.
I agree with you that it is another facet. The point I was trying to make is that there is a pretty low barrier to entry to get yourself into that facet. An attitude I see online a lot is that "If I don't do it, it's not valuable" - though this goes hand-in-hand with "I do it, if you don't you are wrong".
I am biased because I do have a github account and work on side projects for fun, but I think it is worthwhile to point out that if time is what you think your limiting factor is (which was the point that cletus made that I was directly addressing), then maybe you aren't really looking hard enough into how you are using your time.
I am biased because I do have a github account and work on side projects for fun, but I think it is worthwhile to point out that if time is what you think your limiting factor is (which was the point that cletus made that I was directly addressing), then maybe you aren't really looking hard enough into how you are using your time.
You have made similar statements about 4 times in this thread ("you aren't really looking hard enough into how you are using your time.", "trade an hour of TV watching for an hour of writing your own blog engine or a Todo list app") already and you basically alienated about 90% of good developers, and you still don't seem to get why your statement is insulting.
Others told you, so try to understand their viewpoint: you are projecting your own prejudices about time and open source. Maybe, if you look at the cold, hard numbers, you may agree that 90% of smart programmers don't have a github account. True or false? If true, then your claims need to be revisited.
Others told you, so try to understand their viewpoint: you are projecting your own prejudices about time and open source. Maybe, if you look at the cold, hard numbers, you may agree that 90% of smart programmers don't have a github account. True or false? If true, then your claims need to be revisited.
Sorry but that doesn't make any sense (and I was a hiring manager for many years). When I want to hire an experienced developer, what matters is the experience they got at their previous employers, the large codebase they worked on there. None of that stuff will be on Github, that's just a fact of life.
Do you hire a developer based on their resume alone? Probably not. The article is saying that Github is the new resume, not that you should only hire people based on what they do on Github. I have no problem if you want me to demonstrate experience from a previous job, but it's not like that is some magic bullet to finding a good hire either. I could easily embellish my experience and you have no way to tell. But experience supported by publicly available code should give you an indication of whether or not I can actually program.
I am happy to discuss it further if there is some part in particular that you disagree with.
I am happy to discuss it further if there is some part in particular that you disagree with.
You wouldn't hire someone based on their resume alone but a resume is usually required. What you're saying is Github is now a requirement which is absurd.
Also this would mean I have to use a particular tool for development (maybe I should be required to only use gcc for my C projects too). A particular tool on a particular site. I like Mercurial. The projects I like to contribute might use Google code. Guess I am going to have a hard time finding a job now.
Also this would mean I have to use a particular tool for development (maybe I should be required to only use gcc for my C projects too). A particular tool on a particular site. I like Mercurial. The projects I like to contribute might use Google code. Guess I am going to have a hard time finding a job now.
I think you are confusing your disagreement with the original article (which I did not write) and my comment. My comment [mainly] addresses the point about that cletus brought up about people that don't have enough time to do open source or side projects.
I did not say anywhere in this thread that Github was a requirement and I don't believe that to be the case. I also assume you read my parent comment in which I addressed the fact that Mercurial-based repository sites and Google Code both achieve the same goal.
I did not say anywhere in this thread that Github was a requirement and I don't believe that to be the case. I also assume you read my parent comment in which I addressed the fact that Mercurial-based repository sites and Google Code both achieve the same goal.
There are plenty of times when a resume is not required for a hire. A recommendation can replace it, chatting with the person in a dev irc channel, contributions to open source, etc.
You aren't required to do any of those things, but it makes sense that the more quality information about yourself available the better your chance at getting a quality job.
You aren't required to do any of those things, but it makes sense that the more quality information about yourself available the better your chance at getting a quality job.
[deleted]
In many cases contributing to open source software can present legal issues with your employer.
Whenever I'm hiring developers (junior through senior) I ask to see any portfolios they might have - github, websites they've built, a zip file of stuff they've written. I don't care what format it comes in. That said, expecting companies to be able to make good hires without having ANY code to look at isn't very realistic. I understand that sometimes people don't have the time / can't share work they do during the course of their job, but it DOES hurt your chances when there is nothing for someone hiring to look at. That said, if you're dedicating all your time to your day job, and presumably you're doing a great job there, then referrals are the way to go. We're always looking for referrals from employees within our company, and have always had the best experience with those hires.
As someone who works in a 'bigco' culture, I would definitely be looking for a github (or other vcs) link on a new hire, regardless of seniority. Of course they might have their own website with some portfolio code, and that is fine too in my eyes. What I'm looking for is the signal that says, "I care about my profession, I go the extra mile".
I care about my profession. I go the extra mile. Last year, I read Programming Language Pragmatics and the Dragon book because the semester I wanted to take programming languages, the course was offered when I had to work and I never got a formal background. Last month I read 22 research papers in ad-hoc mobile networking in an effort to broaden my horizons beyond what I'm currently working on. Sure, I could write ns-2 simulations (and I did plenty of them as part of my MS) but once I understand what I've read, writing the simulation doesn't hold much benefit for me, does it?
None of the work I invest in myself will be available in any form on github because it simply doesn't fit there in any meaningful sense (unless you want me to upload some sort of .txt book report). I spend my "self-improvement" time on conceptual problems that don't map to github or other repositories in any way. If I want to solve a trivial problem, I assume someone else already has (it's probably on github) and there's no point in me reinventing the wheel. What does me writing another ORM tool tell you except that I'm able to copy someone else's ideas?
None of the work I invest in myself will be available in any form on github because it simply doesn't fit there in any meaningful sense (unless you want me to upload some sort of .txt book report). I spend my "self-improvement" time on conceptual problems that don't map to github or other repositories in any way. If I want to solve a trivial problem, I assume someone else already has (it's probably on github) and there's no point in me reinventing the wheel. What does me writing another ORM tool tell you except that I'm able to copy someone else's ideas?
This is not about how good of a programmer you are but about how a hiring manager can decide whether you are a good programmer or not.
When a programmer has an active github account with lots of quality code, hiring manager has an easily verifiable proof of programmer's abilities (or lack of it, if the code is bad).
When a programmer can only talk about papers he read, hiring manager has no way to verify if he actually read those papers and if he understood them.
Reading papers is not worse than programming for professional development but it is worse if you're looking to convince someone to hire you.
Reading papers instead of writing open source code is a valid choice but that's what it is: your choice and it comes with the consequences of not being as attractive for potential employers as people who write high-quality, open source code.
When a programmer has an active github account with lots of quality code, hiring manager has an easily verifiable proof of programmer's abilities (or lack of it, if the code is bad).
When a programmer can only talk about papers he read, hiring manager has no way to verify if he actually read those papers and if he understood them.
Reading papers is not worse than programming for professional development but it is worse if you're looking to convince someone to hire you.
Reading papers instead of writing open source code is a valid choice but that's what it is: your choice and it comes with the consequences of not being as attractive for potential employers as people who write high-quality, open source code.
I can demonstrate it the way people have been demonstrating work ability for years - through a resume and an interview process. I put nothing on my resume I'm not prepared to talk about from start to finish, and I assure you that I've got no trouble finding work I find intellectually and financially agreeable. It doesn't always correlate with my academic interests, but to assume that I'm missing out on opportunities I'd like to have access to is somewhat less than logical.
People have a tiny itch and write a tiny program to solve that itch. That's fine - I have nothing against someone doing that. However, to take that tiny program and others like it as more than minor evidence of programming ability is a huge leap of faith that I'm not prepared to accept.
For example: I work with a guy who just released an Android app that is a Starcraft 2 build order trainer. It runs a timer and displays an image of what you should be building in the game at that exact moment (assuming perfect efficiency). The idea is that you plug in the order you want to build units ahead of time, and you're "racing" the timer to become more efficient. Supposedly he has about a hundred downloads, so it's not a huge success but it's also not an abject failure as far as apps go. Here's my problem. It doesn't DO anything.
It doesn't suggest reordering your build to account for obvious problems (e.g. never building a military unit). It doesn't optimize your build to account for obvious parallels (e.g. it won't tell you it's stupid to queue up units for production when you could put your resources to work elsewhere for immediate benefit). It doesn't even track wins/losses that I know of. It basically displays a series of images based on a script that you provide.
I'm sure it's very well written software based on the contributions he makes to our codebase at work, but it doesn't say very much about him except "here's a guy who was able to write one mobile app." He's not bad at coding, but he's really not great at solving ill-defined problems, and that costs him when he's confronted with something new. For example, he spent a week as part of a performance effort writing an aspect to generate timestamps whenever a method was called and when it returned. This sort of thing is commonly known as a profiler, a tool which we had access to from the start and which would have worked fine for our purposes. He didn't know about that, and wasted a week getting AspectJ set up and configured and writing his homegrown profiler while the rest of us were making actual, obvious performance improvements based on data from a real profiler.
Yet, according to popular wisdom on this thread, his SC2 app proves beyond a shadow of a doubt that he is a demonstrably superior developer to someone who doesn't code in their spare time. Most of the apps and hobby programs I'm aware of fall into this category. My point is that a program is a solution to a problem, nothing more. If you're trying to hire someone to solve problems (e.g. an engineer or developer - what have you), a demonstration that this person can solve relatively trivial problems should not be taken as a bell-ringer for engineering talent like it frequently is.
People have a tiny itch and write a tiny program to solve that itch. That's fine - I have nothing against someone doing that. However, to take that tiny program and others like it as more than minor evidence of programming ability is a huge leap of faith that I'm not prepared to accept.
For example: I work with a guy who just released an Android app that is a Starcraft 2 build order trainer. It runs a timer and displays an image of what you should be building in the game at that exact moment (assuming perfect efficiency). The idea is that you plug in the order you want to build units ahead of time, and you're "racing" the timer to become more efficient. Supposedly he has about a hundred downloads, so it's not a huge success but it's also not an abject failure as far as apps go. Here's my problem. It doesn't DO anything.
It doesn't suggest reordering your build to account for obvious problems (e.g. never building a military unit). It doesn't optimize your build to account for obvious parallels (e.g. it won't tell you it's stupid to queue up units for production when you could put your resources to work elsewhere for immediate benefit). It doesn't even track wins/losses that I know of. It basically displays a series of images based on a script that you provide.
I'm sure it's very well written software based on the contributions he makes to our codebase at work, but it doesn't say very much about him except "here's a guy who was able to write one mobile app." He's not bad at coding, but he's really not great at solving ill-defined problems, and that costs him when he's confronted with something new. For example, he spent a week as part of a performance effort writing an aspect to generate timestamps whenever a method was called and when it returned. This sort of thing is commonly known as a profiler, a tool which we had access to from the start and which would have worked fine for our purposes. He didn't know about that, and wasted a week getting AspectJ set up and configured and writing his homegrown profiler while the rest of us were making actual, obvious performance improvements based on data from a real profiler.
Yet, according to popular wisdom on this thread, his SC2 app proves beyond a shadow of a doubt that he is a demonstrably superior developer to someone who doesn't code in their spare time. Most of the apps and hobby programs I'm aware of fall into this category. My point is that a program is a solution to a problem, nothing more. If you're trying to hire someone to solve problems (e.g. an engineer or developer - what have you), a demonstration that this person can solve relatively trivial problems should not be taken as a bell-ringer for engineering talent like it frequently is.
It doesn't suggest reordering your build to account for obvious problems (e.g. never building a military unit). It doesn't optimize your build to account for obvious parallels (e.g. it won't tell you it's stupid to queue up units for production when you could put your resources to work elsewhere for immediate benefit). It doesn't even track wins/losses that I know of. It basically displays a series of images based on a script that you provide.
So it's a minimum viable product. That's fine, and if I played SC2 I'd find it useful.
He didn't know about that, and wasted a week getting AspectJ set up and configured while the rest of us were making actual, obvious performance improvements based on data from a real profiler
That tells me nothing about his abilities one way or the other; all it suggests is that your team has communication issues.
So it's a minimum viable product. That's fine, and if I played SC2 I'd find it useful.
He didn't know about that, and wasted a week getting AspectJ set up and configured while the rest of us were making actual, obvious performance improvements based on data from a real profiler
That tells me nothing about his abilities one way or the other; all it suggests is that your team has communication issues.
bartonfink,
How will you demonstrate that in ways that I (or a hiring manager/engineer) can see?
Papers? github(bitbucket, sourceforge) code? applications released? conference presentations?
I can hunt down abstract knowledge all day and bloviate like a master, but in the end, it's all hot air if I can't demonstrate my mastery in a concrete fashion.
The advantage people are seeing is that github provides a public mastery demonstration, as well as a view of your work.
How will you demonstrate that in ways that I (or a hiring manager/engineer) can see?
Papers? github(bitbucket, sourceforge) code? applications released? conference presentations?
I can hunt down abstract knowledge all day and bloviate like a master, but in the end, it's all hot air if I can't demonstrate my mastery in a concrete fashion.
The advantage people are seeing is that github provides a public mastery demonstration, as well as a view of your work.
No, you're saying you want an excuse not to hire people who don't contribute to open source on your favorite source hosting site.
No, I want to see someone who has contributed in ways I can see that I can look up and also consider the quality of his work.
My corporate contributions almost certainly will never leave the purview of the company servers. Ergo, if I ever want to show code samples, I will have to write them at home, on my own time.
My corporate contributions almost certainly will never leave the purview of the company servers. Ergo, if I ever want to show code samples, I will have to write them at home, on my own time.
I would suggest gently that pnathan is saying the exact opposite of that.
Certain others with an odd veneration for Github seem to be saying otherwise (see kfalter's post on another subthread), but they are not a majority.
Certain others with an odd veneration for Github seem to be saying otherwise (see kfalter's post on another subthread), but they are not a majority.
While this post talks about GitHub, i think it very well applies to any distributed version control system.
Having an open source project is another means of visibly showing your enthusiasm, and even skill set. Notice how I don't say actual 'skill'. That is always subject to the eye of the beholder.
By your definition, someone better tell https://github.com/jeresig & https://github.com/zedshaw they're JR developers and should go back to school.
Having an open source project is another means of visibly showing your enthusiasm, and even skill set. Notice how I don't say actual 'skill'. That is always subject to the eye of the beholder.
By your definition, someone better tell https://github.com/jeresig & https://github.com/zedshaw they're JR developers and should go back to school.
[deleted]
Github is to coders what an online portfolio/web presence is for designers. Look at the design industry... corporate designers and grads and freelancers used to all have a hard copy, artfully crafted portfolio on sensual-to-touch paper stock.
That's gone. And no one cared if the corporate designers didn't have time to create a website. Even if you still have an amazing portfolio (which is the resume for the designer), you better have something online (whether they are personal projects done outside of work, or glimpses of projects done at work).
The paper resume is going away anyway. And then when HR finally gets up with the times, do you really think they are going to say, "Aww, it's ok, we understand you didn't get on Github because you were waiting for us..." No.
HR people hiring designers using their online portfolio is a lagging indicator. And the same will go for HR people hiring developers based on Github.
That's gone. And no one cared if the corporate designers didn't have time to create a website. Even if you still have an amazing portfolio (which is the resume for the designer), you better have something online (whether they are personal projects done outside of work, or glimpses of projects done at work).
The paper resume is going away anyway. And then when HR finally gets up with the times, do you really think they are going to say, "Aww, it's ok, we understand you didn't get on Github because you were waiting for us..." No.
HR people hiring designers using their online portfolio is a lagging indicator. And the same will go for HR people hiring developers based on Github.
No. Github is that to some coders.
The overwhelming majority of programmers do not use Github for their projects. I would bet that not even a majority of open-source programmers use Github for their projects.
There are alternatives. Quit thinking yours is the only way. It is not.
The overwhelming majority of programmers do not use Github for their projects. I would bet that not even a majority of open-source programmers use Github for their projects.
There are alternatives. Quit thinking yours is the only way. It is not.
[deleted]
A big problem with github-as-resume for the experienced developer is that it destroys the idea of side-projects as play. I can no longer just fool around with something for the sake of fooling around with it. I now have to judge whether my “fool-around” project is good enough to go on github and be evaluated by potential hiring managers. And if not, I need to ask why I’m working on it, rather than working on something that I’d want a hiring manager to see.
Moreover, everything I put out there now needs to be of professional quality, including comments, code organization, adherence to conventions, etc. And from the beginning, because hiring manager might look at logs and frown upon the fact that I inserted a bunch of comments, and cleaned up a much of memory leaks, two days before I applied for the job.
For a side-project in a technology that I use at the office, this basically makes side projects the same as work. Which is going to lead to burnout really fast.
For a side-project in a new technology, I’d be much less inclined to take my time to learn something new. My first few attempts at writing something in a programming language I’m learning are invariably something I don’t want anyone else to see. But again, why would I take time to work on something that I can’t put on github, if that’s how I’m being judged?
Moreover, everything I put out there now needs to be of professional quality, including comments, code organization, adherence to conventions, etc. And from the beginning, because hiring manager might look at logs and frown upon the fact that I inserted a bunch of comments, and cleaned up a much of memory leaks, two days before I applied for the job.
For a side-project in a technology that I use at the office, this basically makes side projects the same as work. Which is going to lead to burnout really fast.
For a side-project in a new technology, I’d be much less inclined to take my time to learn something new. My first few attempts at writing something in a programming language I’m learning are invariably something I don’t want anyone else to see. But again, why would I take time to work on something that I can’t put on github, if that’s how I’m being judged?
Excellent points. If github-as-resume becomes commonplace, we can expect to see lots of methods for gaming it, as Goodhart's law would predict: http://en.wikipedia.org/wiki/Goodharts_law.
Sounds reasonable, but this is how you feel. Personally I like to see the Ruby on Rails tutorial code in someone's GitHub.
One of the key motivators that made me start my own company was this kind of nonsense. Poor managers, having made bad hiring decisions, are always looking for some way to short circuit the process. The entire recruiting agency industry exists for this very purpose (and look how little they know about engineering!)
This does provide a very useful feature for confident, quality engineers: Whenever someone asks for your github ID as part of the hiring process, you can say "Next!"
Seriously, you're an engineer. You can be choosy. And signs of pointy-haired boss syndrome are a good way to choose.
This is one of them.
The correct way to interview someone is to have a stakeholder in the business, who is a competent engineer, look thru the resumes, pick the ones they want to meet with, and bring them in. Talk to them, one on one, for about 30 minutes. (You should know after about 5 minutes, but you want to give them more time so they don't feel like they're being brushed off if you aren't willing to give them the job right then and there. Also, be ready to make an offer, or tell them you'll be making an offer, right then and there.)
If your startup doesn't have a stakeholder in the business whose competent enough to do this, then you still need your technical cofounder. Your technical cofounder cannot be "too busy" to interview engineers.
This does provide a very useful feature for confident, quality engineers: Whenever someone asks for your github ID as part of the hiring process, you can say "Next!"
Seriously, you're an engineer. You can be choosy. And signs of pointy-haired boss syndrome are a good way to choose.
This is one of them.
The correct way to interview someone is to have a stakeholder in the business, who is a competent engineer, look thru the resumes, pick the ones they want to meet with, and bring them in. Talk to them, one on one, for about 30 minutes. (You should know after about 5 minutes, but you want to give them more time so they don't feel like they're being brushed off if you aren't willing to give them the job right then and there. Also, be ready to make an offer, or tell them you'll be making an offer, right then and there.)
If your startup doesn't have a stakeholder in the business whose competent enough to do this, then you still need your technical cofounder. Your technical cofounder cannot be "too busy" to interview engineers.
Frankly, I think you're out of your mind.
You should hire people based on absolutely as much useful information as you can ethically get your hands on. Why waste the information in a person's github profile?
Resumes suck, and are damned near useless. Bringing people in based on resumes wastes your lead engineer's time because the % hit rate on them will be very low. You will, at the very least, need to phone screen somebody that you only know from a resume, a process which takes a surprising amount of time.
Talking to people is totally useful, and necessary, but not sufficient. It's prone to passing bullshitters (esp since you have your best technical person interviewing) and useless smart people (who don't get shit done), and to failing good employees who don't speak well or are having a bad hair/brain day or are very nervous.
When you go to hire, use all the information you can. Look at their github, interview, have the person write code, have lunch with them to see if they get along with the team. Don't fail them for missing any one part of the interview, but take it all into account.
Especially in a small team, you're making an decision with an enormous impact on the future of your company which is difficult and painful to undo. Don't waste any information.
You should hire people based on absolutely as much useful information as you can ethically get your hands on. Why waste the information in a person's github profile?
Resumes suck, and are damned near useless. Bringing people in based on resumes wastes your lead engineer's time because the % hit rate on them will be very low. You will, at the very least, need to phone screen somebody that you only know from a resume, a process which takes a surprising amount of time.
Talking to people is totally useful, and necessary, but not sufficient. It's prone to passing bullshitters (esp since you have your best technical person interviewing) and useless smart people (who don't get shit done), and to failing good employees who don't speak well or are having a bad hair/brain day or are very nervous.
When you go to hire, use all the information you can. Look at their github, interview, have the person write code, have lunch with them to see if they get along with the team. Don't fail them for missing any one part of the interview, but take it all into account.
Especially in a small team, you're making an decision with an enormous impact on the future of your company which is difficult and painful to undo. Don't waste any information.
I find it interesting that you presume the hit rate on bringing people in based on resumes would be very low. I can tell a good engineer from a bad one, pretty well, using resumes.
Phone screens, however are a waste of time. It is difficult to establish rapport with someone over the phone, for both parties, and I've seen some people actually ask programming questions over the phone.
One very good engineer I hired, back before I was running my own show, did terrible on the phone screen.
I brought her in, though, because I saw something in the resume. She's asian and had a real problem talking on the phone, but eventually got the job and was great.
You are making a decision with an enormous impact. Therefore, it is critical that you do it based on a truthful assessment of the candidate-- not ideological prejudice.
Phone screens, however are a waste of time. It is difficult to establish rapport with someone over the phone, for both parties, and I've seen some people actually ask programming questions over the phone.
One very good engineer I hired, back before I was running my own show, did terrible on the phone screen.
I brought her in, though, because I saw something in the resume. She's asian and had a real problem talking on the phone, but eventually got the job and was great.
You are making a decision with an enormous impact. Therefore, it is critical that you do it based on a truthful assessment of the candidate-- not ideological prejudice.
I can tell a good engineer from a bad one, pretty well, using resumes.
I am reminded of a cartoon I once saw. It showed a businessperson meeting another in a typical office. The caption read "We really liked your resume and would be interested in meeting the person it describes."
Obviously you can select the good engineers a resume describes from the bad engineers a resume describes. What you cannot do from the resume alone is deal with false positives in the form of misrepresentations, nor with false negatives from people who are better at programming than they are at writing resumes.
You already know this, that's why you still have interviews. But I hope you can appreciate that additional information can help you pick out some red flags for the "good" resumes, thing you will want to ask about in an interview, and likewise a resume that doesn't seem all that great but is associated with good work on github.... Maybe that's a false negative and you want to interview them anyways to see if they simply suck at resume-writing.
I am reminded of a cartoon I once saw. It showed a businessperson meeting another in a typical office. The caption read "We really liked your resume and would be interested in meeting the person it describes."
Obviously you can select the good engineers a resume describes from the bad engineers a resume describes. What you cannot do from the resume alone is deal with false positives in the form of misrepresentations, nor with false negatives from people who are better at programming than they are at writing resumes.
You already know this, that's why you still have interviews. But I hope you can appreciate that additional information can help you pick out some red flags for the "good" resumes, thing you will want to ask about in an interview, and likewise a resume that doesn't seem all that great but is associated with good work on github.... Maybe that's a false negative and you want to interview them anyways to see if they simply suck at resume-writing.
I once was given a phone interview because a friend of mine knew the hiring manager. The manager really didn't want to waste time with me, he said, because I had just graduated from school, and thus I couldn't possibly be useful to him.
But at my friend's insisting, he gave me the interview, and summarily dismissed me.
A few weeks later the manager was fired from the company for some sort of unprofessional behavior, and replaced by someone who had just graduated from school.
But at my friend's insisting, he gave me the interview, and summarily dismissed me.
A few weeks later the manager was fired from the company for some sort of unprofessional behavior, and replaced by someone who had just graduated from school.
I'm not sure the point you're making, but I should have said "phone interviews, at least for me, are a waste of time."
I would have brought you in face to face... a recommendation from someone already working there is a very valid positive signal.
I would have brought you in face to face... a recommendation from someone already working there is a very valid positive signal.
[deleted]
Phone interviews aren't that bad, IMO, with proper use of http://i.seemikecode.com or something similar. But when there's a language barrier of some kind, they're definitely not going to be as useful.
Whenever someone asks for your github ID as part of the hiring process, you can say "Next!"
Yes you can, but your words do not convince me that this is a sound job-seeking strategy. You say:
...have a stakeholder in the business, who is a competent engineer, look thru the resumes, pick the ones they want to meet with, and bring them in.
To persuade me, you must establish that the companies with a strategy of "look thru the github profiles, pick the ones they want to meet with, and bring them in." Everything else, the thirty minute interviews and what-not, can be identical between the resume-driven filtering companies and the github-driven filtering companies.
I am not saying that selecting candidates on the basis of a github profile is superior to selecting candidates on the basis of resumes, or--even better--selecting candidates on the basis of either an outstanding resume or an outstanding code portfolio (my personal choice).
But your claim is that as a job-seeker, the best strategy is to refuse to interview with companies that select candidates to interview on the basis of their github profile or who want to discuss it in an interview. The onus is on you to establish that this is such an obviously unsound practice that you can infer that these companies are poor places to work once you receive an offer and accept it.
Yes you can, but your words do not convince me that this is a sound job-seeking strategy. You say:
...have a stakeholder in the business, who is a competent engineer, look thru the resumes, pick the ones they want to meet with, and bring them in.
To persuade me, you must establish that the companies with a strategy of "look thru the github profiles, pick the ones they want to meet with, and bring them in." Everything else, the thirty minute interviews and what-not, can be identical between the resume-driven filtering companies and the github-driven filtering companies.
I am not saying that selecting candidates on the basis of a github profile is superior to selecting candidates on the basis of resumes, or--even better--selecting candidates on the basis of either an outstanding resume or an outstanding code portfolio (my personal choice).
But your claim is that as a job-seeker, the best strategy is to refuse to interview with companies that select candidates to interview on the basis of their github profile or who want to discuss it in an interview. The onus is on you to establish that this is such an obviously unsound practice that you can infer that these companies are poor places to work once you receive an offer and accept it.
It is an obviously unsound practice because at its core is an ideological prejudice: We're going to judge you, not on the quality of your skills, but on whether you contribute to open source software or not.
Candidate are better off working for companies that are interested in getting to know them in order to make hiring decisions, rather than running them thru a political correctness filter.
I don't really care whether I convince you or not. I believe the basis for wanting someone's github id is a prejudice, and I've not had luck convincing prejudiced people that they shouldn't discriminate.
Candidate are better off working for companies that are interested in getting to know them in order to make hiring decisions, rather than running them thru a political correctness filter.
I don't really care whether I convince you or not. I believe the basis for wanting someone's github id is a prejudice, and I've not had luck convincing prejudiced people that they shouldn't discriminate.
We're going to judge you, not on the quality of your skills, but on whether you contribute to open source software or not.
That's interesting. I don't see it that way, and neither do a lot of other people. Here's how I see it: Those people that do write code I can review provide me with more information than those that don't. They make my job easier. I judge the code, not whether the code is open source.
This is exactly the same phenomena as writing a readable resume, or blogging where I can read it. It increases their chances of being hired simply because they reduce the friction involved in the hiring process.
Now, does that mean that I will not hire someone who doesn't have a github account? No. It's my job to hire them too. But as an employer, it is remiss of me not to use all of the information available to judge hires. This is not prejudice, this is a business strategy.
Your words seem to indicate this is not a question of tactics and strategy. You introduce a lot of emotional rhetoric such as "political correctness." Frankly, I have NO idea what you are talking about, as Github has zero to do with whether one uses the word "bitch" in a presentation at a conference ;-)
I cannot read your mind, but in the conversation between you and I, YOU are the one introducing emotional baggage like "ideological prejudice," not me. I therefore suggest that if you want to stamp out all this zeal and prejudice, you start with YOURSELF. I am not the one claiming that people who write things I can read are or aren't better than those who don't. I am not the one with an axe to grind. I am simply a fellow trying to get my job done and looking for efficient and effective strategies for doing so.
That's interesting. I don't see it that way, and neither do a lot of other people. Here's how I see it: Those people that do write code I can review provide me with more information than those that don't. They make my job easier. I judge the code, not whether the code is open source.
This is exactly the same phenomena as writing a readable resume, or blogging where I can read it. It increases their chances of being hired simply because they reduce the friction involved in the hiring process.
Now, does that mean that I will not hire someone who doesn't have a github account? No. It's my job to hire them too. But as an employer, it is remiss of me not to use all of the information available to judge hires. This is not prejudice, this is a business strategy.
Your words seem to indicate this is not a question of tactics and strategy. You introduce a lot of emotional rhetoric such as "political correctness." Frankly, I have NO idea what you are talking about, as Github has zero to do with whether one uses the word "bitch" in a presentation at a conference ;-)
I cannot read your mind, but in the conversation between you and I, YOU are the one introducing emotional baggage like "ideological prejudice," not me. I therefore suggest that if you want to stamp out all this zeal and prejudice, you start with YOURSELF. I am not the one claiming that people who write things I can read are or aren't better than those who don't. I am not the one with an axe to grind. I am simply a fellow trying to get my job done and looking for efficient and effective strategies for doing so.
" if you want to stamp out all this zeal and prejudice, you start with YOURSELF."
You're talking to the person, rather than the point. In fact, looking at your original response, it is constructed to do the same thing.
I'm done here.
You're talking to the person, rather than the point. In fact, looking at your original response, it is constructed to do the same thing.
I'm done here.
[deleted]
I literally cannot believe that you have no interest in evaluating a programmer's code base for the purposes of a hire. That is so unbelievably counterintuitive and, well, just not very smart.
There are two issues with this.
1. It excludes developers who have managed to find jobs that are sufficiently challenging, difficult, and interesting that their jobs keep them fully occupied, and so they simply do not have the time or energy left over to contribute to a bunch of open stuff on Github.
2. What happens after you hire someone? Do you have any policy to ensure that the job won't take too much of their time, or won't be too challenging and interesting, so as to leave them the time and energy to continue working on various open stuff on Github?
1. It excludes developers who have managed to find jobs that are sufficiently challenging, difficult, and interesting that their jobs keep them fully occupied, and so they simply do not have the time or energy left over to contribute to a bunch of open stuff on Github.
2. What happens after you hire someone? Do you have any policy to ensure that the job won't take too much of their time, or won't be too challenging and interesting, so as to leave them the time and energy to continue working on various open stuff on Github?
I love Github, but I certainly must agree with point number 1. I work as a CTO at a start-up here in SF full-time (which means, 8am-2am). We have to a lot of developers and designers around the world which means when I'm not coding, chances are I'm managing. This leaves me very little time to contribute to my own personal projects, much less open source projects.
I'd say that using Github as a resume is a great idea for Jr. Developers and students looking to get some "cred" in the real world. But that really just refers back to knowing your industry and being professional about your work.
I'd say that using Github as a resume is a great idea for Jr. Developers and students looking to get some "cred" in the real world. But that really just refers back to knowing your industry and being professional about your work.
Everyone missed the part where I found myself contributing to several open-source projects, naturally.
Here's an example: we use this gem called "analytical". Its configuration didn't support test vs. dev vs. production. I could have hacked on top of it - it would have added some gross code to my project. Instead I changed the original - turned out to be less code overall and didn't pollute anything in my work project. My pull request (https://github.com/jkrall/analytical/pull/17) still hasn't been accepted, but we use the fork.
I just think that the reason you're not contributing to OS is not time, it's that you choose to design within the box.
Here's an example: we use this gem called "analytical". Its configuration didn't support test vs. dev vs. production. I could have hacked on top of it - it would have added some gross code to my project. Instead I changed the original - turned out to be less code overall and didn't pollute anything in my work project. My pull request (https://github.com/jkrall/analytical/pull/17) still hasn't been accepted, but we use the fork.
I just think that the reason you're not contributing to OS is not time, it's that you choose to design within the box.
Interesting considering he works from 8am-2am. How on earth do you come to the conclusion he's not contributing to OS because he chooses to design within the box?
The kind of person that has two-dozen active GH repos is, strangely enough, the kind of person that must be actively challenged at work in order to not get bored with work and spend all their time on open-source stuff. My work bugtracker tends to be sorted so that I can go after the toughest bugs first. :3
this may be true in startup land, where hires are evaluated by the engineers/managers/founders but it's absolutely not the case in the world of BigCorps. many recruiters (including internal ones) are less technical than anyone would like and have to operate on looking at key words in a resume before deciding what to pass along to managers. a github account with a bunch of code in it would be so confusing they'd just move on.
if you're looking for work, it's worth knowing how to put together a good resume just so it gets you by the HR department.
i've also had experience where i was required to write (non trivial) sample code with my application, only to find out months after i started the job that nobody even looked at it.
code samples and projects are great to have, and especially helpful if someone cares, but the resume isn't dead yet.
if you're looking for work, it's worth knowing how to put together a good resume just so it gets you by the HR department.
i've also had experience where i was required to write (non trivial) sample code with my application, only to find out months after i started the job that nobody even looked at it.
code samples and projects are great to have, and especially helpful if someone cares, but the resume isn't dead yet.
Not everyone reviewing resumes at BigCorps are bad. For what it is worth I work for 'BigCorp' and when looking for new guys on my team I do read any code I am given and go out looking for any code on GitHub and elsewhere. Internal transfers are easier as I don't have to do any hunting and just go looking through our internal repository at their commits.
I agree, a recruiter is not going to know what to look for on github. But the engineering team should, if they are worth joining. I think sites like coderwall.com and vizualize.me are interesting in that they summarize your experience to get you past the initial quick screening.
I think you're mixing up BigCorps with IncompetentCorps.
I've had plenty of BigCorps asking me to interview with them based solely on my open source work (they contacted me). Those were companies like Amazon, Google, Twitter etc. (companies I would consider working for). So I know that this advice works also in the context of BigCorps that are technical and competent.
I haven't had similar offers from GM or WalMart or Shell (or name-your-own-bigcorp) even though I'm sure they also hire programmers.
But given that I do have an option of working at a company like Google, I wouldn't even consider working for GM, which, and that's an educated guess, doesn't pamper their employees as much as Google, doesn't pay them as well and doesn't respect them as much.
So add that as one more benefit of github-as-a-resume model: it attracts companies that treat programmers extraordinarily well so not only you get more work opportunities but those opportunities are of the highest quality.
I've had plenty of BigCorps asking me to interview with them based solely on my open source work (they contacted me). Those were companies like Amazon, Google, Twitter etc. (companies I would consider working for). So I know that this advice works also in the context of BigCorps that are technical and competent.
I haven't had similar offers from GM or WalMart or Shell (or name-your-own-bigcorp) even though I'm sure they also hire programmers.
But given that I do have an option of working at a company like Google, I wouldn't even consider working for GM, which, and that's an educated guess, doesn't pamper their employees as much as Google, doesn't pay them as well and doesn't respect them as much.
So add that as one more benefit of github-as-a-resume model: it attracts companies that treat programmers extraordinarily well so not only you get more work opportunities but those opportunities are of the highest quality.
for what it's worth, my experience comes from getting hired at vmware and ITA software (now google). in my experience, the recruiters who source and filter resumes at those companies are rarely technical.
Nah, not really, because "a github account with a bunch of code in it" is the signal.
Of course, it can be gamed by someone who just forks a bunch of other people's repos, which a recruiter won't be able to spot but "github" is a keyword that can be searched for on a CV like any other.
Of course, it can be gamed by someone who just forks a bunch of other people's repos, which a recruiter won't be able to spot but "github" is a keyword that can be searched for on a CV like any other.
I like the idea of GitHub as a resume, but most of the code I drop in GitHub is closed source and I don't spend a lot of free time hacking on other people's projects. So, while a GitHub resume is a great idea if you do a lot of open source hacking, it is not nearly as useful if you are working on private code.
My day-to-day tasks are all around private repos too. But for some reason I keep having to patch, fix, edit, hack other people's open source projects. If you don't, maybe it's time to look for a piece inside a private repo that could be useful to others and spend the extra time extracting it into something open-source?
Yeah. I mean, accountants and lawyers don't publish accounts and cases they've worked on pro-bono do they?
not yet but I think as far as making use of the web, devs are on the early start of a trend. Think about blogs, they were widely used in the tech community before mass adoption, now my mom even has one. I suspect you will find more and more industries figuring out ways to share their professional experience online
So do yourself a favor and move to Github!
How, exactly, would i be doing myself a favor with this? I'm not such a big fan of git and i avoid github on moral grounds[1]. Other code hosting services work great for me and i see no reason to switch both my hosting and my VCS.
I don't disagree with the argument that your code should act as your resume, but it could have been worded a lot better.
[1] I can't in good conscience support the guy who posts things like this routinely: http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucke... and http://whygitisbetterthanx.com/
How, exactly, would i be doing myself a favor with this? I'm not such a big fan of git and i avoid github on moral grounds[1]. Other code hosting services work great for me and i see no reason to switch both my hosting and my VCS.
I don't disagree with the argument that your code should act as your resume, but it could have been worded a lot better.
[1] I can't in good conscience support the guy who posts things like this routinely: http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucke... and http://whygitisbetterthanx.com/
Wooooow. I already wasn't a fan of Git or Github, but those links are vomitous.
"Waah, they copied us!" Maybe. "PLAGIARISM!" Not so much.
"Waah, they copied us!" Maybe. "PLAGIARISM!" Not so much.
No, github is not your new resume. Remember the post from Marco? You need to own your identity[1]. You do not own your github account.
If you really want to show that you are a good coder, you need your own website as a central point with aggregation of your information from other sources. Github is really nice, but in 5 years, they may have sold themselves to BigCorp for BigMoney and the BigCorp could completely destroy github.
Be it github or the next "cool company", do yourself a favour, build your own site at the centre. Of course, you can open source the code on github or the next cool git/svn/hg hosting company too. Double win.
[1]: http://www.marco.org/2011/07/11/own-your-identity
If you really want to show that you are a good coder, you need your own website as a central point with aggregation of your information from other sources. Github is really nice, but in 5 years, they may have sold themselves to BigCorp for BigMoney and the BigCorp could completely destroy github.
Be it github or the next "cool company", do yourself a favour, build your own site at the centre. Of course, you can open source the code on github or the next cool git/svn/hg hosting company too. Double win.
[1]: http://www.marco.org/2011/07/11/own-your-identity
Along these lines, David Coallier created a tool to generate your github "résumé" awhile back: http://resume.github.com/
As unshift mentioned, the entire development community is not quite at the point where a github account can be used as your go-to résumé, but it is certainly becoming more and more useful in the job market.
As unshift mentioned, the entire development community is not quite at the point where a github account can be used as your go-to résumé, but it is certainly becoming more and more useful in the job market.
cool, thanks for mentioning resume, I've never seen it!
While this works for freelancers/students/startupers, it doesn't work very well for people working in bigger companies.
If your interests are related to your day job, I think it's quite risky to put your code on GitHub, even if the code is not "official". While I do have a GitHub account with some code in it, that code is not really representative.
If having a relevant GitHub account becomes a pre-requisite, you may be overlooking some good people.
> you may be overlooking some good people.
Every heuristic overlooks good people.
This heuristic has the advantage of having next to no false positives, even though it allows for lots of false negatives. Given that false positives are absolutely disastrous while false negatives are merely unfortunate, it's a trade-off I'm happy to make.
Every heuristic overlooks good people.
This heuristic has the advantage of having next to no false positives, even though it allows for lots of false negatives. Given that false positives are absolutely disastrous while false negatives are merely unfortunate, it's a trade-off I'm happy to make.
I guess the majority of repos are either bigger and useful open source projects or just small toys.
If you're looking at somebody with repos from the first category, most likely his resume will mention "author/ contributor to project X".
For the people in the second category, only thing you'd infer is that they can somewhat code. Which you could assume as well if they worked on any delivered project.
There are obviously exceptions in both cases.
Yep. Without thinking, I used code for an open source library I had written in my spare time in our proprietary software, and it came up during a due diligence check for acquisition.
Wasn't a big deal in the end, I just made sure it was using a commercial friendly license, but you do have to take care.
If it was a US employer they may have sued me if they didn't think that the OSS code came before the inclusion in the product (which it did).
Wasn't a big deal in the end, I just made sure it was using a commercial friendly license, but you do have to take care.
If it was a US employer they may have sued me if they didn't think that the OSS code came before the inclusion in the product (which it did).
GitHub in particular is problematic for those of us that don't particularly use Git, and use other hosts for their code.
Something like ohloh is much better suited to being a CV.
Something like ohloh is much better suited to being a CV.
Agreed. Git is obnoxious and Github offers me nothing, which is why I use Atlassian's Bitbucket. But the assumption, silly and unpleasant as it is, is that "everyone uses Github." Well, no, they don't. I really could not care less "where the code is," as per the sibling post to this one; I care for "where things don't aggravate the hell out of me," and that's emphatically not Github.
I disagree, however, regarding Ohloh--too chaotic, too messy, too many false positives. I don't think that, right now, there's a good solution. Something to think about, I guess...
I disagree, however, regarding Ohloh--too chaotic, too messy, too many false positives. I don't think that, right now, there's a good solution. Something to think about, I guess...
If you're using Mercurial instead of Git you can create a mirror on GitHub with little effort (unless you're doing something pretty crazy with your DAG): http://hgtip.com/tips/advanced/2009-11-09-create-a-git-mirro...
This also lets git users contribute to your project, so you get the benefit of GitHub's community without having to deal with git.
This also lets git users contribute to your project, so you get the benefit of GitHub's community without having to deal with git.
Interesting, but this doesn't address the other problem--I fundamentally dislike Github! (I use Bitbucket because of consistently stellar support from Atlassian and an overall pleasant working experience.) And going outside my current, working ecosystem for benefits I consider dubious at best--the overwhelming majority of open-source projects get no outside commits, ever, and magic Github pixie dust doesn't really change that--isn't really a good use of time.
For me, Git and Github are both problems with this "GitHub's your resume" thing, not one or the other.
For me, Git and Github are both problems with this "GitHub's your resume" thing, not one or the other.
I'm sure a bucket full of your source code on bitbucket will serve the same purpose when interviewing. I'm on the job hunt and in interviewing with some YC startups we haven't really gotten to my github, since they more were interested in some of the closed-source projects I've done at other jobs. I think the overall point of the article is to be able to show people you can code rather than just list it as a bullet point in a document.
The assumption, however, that everyone uses Github results in processes having a dependency on Github. Which is stupid.
We use github, but have a fallback server.
Sorry--I meant social processes. If the mindset is that "Github is your resume," then the focus is that Github is your resume, and the line of thinking goes, so to speak, "if it's not on Github, they don't have it." Which is not good.
While social networking makes sense to have a single central location makes sense (but not totally so, see G+ v. Facebook), writing code does not.
While social networking makes sense to have a single central location makes sense (but not totally so, see G+ v. Facebook), writing code does not.
So BitBucket is your resume. Where's the problem?
My resume is my resume. My personal code is closed-source, with the exception of a couple of bits for presentations and an archived project for which I am a maintainer. You could say that "well, that one archived project is your resume," but that would be foolish (not that you are saying that, but it does follow from all of this) because it has little to do with what I actually do.
More than anything, though, I kind of find all this "anoint the buzzwordy startup as the new X" stuff silly. Maybe one company in ten would actually follow a link to Github or Bitbucket on my resume, regardless of the content. At least for now, the resume is the new resume.
More than anything, though, I kind of find all this "anoint the buzzwordy startup as the new X" stuff silly. Maybe one company in ten would actually follow a link to Github or Bitbucket on my resume, regardless of the content. At least for now, the resume is the new resume.
Is there a particular reason why your personal code is closed source.
My current personal project is a cross-platform game framework for Windows, OS X, Linux, Android, iOS, 360, and WP7. It may be commercializable, and as such open-sourcing it makes little sense. If it's not, then when I'm done with it I'll likely open-source it.
Ohloh has everything but the code.
It reminds me of those "CSS galleries" but for open source projects.
In the end, I'm where the code is, and that place is GitHub.
It reminds me of those "CSS galleries" but for open source projects.
In the end, I'm where the code is, and that place is GitHub.
I recently started a new job and their recruiter found me through my Github profile. Aside from that, I put my Github link on my CV and have for a while.
Additionally, when I am interviewing others, I always like to see a Github link or will Google them to find a Github account. Even though people may work a lot in closed source, it is interesting to see the activity history, to see which projects they've forked, patched, written, or contributed to.
It sometimes varies based on the community you're in, but the Ruby community is very collaborative and sharing contributions. Even when I've worked in largely closed source codebases, I'll still encounter bugs in other libraries, fork them, fix it, and send a pull request. Those all show in my repo list and activity feed.
Additionally, when I am interviewing others, I always like to see a Github link or will Google them to find a Github account. Even though people may work a lot in closed source, it is interesting to see the activity history, to see which projects they've forked, patched, written, or contributed to.
It sometimes varies based on the community you're in, but the Ruby community is very collaborative and sharing contributions. Even when I've worked in largely closed source codebases, I'll still encounter bugs in other libraries, fork them, fix it, and send a pull request. Those all show in my repo list and activity feed.
I don't use a public Github because my interesting code often isn't something I want to share with the public, particularly if it happens to include AWS credentials, API keys to various services, etc. All my most interesting sites have been money making endeavors as well, so I don't see any reason to give away the source code, or share it with the public. I do share the URL of the finished product, though, and that has been enough to land me quite a number of job offers, including the one that led to the startup position I am filling right now.
I've never made a traditional resume, and I've never made my code publicly accessible on Github but I've gotten along fine.
I've never made a traditional resume, and I've never made my code publicly accessible on Github but I've gotten along fine.
You should really be factoring out sensitive information from your repos anyway.
I usually put my credentials in a separate include file and then filter it out with gitignore.
"Your first job should be at an organization that embraces open-source and lets you contribute to existing projects. Other companies simply don’t deserve you."
Oh, I had to laugh at that. Good luck explaining that one to the wife. I'm sorry honey, the pay way great, the benefits were good, there was an excellent health plan and even a stock buy-in option.... if ONLY they had agreed to embrace open source so I could work there.
Oh, I had to laugh at that. Good luck explaining that one to the wife. I'm sorry honey, the pay way great, the benefits were good, there was an excellent health plan and even a stock buy-in option.... if ONLY they had agreed to embrace open source so I could work there.
You're implying that a company that encourages open-source contributions sucks at pay, benefits, health plan and stock. You should know that generally startups, which by definition encourage more open-source contributions, have comparable pay, benefits, health plans and stock after their first round of financing. There's more risk in theory, but the numbers since the financial crisis are against this theory.
If open source is so important to our hypothetical you that you'd turn down an otherwise-great job over it, why did you marry someone who is so unsupportive of it? Even if your SO is 'bad with computer', presumably they know how much you value "open-source" (whatever the heck that is). Sounds like hypothetical you made some poor life choices.
I wonder if programmers are going to overwork themselves at some point.
Judged by programming OUTSIDE of work time. Not having free time to do this is not an excuse.
gf/bf/wife/husband/son/daughter/parents/dog/cat/friends/life will have to understand that you need time for your craft.
I currently have time to do programming in my spare time, but I worry that in a few years my time won't be as free.
Judged by programming OUTSIDE of work time. Not having free time to do this is not an excuse.
gf/bf/wife/husband/son/daughter/parents/dog/cat/friends/life will have to understand that you need time for your craft.
I currently have time to do programming in my spare time, but I worry that in a few years my time won't be as free.
If that was to become true, it'd be great to be able to curate your profile. At the moment your repos appear in order of newness, and an unchanged fork of someone's repo could be the first thing potential employers see.
> College and Personal Projects
At the risk of stating the obvious, I'd strongly recommend against putting school projects in a public repo. You might disagree with the ethics of it, but if someone submits your code to your own school, you could conceivably be held responsible for facilitating plagiarism.
At the risk of stating the obvious, I'd strongly recommend against putting school projects in a public repo. You might disagree with the ethics of it, but if someone submits your code to your own school, you could conceivably be held responsible for facilitating plagiarism.
I am shocked. What kind of pojects are those? Does anyone believe that students were waiting for this "internet" thing to share source?
At first I thought "No, LinkedIn is my New Resume."
But then I realized neither are. Because when a recruiter wants a resume, they want to see a concise document that details exactly how your experience matches their job requirements. Github can't be that because it would require that (probably non-technical) recruiter to slog through a lot of stuff to get to what they want to see. Which none of them will actually do.
But then I realized neither are. Because when a recruiter wants a resume, they want to see a concise document that details exactly how your experience matches their job requirements. Github can't be that because it would require that (probably non-technical) recruiter to slog through a lot of stuff to get to what they want to see. Which none of them will actually do.
I put my stuff up on Github in part because I like being part of a community. It also has the nice side effect that it shows that I'm intellectually curious and like trying out new things. If someone is looking for a new hire with those qualities, it'll be a big benefit.
If they're not I don't really want to work there to be honest.
If they're not I don't really want to work there to be honest.
I certainly believe this to be a trend. I have been interviewing with different startups and they all have seemed to respond more to my github page than my resume. They all want to hear about personal projects and your thought process through them. Maybe I'm biased towards startups though.
I use zerply. The name is terrible but I like their service and don't see myself updating my "traditional" cv in the near future. That could change but I'll resist it.
Might be a nice recruiter filter too. If you tell them you don't have a resume and point them at your github or whatever else and it's not good enough you probably dodged a bullet. If they are fine with it then perhaps you found the proverbial needle in the haystack and could give the recruiter a chance.
Might be a nice recruiter filter too. If you tell them you don't have a resume and point them at your github or whatever else and it's not good enough you probably dodged a bullet. If they are fine with it then perhaps you found the proverbial needle in the haystack and could give the recruiter a chance.
Github[0] gives Junior developers another way to get an interview. Those with minimal professional experience are able to show - to some degree - that they can code, use a VCS and have an understanding of the push/pull/fork contribution model. Bonus points for contributions, bug reports etc.
I don't believe it replaces one, but for those without a well-seasoned resume, a Github profile works well as a conversation starter.
[0] Or any public VCS, of course.
I don't believe it replaces one, but for those without a well-seasoned resume, a Github profile works well as a conversation starter.
[0] Or any public VCS, of course.
Anything that can quickly prove you are awesome can be your resume. TopCoder, your LinkedIn profile, the list of hacks and demos that you've put together yourself, I think they all fit this category.
Did you create some awesome project on GitHub (or on any other CVS for that matter)? Then you have something to show off.
But none of them in themselves will help you get hired. They will maybe help you get to the interview.
Did you create some awesome project on GitHub (or on any other CVS for that matter)? Then you have something to show off.
But none of them in themselves will help you get hired. They will maybe help you get to the interview.
Not in my experience. Most job boards are dominated by technical recruiters so, to get in through them, you play by their rules.
In their world, web presence of projects almost never counts. The rationale is that "anyone can point to my work and claim they did it." The preference for assessment is still resume keywords, good references, and multiple choice tests.
In their world, web presence of projects almost never counts. The rationale is that "anyone can point to my work and claim they did it." The preference for assessment is still resume keywords, good references, and multiple choice tests.
There's a huge trend of engineering managers to take things in control to avoid this. Every time I had an HR person between me and a candidate they managed to screw something up. Here're some better job boards.
http://wearenytech.com/jobs (New York based) http://careers.stackoverflow.com
http://wearenytech.com/jobs (New York based) http://careers.stackoverflow.com
I'm liking this trend you speak of but it hasn't reached everywhere yet. I live in the middle of Connecticut and there are 2 companies total that post anything on the Stack Overflow boards. So, the reality of the situation would seem to leave 3 options for people in my neighborhood.
1. Play by the rules of the local recruiters. 2. Telecommute. 3. Move.
1. Play by the rules of the local recruiters. 2. Telecommute. 3. Move.
On a related note, you can actually add your github repo details to your LinkedIn profile via their OpenSocial app. I have found it super useful when looking at people.
http://www.linkedin.com/opensocialInstallation/preview?_ch_p...
http://www.linkedin.com/opensocialInstallation/preview?_ch_p...
I had this crazy idea that I'd buy a vanity domain with my name in it. Use it as my personal email, which is used an all kinds of technical newsgroups. Setup a web page where I described myself, linked to various projects, source code, etc. A site that has a better indication of my personality than github ever would, and has some projects that will never go in github for various reason.
After seeing the last one of these articles, I actually put a note on my github site directing people to my primary site. Seems silly that I felt I had to do this, but oh well.
It's also a shame that the last few patches I did, involving smartcard hardware for gnupg, doesn't get me any bonus points, since that project, like a majority of major projects, hosts its own version control. Not to mention, 9 times out of 10 when I open an issue on a github project, I hear nothing back, making me really unmotivated to fork the project and fix something.
After seeing the last one of these articles, I actually put a note on my github site directing people to my primary site. Seems silly that I felt I had to do this, but oh well.
It's also a shame that the last few patches I did, involving smartcard hardware for gnupg, doesn't get me any bonus points, since that project, like a majority of major projects, hosts its own version control. Not to mention, 9 times out of 10 when I open an issue on a github project, I hear nothing back, making me really unmotivated to fork the project and fix something.
I did the reverse - had a vanity domain and all that stuff, then just tacked my Github account onto it.
Also, why not find your patches from http://git.gnupg.org ?
Also, why not find your patches from http://git.gnupg.org ?
You're not your Github account. You're not your Facebook account. You're not the car you drive. You're not the contents of your wallet. You're not your f'ing open source project.
I don't espouse the negativity in Fight Club, but the quote that I've adapted seems particularly relevant here.
"Facebook users 'are insecure, narcissistic and have low self-esteem'" http://www.dailymail.co.uk/sciencetech/article-1310230/Faceb...
I consider Github sort of the developer equivalent of Facebook. Let me clarify that. If you're posting stuff on Github just to impress recruiters and fellow engineers, then it is. If you're using it in a constructive way, less so or maybe not at all. The point I'm trying to make is that there are parallels between the two.
Look. It's good to provide recruiters (by recruiter I mean a real engineer here who is evaluating candidates) evidence that you're skilled. There are many ways to do that. One way would be to bring in code and discuss it. Another way would be to work through programming problems in the recruiter's presence. I'm not talking about "a-ha" brain teasers but real, actual programming. After all, that's what a programmer is (theoretically) being hired to do.
But please do not encourage an arms race where programmers fall over each other trying to see how much code they can post publicly, and how much work they can give away.
I'm highly skilled and my time is precious. I don't spend it looking in front of the (Github) mirror, and I actually charge money for it. Charity is a good thing, but you shouldn't do it to boost your ego and image. And further, if that's all you spend your time doing, I would wonder why you want to work in private industry where the purpose is to make money so we can be employed. You know, engineers at Apple might not have Github accounts, but they are employed and support their families. Apple's work also lifts tons of people out of poverty in China. How many people does your open source project feed?
You guys need to step off the ego train and direct your energy into stuff that actually matters. And you will be happier for it.
I don't espouse the negativity in Fight Club, but the quote that I've adapted seems particularly relevant here.
"Facebook users 'are insecure, narcissistic and have low self-esteem'" http://www.dailymail.co.uk/sciencetech/article-1310230/Faceb...
I consider Github sort of the developer equivalent of Facebook. Let me clarify that. If you're posting stuff on Github just to impress recruiters and fellow engineers, then it is. If you're using it in a constructive way, less so or maybe not at all. The point I'm trying to make is that there are parallels between the two.
Look. It's good to provide recruiters (by recruiter I mean a real engineer here who is evaluating candidates) evidence that you're skilled. There are many ways to do that. One way would be to bring in code and discuss it. Another way would be to work through programming problems in the recruiter's presence. I'm not talking about "a-ha" brain teasers but real, actual programming. After all, that's what a programmer is (theoretically) being hired to do.
But please do not encourage an arms race where programmers fall over each other trying to see how much code they can post publicly, and how much work they can give away.
I'm highly skilled and my time is precious. I don't spend it looking in front of the (Github) mirror, and I actually charge money for it. Charity is a good thing, but you shouldn't do it to boost your ego and image. And further, if that's all you spend your time doing, I would wonder why you want to work in private industry where the purpose is to make money so we can be employed. You know, engineers at Apple might not have Github accounts, but they are employed and support their families. Apple's work also lifts tons of people out of poverty in China. How many people does your open source project feed?
You guys need to step off the ego train and direct your energy into stuff that actually matters. And you will be happier for it.
I actually agree with a lot of stuff here. One should contribute to things that are useful for your job or your future, not spend time polishing your github resume.
I came to this conclusion a while ago and tossed Github Badge (http://drnic.github.com/github-badges/) on my personal site.
[deleted]
cool, similar to coderwall
Ah - I just gave coderwall a try this time. Github's authorization prompt is much clearer now as to what I'm allowing access to.
Its really only true for startups at this point. I've had plenty of interviews with the interviewer scratching their head when I mention github.
I'd be fine working with devs who don't use github, but very alarmed at the prospect of working with anyone who never heard of it (or bitbucket or sourceforge). That betrays a striking ignorance of what's going on in the profession. Actually it might be a decent litmus test, if you have the luxury of avoiding navel-gazing employers.
I must be getting old, but this post strikes me as silly to the point of seeming like a troll. If any hiring managers are seriously discarding candidates that don't use github, well, I think the market will ultimately dictate the utility of this shortcut.
Exactly what I said over a year ago http://news.ycombinator.com/item?id=1472985
Ah, but you were waaay ahead of your time! Now someone else (me) stole your thunder ;)
If you're using this sort of approach, check out www.gitalytics.com, a site I made to automate this sort of search when I was doing it.
No it's not. Github it's a shared repository tool.
Build a bot that can simulate an open source genius via a classic academic technique: Plagiarism.
The algorithm:
Use Github's API and/or Google to find some popular repos.
Fork those repos into a new Github account named (e.g.) "Nicolai".
For each repo, find some other forks of that repo. Grab some branch names and commits from those forks and commit them to Nicolai's fork, under Nicolai's name and with a few Nicolai-specific changes here and there, to commit messages and perhaps to code comments, to obscure the trail. Sprinkle in some choice text from, e.g., Zippy the Pinhead, the Tao te Ching, random comments from Stack Overflow or Lambda the Ultimate... whatever.
Scoring:
For every recruiter who emails Nicolai with an opportunity: one point.
For every interview that Nicolai gets offered: ten points.
For every job offer that Nicolai gets: one thousand points.