Hacker News Reader

Comment by onan_barbarian | Hacker News Reader

Maybe this is paranoia, but I'm beginning to find a lot of threads like this (and a few yesterday about 'how to hire people') actively coercive: "Contribute to Open Source or Don't Get Hired".

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.

View on HN

This is one of those posts that is made, and upvoted, based on what everyone wants to be true, instead of what is true.

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'm not trying to convince you of anything.

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.

Just being honest here, but both of your posts come off, to me, much more as you rationalizing a belief about what is true based on what you want to be true, and trying to "convince" us that most of this thing that "we" possibly value isn't all that valuable. Minimizing people's work on github as just some trivial side project, that should be ignored, because you don't want to do it, just isn't a reflection of the reality the situation. I freely admit this might be offbase, but it would appear you are arguing against -really- sound advice simply because you don't want the reality that that advice implies we live in. Except we do.

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.

I concur that there definitely are strawmans and other poor argument tactics afloat. Onan_barbarian says that while some github contributions are really admirable, but some are of zero value, to which you reply by first reconstructing this argument to be "people's work on github is just some trivial side project, that should be ignored.", followed up by accusing him of rationalizing his hopes and making strawmen.

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.

This has been going on forever with Academia, where the right to freely publish profoundly impacts where one chooses to work.

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.

The problem is that I can't believe a word you said. I can't see examples of this awesome super top-secret code because it's all closed-source, as you say, for good reasons.

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?

> The problem is that I can't believe a word you said.

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.

This is absolutely the right way of thinking about the problem. If you can afford to be picky, this filtering saves you time and doubt.

Unless the person is a major contributor to widely used project, all the OSS contributions show you is two things:

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

In my personal experience, all people who can code well, can do that under stress too. This must be one of those theoretically valid arguments that is rarely encountered in practice.

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.

In hiring a false negative means your competition gets a better programmer which means they will be able to eat your lunch.

How isn't that a disaster?

Maybe.

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.

Thanks for the sarcasm: "awesome super top-secret code".

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?

"Thanks for the sarcasm" - no, thank /you/.

It honestly wasn't meant as sarcasm and I apologize for the hyperbole. But do you know how often I hear people say "I'm really good, but I can't show you anything. But you can talk to my references and they'll tell you I'm good." That may work with HR people and managers who don't code, but not from programmers.

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

'The problem is that I can't believe a word you said'

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.

But how many Facebook/Google/whatever engineers can a new startup afford to hire?

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

For a shop whose pre-requisite to hiring a developer is that they have code publicly available, you can bet cultural fit is the other thing at the top of their checklist.

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.

You'd go with a graphic designer with a portfolio you could look at every time, right? Say the graphic designer's previous employer didn't let them put stuff in the portfolio -- I don't know, maybe they only worked on NSA internal marketing -- that's the designer's problem. They aren't going to say "no fair," they're going to find a way to do some work to put in a portfolio.

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.

This assumes that all programming in analogous to 'graphic design'. This analogy breaks the moment you consider that perhaps at least some programming is more analogous to, say, civil engineering or in-house material science research or in-house statistics... none of these other professionals are going to be able to disclose their 'portfolio' in any meaningful way.

Yet, mysteriously, civil engineers, material scientists and statisticians somehow keep being hired and the work keeps getting done. Baffling, I know.

The difference is that if you graduate as a civil engineer the probability that you can do what the job requires is quite high. This isn't the case for most graduates in the field we work in. This is a tragedy - I share your sentiment, but I can understand why companies are unwilling to use the same process that works for engineers as long as the education doesn't produce equivalent results.

Not to mention that research scientists and engineers often have advanced degrees which required a lot of application.

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

if nobody could show their portfolio, then nobody would get an advantage from doing so.

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.

Understand though that, while your points are valid, it it's certainly more valuable to an employer to be able to see your skills in action than not.

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.

Some companies have a culture built around open source software (e.x. Github), and some don't. The latter will value open source contributions less (or none). If you have no desire to be involved in open source then perhaps you'd fit better in those companies.

Also, contributing to open source projects doesn't necessarily need to happen in your "spare time". Companies contribute to open source too.

The thing to me - as someone who is more devops than dev, works at a currently 100% closed company, and does not have a public track record on github - is that this article and argument are both kind of silly.

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.

For-profit companies are certainly allowed to attempt to convince me that working for free for them is both morally required and in my own best interests. I promise to listen attentively.

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.

I don't see what this has to do with the issue being discussed - that having made open-source contributions is an important factor in getting hired.

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.

Even if you manage to maintain a side project, there are plenty of valid reasons (legal and not) to not release the code in public view.

If "endless side projects" is unreasonable, is "at least one" reasonable?

No, it is not. For a side project to be remotely comparable to the efforts that, for example, we have put in, it would have to be quite a side project.

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.

Yet you offer no reasonable alternative.

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.

I think there's a question of degree involved. A lot of employers seem to want you to have a github account that proves that you're glued to your computer 16 hours a day (fortunately, they have no way of finding out if you dream about code 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.

From personal experience with interviewing and screening ~100 candidates over the last two years, I can say that high-quality open source contributions are a big plus for an applicant. I can also say that we've never even considered rejecting someone due to a lack of contributions.

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.

If I might reframe the issue slightly, I don’t think the problem is that coders are expected to make FOSS contributions. The problem is that coders are expected to do significant amounts of unpaid work. We all laud Google Summer of Code because it lets young people get some traction without starving. Other companies that want the benefit of hiring people with FOSS experience need to put their money where their mouth is and fund FOSS contributions. There is an awful trend of corporations wanting experienced workers but doing nothing in terms of internships, apprenticeships and mentoring.

Not only that, but "passionate" people aren't always a good fit. I prefer to work with someone who may only regard software engineering as a job, but who has common sense etc.. instead of some hacker kid who is going to try to make things as complicated as possible just for kicks.

It is becoming increasingly rare to work on an island away from open source. A lot of companies use open source in some way and having an in-house developer familiar with the projects they use or relay on can be quite useful. And the improvements that the company is willing to pay for but aren't a competitive advantage can be committed to the open source project. It's a win for everyone.

Do you work on an island?

You people are insane. Going out on a limb here, as I hate making my life public - I worked at Factset Research Systems for just about four years. They are a publicly traded company (FDS - NYSE). Guess what - They would allow precisely 0% of the code I wrote for them while working there to be shown to another company.

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?"

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

Then check that the guy has a relevant degree.

While medical cert (rather painful and time consuming to obtain) give a good guarantee that a doctor wouldn't butcher people outright, there is never such a protection with CS diplomas.

I said nothing of the sort. Please try to pick a comment that is actually relevant to your diatribe next time.

Reply on news.ycombinator.com