When it comes to hiring, I'll take a Github commit log over a resume any day.
blog.stackoverflow.com
blog.stackoverflow.com
There are a lot of increasingly shrill remarks out there about how everyone should be doing open source projects in their 'spare time', so no-one has any excuse not to have a track record of FOSS contributions... frankly, it's bullshit.
I work in a closed-source shop (for some very good reasons, we can't open) and our devs do sterling work of a sophistication not seen in most projects, open or otherwise, solving a very difficult and rather open-ended algorithmic problem. On a good day, we get a lot of sophisticated work done.
Strangely, at the end of one of these good days, no one wants to go home and write a big fucking pile of code - we have girlfriends/wives/families that haven't seen us for 12 hours and probably aren't going to want to use the remaining hours (and typing time) to write MORE code. Even if that was a good idea - we are paid for full-time work here which means ideally we go home and relax, not flail away on endless side projects.
Calling attention to (say) a 250-line neat hack - say a patch to a driver, or solving some elegant toy problem - would constitute a detraction from the programmers' major contribution at work over the course of years.
I view this new fixation on open source contributions as a continuation of the pathological distrust for programmers' skilled contributions that used to be expressed through high-stakes (or even low-stages) white-board coding challenges. I'm not sure which is more irritating.
You act like the code you've written that no one can see should matter to another company interviewing you. There is no way for a interviewer to verify the work you've done at your previous job. Like it or not, if you are looking for a new job it is your job to impress them. Fail to do that an risk them picking someone else.
The simple, unassailable truth is that having strong contributions to open-source projects is a massive advantage in any resume-scanning and hiring situation. And as a hiring manager, seeing extensive open-source work is better than seeing a resume. That means the advice is ALWAYS good advice. There is never a situation under which the proper career advice is to not do good visible work.
This doesn't mean it's a requirement, or should be a requirement, but it IS a reality. If you choose not to participate, that's fine, but it comes with an inarguable cost. You can try to convince us all that it shouldn't, but it does, and it probably always will.
I am well aware that strong open-source contributions are an advantage. What I find objectionable is not this advantage. It's the fact that failing to secure this advantage is being portrayed as an obvious professional failure that can be simply rectified by working an extra few hours a night on side projects.
It is propaganda from open source people, many of who have achieved considerably less in their open source projects than a casual inspection might suggest. Usually I come away from people's open source projects with a cheerful acknowledgement that this person (a) likes cool stuff and (b) appears to be able to write working code of a kind. This is good - but not that good.
There's a big difference between 'I wrote some code, look at me' and 'I contributed a competitive register allocator to LLVM' or 'I rewrote the scheduling algorithm for major open source FooOS'. The latter are 'strong contributions' and deserve the 'massive advantage' of which you speak. A handful of pet projects constitute a code sample that suggests that the person can form syntactically correct code.
The underlying issue is that from a hiring perspective, all other things being equal, a candidate that can provably show things is ahead of the guy who simple says he can. Even if "we" all sit around and minimize that as some trivial nonsense that anyone could do and that it proves, at best, they can form "syntactically correct code", the fundamentals of the situation haven't changed. Showing is better than saying. It always will be.
There is an undercurrent of a strawman, as well, in this conversation. I don't think anyone out there is taking actual trivial github stuff and basing hiring decisions on it. But I wouldn't be surprised if some superficial github stuff haven't gotten people past a resume screen that they wouldn't have otherwise gotten past.
When someone says he did something, a github commit log showing it is definitely better than just him saying he did it. However, the point you actively dismissed was that a commit log of some mundane contributions is much less impressive than a resume describing work requiring a lot of skill.
'I wrote some code, look at me'
Not that you're totally wrong, but a good open-source project also requires -- documentation, tests, community involvement, real users, gathering feedback from those users, collaboration.Throwing code over the fence is not what open-source is about. I look at it as -- is this person capable of building a product for other people? Is he a team player?
That's not a skill that comes so easily and requires lots of experience or natural talent at other things than churning out code.
Anyone who dreams of becoming faculty must do work that is publishable, which often means taking substantially lower-paying "research" versus "corporate" internships throughout their younger years.
At the same time, seeing how you handle version control, how you deal with contributors and bug reports, all that matters. Being able to see that is much better than taking one's word for it.
So yes, as someone who previously worked on a shop where no code would get out, I can relate to the feeling. But the above is still true. A few things you can do about it:
- open not the products you have entirely, but modular parts of it. - should the previous suggestion not be an option, get the company to run a blog, and have you/your workmates share solutions at a discussion level. - get the company to allow developers to work 10%, or 20% of their time, on open source. It'll help keeping you guys sharp, at the same time it helps you putting a name out there.
Saying "no one wants to go home and write a big fucking pile of code" probably means that regardless of technical aptitude, you wouldn't fit in well with the kind of folks who love and encourage doing just that in their spare time. Most of the developers on our team have and love "endless side projects."
Not bullshit, just different.
I also can't trust your references, because you'll only give me ones that will say good things about you, and any digging at your work history will only uncover "yes he worked here" responses.
I want to see open-source contributions because I like being around people who are passionate about solving problems with code, and it is my experience that people who contribute to open-source projects, or start their own, are of that mindset.
I don't think that they are the only people who are passionate, but I want to make a choice so I can get back to solving problems.
If you're making the hiring people work harder, you're going to miss out. Being able to show examples of your work is the best way to do it.
How do you feel about tests? or "write this program that does [x]" spec projects instead?
It comes down to this: filtering by OSS contributions gives you many false negatives (as the OP has complained) but virtually zero false positives. In hiring, a false negative is a bummer, but a false positive is disastrous. It would be irresponsible of me as an interviewer not to take this into account.
If it someone's pissed because they fall into the false negative bucket, that's rough, but I'm the one calling the shots and taking the risks.
(1) The person can apparently code when he's allowed to pick what he wants to work on and doesn't have any real pressure, and
(2) He has time to work on open source.
Most companies need people who can code well under pressure and when they have to work on something they don't necessarily want to work on.
By screening by OSS contributions you will indeed eliminate one kind of false positive--they people who can't code at all. Other kinds of false positives, such as people who can't work well except on self-selected projects, will get in.
And from the developer perspective, just the fact that it helps you avoid idiotic CS101 tests over the phone at every interview is enough to make it worth.
How isn't that a disaster?
If a false negative means you have no awesome candidates to choose from, that's a problem.
If a false negative means you have two awesome candidates to choose from instead of three, that's irritating but hardly a disaster.
Realistically, the code and details of are covered by NDA. The task solved, the huge difficulty of same, the overall success of the task being solved, demonstrable fluency in related but public areas of computer science, and the commercial success (modest or otherwise) of the code would not be.
If you don't understand this, or couldn't say the same things about what you're doing, maybe you're not working at the same level, and you are welcome to go fire up the GitHub account and solve tic-tac-toe in Haskell or whatever the hell it is that's meant to be so impressive.
The closest analogy I can come is - say you wrote a pile of LEDA (not a invite to debate if this is a good product, but it's certainly substantial) and you've got references who are in a position to know that say, 'yes, Joe Bloggs really did write all the graph algorithms or geometry algorithms or whatnot in this package'.
Well, you're within your rights to 'not believe a word you've said'. But this falls into the thing I'm complaining about - the whole pathological distrust of programmer achievements. How do you think engineers or commercial research scientists in other fields ever get hired, for fuck's sake?
There's a distrust of programmers because many programmers are not at your skill level. You don't seem to have problems with finding employment. Perhaps open-source contributions don't matter to people of your caliber. But you need to realize that it's not HR or management asking to see your code -- it's your peers.
We need as many metrics as we can to find out who's good and who says they're good. Looking at code and examples of work is exactly how you do that. You can argue all you want, and it may not be fair. Neither is "You have to have a 3.5 GPA to get a job here."
Thats fair, but the thing is that its YOUR PROBLEM(as a recruiter), not mine as a great "closed source" engineer
I know bunch of people who work on very cool and interesting problems/projects binded NDAs and have no problem on finding a new job if they want to. Hell Facebook, twitter, google are all closed source(mostly) so wouldnt you hire ex-Facebook engineer if he has no open source commitments?
Lets face it - its employees market, where companies compete for bright engineers. If you are saying that you only want open source commitments - thats fine, but you are betting on smaller market and missing some great talents. So you are more "lazy" recruiter, who dont want to look deeper, do facts check, test candidate etc. But again its your own problem, not mine.
Not every programmer is a rock star ninja. Most are mediocre. Some are pretty bad but know the theory and can play the resume game, pass the whiteboard test, etc. There are plenty of books and lots of advice that will teach you how to fake your way through a resume, cover letter, and interviews.
Worked at Google/Facebook/Twitter? Great. Odds are I can't afford to hire you. You're not the target of open-source filtering :)
Also, contributing to open source projects doesn't necessarily need to happen in your "spare time". Companies contribute to open source too.
That said, I don't see anything wrong with wanting people that have some open source contributions. It doesn't have to be anything along the lines of having written the linux kernel in your spare time. However, it should be something that you put serious time and thought into.
Wouldn't have to be open source work, just work you could show.
It's tough to hear, but the goal of a new employer is not to give us what we deserve for working hard and being skilled.
The employer's goal is to maximize their chances of hiring someone good.
If a hiring manager has two people that seem about the same but they can see the code one of those people wrote, it's a no-brainer to go with the one who has a portfolio.
Agree with you that some lame open source patch doesn't matter. But if someone's done significant work in public, or even has non-open-source code they're able to share, ignoring that would be an insane choice for the hiring manager to make.
Yet, mysteriously, civil engineers, material scientists and statisticians somehow keep being hired and the work keeps getting done. Baffling, I know.
I bet you'd hire a programmer without a degree who can do the work before you'd hire a civil engineer who learned how to build stuff off the Internet. :)
but since people can show it in the programming world, you are at a disadvantage if you don't.
if a civil engineer had some way to show what they could do, I'm sure it'd give them an advantage.
Do you work on an island?
So what you are saying, is that, given that, unless I went home and coded and contributed to an open source project during my free time, I am a shitty engineer, not worth your time. Get real. Incidentally I work elsewhere now. They asked me to solve a programming task before an on site interview, and then...shock, I had an onsite interview process.
Do you think that when a heart surgeon from NYC applies to work in Seattle or LA, they say, "That's great that you didn't kill anyone at First General on 57th street, but, do you have any published video of you doing surgery pro bono we can watch so that we know you're not full of it?"
I think their diploma and med license are sufficient. I also think a lot in hiring decision for particular surgeon can depend on their peers opinion.
Ditto other cultural fit issues like "Your personal life should come second to our business desires", "Marriage and children are unreasonable burdens to saddle us with", "You should be loyal to us; we may reciprocate, but if not, it is just business", etc, etc.
We're not talking about companies demanding that you do open-source work for them before getting hired. It's about the idea that having some code publicly available somewhere is a good way to improve your chance of being hired.
It's great that there are companies which look down on you not using your spare time to do extra programming -- you probably wouldn't want to work at places like that anyway.
Github track records aren't just about the fact of seeing your code; it's about the fact that you're proving you can work with the OSS community projects. That's a skill set in and of itself, as demonstrated by the recent extremely public bickering between gnome and canonical, for example. If you have a demonstrated track record of navigating OSS project drama like that and still getting your patches pulled into trunk, a company that wants to build a relationship with an OSS project is vastly more likely to hire you.
Re-reading your comment on preview, it sounds like you're looking at this like "Okay, I've coded all day on closed-source, now I need to go do up some erlang on some personal bullshit project and commit it to github, with unit tests and a meaningful commit, just so I have a track record to point to in a year or more when I'm looking for a job."
And I'm not saying that wouldn't work, but more that that's not the point at all, and any company hiring based on that is exactly as clueless (albeit a bit more up to date) as the company hiring based on a minimum of CCIE + RHCSA when looking for developers.
Of course I have my own personal projects, but for most of them, I am not about release their source.
Candidate 1: "I brought this fanfold printout of the source code for _____ I wrote with me, have a look.
Candidate 2: "I can't show you any of the code, but trust me, it's good."
Github merely drags that conversation forward from 1981 up to 2011. When you and I choose to write code that is locked away in somebody else's vault, we ought to charge extra to compensate for the fact that we might as well have been surfing Oahu.
Perhaps, but it's a lot less than the cost of not having a probationary period and winding up stuck with a poor member of staff indefinitely because you couldn't do the impossible and spot every problem candidate during a momentary interview.
The argument that this isn't fair to many programmers has also been going on at least for the last 30 years. Fair or not, it helps a lot in convincing an employer you're worth hiring.
I like that idea. Part of the value from working on open source projects for companies is the public nature of your contributions: It's easy for you to take your commits to Chromium and show it to Facebook or Apple when looking for a job there.
Companies may not like that idea, however.
His criteria don't (and shouldn't) apply to every SW hire, even though it's clear his message is "demonstrate > declare".
So what are you complaining about exactly? If you don't want to be judged by your own work, then there's no problem: that's your decision. If you do, but you refuse to let anyone see it, then you're creating your own problem, so you have no basis for complaint.
There is nothing "unfair" about this. Rather, you're given a choice about whether or not you want to participate and you have decided that you don't.
I do exhibit some of my smaller projects on github; my larger projects are not online because of competitive reasons.
that aside, a companies hiring process isnt designed to be fair, its designed to efficiently recruit the best talent.
Any particular reason?
"Any code, materials, designs, patents, design patterns or other such intellectual property ("IP") created by candidate is automatically and immediately assigned, irrevocably, to Employer upon its creation without further consideration."
The legality of this withstanding, I'm just letting you know, from experience, I've seen this approach in LOTS of contracts. I've learned the hard way that just because something is illegal or unenforceable doesn't mean that a company won't TRY to get away with it anyway. Often times, they do, because "the little guy" doesn't have over $100k to pay for an attorney.
Anyway, I'll shift my stance to lusis'. My eyes would pop out if I ever saw that in a contract offered to me.
This has made me extremely happy, and means that in the future I can point towards those patches that were posted as proof of work I have done.
Further, the disadvantage you refer to is natural.
That would be private code that's in Facebook. (I didn't work on Hive, Thrift or anything open source)
If the ability to demonstrate that they can write good code with concrete examples puts someone at an advantage over others, so be it.
Last time I heard git sucks on windows, svn is still extremly widely used (try writing a game with a large amount of binary assets and use git) and some of the old open source systems still use CVS.
As the ad in the in-flight magazine says (I think I remember right), you don't get what you deserve, you get what you negotiate.
The impact on your visibility, personal brand, and ability to find future roles should be a factor when you sign up for a job. Just as you'd consider your job title, for example.
If you're signing up for something you can't talk about or show off -- worse, if you're signing a contract that says you can't do anything that you _can_ talk about on the side -- then you'd better be sure you're getting paid extra, or in some other way getting compensated.
From what I've seen, working on super-secret trading software for Wall Street _does_ pay a lot more than working on an open source project, on average.
If the price is that you have to use references and other means to show future employers what you can do, then that's the tradeoff.
If you're not getting paid much, have no spare time, aren't allowed to code in your spare time, etc. then those are some items for the "cons" column that might nudge you to look for something new, all else equal...
The Github projects are a very small part of the open source universe. You can easily build *BSD or LinuxFromScratch with a substantial userland without ever downloading anything from Github.
Yes, other websites show source inline, but I've found that they are not intuitive at all, and the code (to me) feels hidden.
To your second point, you're right. I'd love to be able to convince older OS projects to move to GitHub. Some do[2], but it's an uphill battle.
Careers 2.0 probably isn't popular enough to change the world that significantly but it does make me want to hunt down someone for a profile invite (though I guess I should save those for people who are actively looking for jobs)
P.S. Careers 2.0 is hosted by Stackoverflow which means hosted on a .Net platform...just sayin'
Why would I release my software on github for free, when I can release it on Google market for money?
Facebook has a nice social graph but no angle on programmer socialization. Github's API can let you infer which open source languages I dabble in, but not at all what I do at my day job. Good luck to you though, I'd love to see the product.
The market is hot right now and it would be pretty nice to be able to show some of the programs that has been written.
Go elisp! You can do it!
Oh, and forks don't take up much disk space since they share structure with the original repository. If the changes have been merged to the mainline, then the marginal cost of your fork is close to nil; probably just a few rows in the database.
Using GitHub or other OSS contributions/commits as your actual resume, or the litmus test for, "can I have the job, boss?" has been something I think we've all seen coming down the pipe for a few years now - I know I saw it way back when. Personally, I live in the midwest, not the SF bay area, so "trends" like this are a bit slower to catch on out here, but the last several job interviews I've been at, somebody has always asked me: "Do you have a GitHub account?"
This situation has people on both sides of the argument - for and against. And I'm going on record right now as saying, absolutely, 100%, without question, BOTH sides are right.
The truth is, from an employer's perspective, this just makes sense: prove that you can do the job. A resume doesn't do that - it proves that you can hand a piece of paper, sometimes even written by some one else, and BS your way through an interview.
On the other hand, employers frequently trot out teams of developers - some as many as 15 (that I've seen personally) to pepper a candidate with lots of hard questions during an interview. Inevitably, there's always that one nerd in there with serious penis envy who tries to re-assert his "dominance" by trying to "outsmart" the job candidate to make him or her look bad by throwing some super hard core question that makes said nerd look like a badass at the poor guy doing his best, and then trying to make the interviewee look like an ass when s/he can't answer it. The truth is, these guys have time - days - to prepare these interview style "litmus tests" for candidates, but when interviewing for the job, you go in blind not knowing what to expect and have to come up with everything from memory. /rant
This makes for a craptastic experience for the candidate, and a very time consuming and costly experience for the employer. Looking at a collection of code related to the job in question is a much faster way for them to get a handle on where the candidate is at, without the need for such involved processes in many cases, saving time and money for them and the candidate, and saving the candidate some serious anxiety.
However, there's another side to this coin. From the perspective of those of us who would rather NOT go home and spend all night 4+ days per week writing MORE code, this puts us in a bad spot.
The way I see it, you have two kinds of developers (basically): those who are SUPER into what they're doing - which is great (really! no sarcasm intended) - and those who enjoy what they do, but recognize that it's work. Good, old-fashioned, hard work. W-O-R-K. Blowing up some asshole in Halo Reach or having sex with your girlfriends (yes, plural) is a hell of a lot more fun than researching "most efficient sorting algorithm". So when we're not at W-O-R-K, earning a living, we need SOME way to kick back and release, or we'll absolutely explode. That's called "common sense".
This presents a problem: those who, for whatever reason, be it inability to get a date, or absolute true "nerdvana" enjoyment of writing code, end up doing ADDITIONAL development work, strictly for work's sake, now have a somewhat (emphasis on somewhat) unfair advantage over those of us who can do the same job, and are willing to work just as hard (for pay - after all, I can't pay rent with hugs and good will), but have other obligations (kids, for example, is a big one) and just plain can't put in another 20+ hours per week required to COMPETE - yes, I said the C word - with others who can.
Some arguments I've seen or heard that I'll comment on:
"But it's not THAT hard!" Nothing easy is really truly WORTH doing. I can write some seriously easy code in under 5 minutes that'll look bad ass from a quantity point of view - until you actually examine it close up and see that it's just bullshit. The stuff that REALLY makes you shine is finding new, interesting, and USEFUL ways to solve hard problems. Nothing else is really as worthwhile. And there's a point that you get to, after doing it for 50+ hours per week, that you just say, "enough!" and have to decompress. Other people see it differently - they still enjoy it and do it in their free time. I truly wish those people well and want to encourage them to keep doing it!
"Well, if you aren't the kind who'll do the OSS commits, you aren't a culture fit anyway." This is 100% Grade-A bullshit. Just because a person doesn't want to spend their free time - that they'll never get paid for - creating additional software, outside the scope of their workplace, essentially doing MORE work simply for work's sake, does NOT mean s/he is a bad culture fit. _It means they have self respect._ If you're going for the super hard core, hipster silicon valley, "my shit doesn't stink" start-up environment, that may be true. But in a nice place I like to call "the real world", those companies cutting the checks GET IT - at the end of the day, you gotta get paid for your work. Even though they understand this, they'll sure as shit take advantage of other people who have no problem with playing the role of "happy little nerd behind the desk that we don't let talk to anyone and just codes all the time". They're perfectly happy to use this kind of job competition to squeeze more out of some one beyond what they're paying them for, and don't give a damn when that poor person eventually has a breakdown because they've been working 80+ hours per week for several months, maybe even years.
My bottom line on this is pretty simple: like it or not, this trend isn't going anywhere because it has advantages for parties who are interested. Unfortunately, I really think that it's going to create an even more hyper-competitive environment for people looking for jobs. We'll get to a point where we'll have maybe 20-35% of applicants who are truly really HARD CORE into what they're doing and truly, with every fiber of their being, enjoy writing code on their own time, but then we'll find a larger segment of people who do it somewhat begrudgingly, seeing it for what it is - work for work's sake. This is going to breed a very strong sense of competition in the engineering and development job market that allows companies to treat developers - especially younger ones, recent college grads, etc. - as what they'll be painting themselves as: subservient nerds who work for peanuts just for the CHANCE to have a job, even being paid in stock options that are totally worthless at Startup #1119128418911818119.2.
There's no way in hell I'm going to work 40+ hours per week doing something that, sure, I enjoy, but get bitched at by some asshole in his Armani suit that "it isn't gettin' done fast enough!", then go home and write more code just for the CHANCE to do it all over again. Fuck that.
And those who will do that? Many will end up submitting crappy OSS contributions that do nothing to move the industry forward, because they're only doing it for the sake of being able to compete in a job market - NOT because they truly love what they're doing. And that's really the major thing that irks me about this trend.
But again, it's happening and there's nothing that can be done to change it. That's why personally, I'm looking at changing job functions. Systems administration, or project management maybe. I'd much rather be the asshole in the Armani suit DOING the chew out, making bonuses of over $500k/year that keep going up, with a relatively easy job (especially compared to modern development), than the poor guy he's chewing out, despite that person doing a seriously awesome job under very difficult circumstances, for very low/poor pay that keeps decreasing due to increasing job market competition, who works twice as much and twice as hard, and STILL has to put up with assholes like "Mr. Suit".
Fuck that shit.
Thats your problem right there - it is a sellers market right now, so if they start making too many demands for stupid things you can get a job elsewhere.
You are a great programmer, good companies know they need to qualify themself to you.
Do you think suit guy got his job with that attitude?
Everybody wants to hire the brightest developers, but there aren't enough to go around. It's a mathematical impossibility.