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.

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?

That's the art of plagarism - knowing enough to steal well.

http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-c...

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 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.

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.

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.

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 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.

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.

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.

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.

- 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.

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.

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 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 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 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 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.

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.

I am happy to discuss it further if there is some part in particular that you disagree with.

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 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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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 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.

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 would have brought you in face to face... a recommendation from someone already working there is a very valid positive signal.

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.

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.

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.

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'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.

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.

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.

I think Daniel nailed it.

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.

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.

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/

"Waah, they copied us!" Maybe. "PLAGIARISM!" Not so much.

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

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.

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.

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).

Something like ohloh is much better suited to being a CV.

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...

This also lets git users contribute to your project, so you get the benefit of GitHub's community without having to deal with git.

For me, Git and Github are both problems with this "GitHub's your resume" thing, not one or the other.

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.

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.

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.

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've never made a traditional resume, and I've never made my code publicly accessible on Github but I've gotten along fine.

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.

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.

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.

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.

If they're not I don't really want to work there to be honest.

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.

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.

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.

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.

http://wearenytech.com/jobs (New York based) http://careers.stackoverflow.com

1. Play by the rules of the local recruiters. 2. Telecommute. 3. Move.

http://www.linkedin.com/opensocialInstallation/preview?_ch_p...

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.

Also, why not find your patches from http://git.gnupg.org ?

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.