Speaking from this experience, and as someone who reviews on average 20-50 coder profiles a week, the public commit history of a coder is almost never a significant factor. I don't see any trends that indicate this is changing, either.

The vast majority just don't have much to show, having spent their years working behind walls on closed software.

Instead of relying on a public portfolio that in most cases won't exist, I rely on talking to these people directly, programmer to programmer. If we can code together, on the actual code they would be working on, that's about as good as it gets.

In other words, I rely on my experience as a coder to help make what are, ultimately, subjective judgement calls.

Sure, that's not many people and I'm still new to the industry, but I can tell you that of all of these people only one or two have significant public GitHub activity. All the rest have empty GitHub accounts (aside from work).

These are all well employed programmers at startups. They're doing fine. The importance of "side projects" is overrated on the internet.

What we found was the way you figure out whether or not someone with a strong GitHub history is going to be a good hire looks more-or-less exactly like the way you figure out whether or not someone with zero GitHub history is going to be a good hire. All focusing on GitHub really seems to get you is the ability to cast an artificially narrow net.

And I work at a major tech BigCo(tm), with a lot of smart software engineers, the majority of which are under similar restrictions.

Frankly, any potential employer who expected to see said contributions from me and use it to judge me or my coworkers as candidates would be making a poor decision.

I understand the company wanting to protect itself, but I have to protect myself too.

I have always asked for it politely in advance as part of the negotiation process, before there's a contract. I didn't try to strike stuff out. I specifically made it clear throughout the process that there are some things that are important to me that I wish to continue doing. It's usually never no when I ask because the outside work I've done is often the reason we're talking in the first place. When I frame it that way, they're usually able to find some exemption.

The conversation usually starts with my soon-to-be manager about me wanting to work on projects on my own time without using company resources, that don't directly compete with the company's business.

I've been fortunate enough that I've never been in a position where I've only had one offer I've had to take, though. If they said no, I was always able to go to another offer and say yes.

Some companies literally do not budge though. But I have to look out for me and my family. I do side projects mostly to learn stuff and help people. I also love writing about technology. And, for example, my current job doesn't really have a place for me to do Elm and Elixir, but I think those things are important skills for my future.

If I take a job that doesn't let me do those things, and they decide to let me go because reasons, now I'm on the market with out-of-date skills and that scares me. It also scares me to work for a company that's against me investing in my skills on my own.

I think that if I was in a situation where they wouldn't budge on that, I'd have to walk away and take my chances as a freelancer at that point. I mean, I'd rather have my risk spread out among a few clients than on a single employer who wasn't willing to negotiate.

The first key I found is to make it easier for them to say yes than to say no. I simply refused to sign my separation agreement unless we could change the line. Like everyone else, I got the "it's standard policy" bullshit, I just nodded, said nothing, and went back to my desk.

It's an intimidation tactic, those contracts are done up by lawyers and modifying them potentially exposes them to liability, they'd have to get a lawyer to look at amended agreements and that costs $. Intimidation tactics are generally used when they don't have any real leverage to use. Just don't give in, and keep asking for the change. Works best if you're actually prepared to walk, you don't want them to call your bluff.

After it became clear to them that I wasn't going to do it, they agreed to the change, but only after a stern discussion that I was not to discuss it with anyone. If we didn't already enjoy a friendly, trusting relationship I doubt I could have gotten away with it.

If you're not willing to walk away, then of course your leverage is limited. Their BATNA was basically to fire me without cause, they had more to lose than I did.

In your case I'd appeal to their sense of decency. Assure them that you won't tell anyone about it, that's a big reason for the "standard policy" bullshit. And then say that if you'd realized how onerous the contract provisions are, you would have never even applied for the position. That lets them know you're serious. Tell them you're prepared to walk out over it but you'd really like to make a deal so you can get to work. Presumably the employer actually wants you and you have champions at the company.

Doing all that without a contract in place would have been tough on them to say the least. They had another Rails consultant lined up to replace me, but I was a lot cheaper.

Everyone is going to have at least one point in their life where they need to take job X because Y. But you can do things to make that the exception rather than the rule, even if you don't feel you're a wunderkind.

Continual job searching, self marketing, networking, skill refresh towards emerging areas. These all give you better odds to be on the right side of that discussion than the wrong one.

1. Your current job and or job situation (company not doing well, layoffs on the horizon etc) is hopefully not one which you are desperate to leave at any cost. 2. Apply to multiple companies and interview with them around the same time; this usually works out. 3. (HARD PART) Land multiple offers in hand. 4. With 3 and 1 combined, look at the offer letters and negotiate the bad clauses, after reviewing with a lawyer-friend, so that the wording is also right. If they say GTFO, you also get to say GTFO :-).

I know from experience and also that of a few of my friends, it works.

Also, these employment agreements use the words "inventions, innovations, or ideas". Can any lawyer-types chime in if that implies patentable items, or does inventions legally cover copyrightable creations?

I sent an email to HR asking whether my employer claims ownership of code I write outside of work. The process required several emails, a legal review of the agreement, and a meeting between our CTO and in-house counsel. The approval required a a signed statement that I wouldn't use company time or equipment for my contributions. The whole process took about 3 months.

If you live in one of those states and an employer demands assignment of all IP, even if created with your own resources, on your own time, using your own ideas, they are probably outside the law and you can point to these statutes as evidence. Of course funding litigation is another thing entirely, but if an employer has a very broad assignment expectation and is in one of these states, you should look for work elsewhere.

That being said, it does not mean that you are free to earn money outside your employer, but they don't own your brain.

Make sure you can prove that your work never comes from work machines, etc. This includes not using company internet connections as well.

The bigger your employer, the less of a protection California's default is.

Most things that most developers work on are private. More importantly even when the code isn't private, the context and reasoning behind it is often far more important than the code. Resumes tell a story, code is just data.

Whenever I've hired people, GitHub has never been a significant factor. It is, at best, a minor boost (if someone has a bad resume but a prolific GitHub, I'll give them an interview). It's definitely not enough to ever get hired.

Even as someone who has been relatively active on GitHub in the past, it was never an important part of my job searches. My resume is a lot more important.

I also use someone's GitHub profile as a way to give me a reason to interview them, and some things to talk about in the interview. I also use their resume, and if we give them a small project, the results of that.

I got loads of recruiters to email me, wanting to have a chat.

My plan was to get free plane tickets and hotel to visit U.S, but I didn't find enough time to bullshit them before they actually invite me, but it seemed it's possible.

I'm below average programmer and from Europe. Probably I wouldn't have either attends the actual interview, lied something happened or go there and let them realize I'm shite. No, I wouldn't feel bad about it all if I'd have pulled it off.

If you are a solid contributor to well-known projects, it can be very helpful in networking and it's useful in separating you from the pack in the early "resume review" stages.

I don't really know if the expected value of building a reputation in an open source software community is higher than the opportunity cost of other things you could do to help your career, of course. I'm just not sure if "I really don't make hiring decisions based on the code on a github account" is the right metric in this case.

This is a very important point mostly missed. My first job out of school was due to networking related to a free software project I was helping out on. Networking is the best thing you can do to help your career and working on free software projects can be a big help.

Though this is a bit off topic from the original post about having a github portfolio. I do think a portfolio can be helpful and is worth spending some time on, but I don't think it is necessary.

How do I find a recruiter like you?

Right now, I work with two different recruiters, at two different agencies local to me. Both have placed me in great positions; my current position is one (and I am not looking for a position currently).

But say, in the future, I want to find a recruiter who knows software development, from the low-level nuts-n-bolts (coding), to design, deployment, business, etc - what would be the best way I could find that person?

I think having a contact like that might be valuable, since not only could they recommend the fit, if they serve as an initial "gatekeeper" to an interview, but they might also offer tips and other advice helpful for positions. I'm not looking to replace my current recruiters; both are great guys and work well with me. But augmenting them might be worthwhile.

Finding someone local to you, well, you'll have to ask around.

But how do you know if the recruiter is qualified to assess coding skills?

>> Pretend you're a team leader interviewing a junior coder.

So how do you handle the minority who have much to show on Github? Do you use the same or different process for this minority? If the same process, then IMHO, it is a one size fits all which does not seem right. Sincerely wish to know your experience/thoughts in the minority context, a Minority Report if we can call that :-)

If someone worked at Snapchat, you have some context about what industry they were in. If they worked somewhere unknown, it takes a couple more questions and you're at the same place

If you have hundreds of candidates to sift through then you don't have enough time to look through their github history in enough detail to be worthwhile.

Thank you! :)

I've done a fair bit of recruiting for clients willing to build technical teams (developers / data engineers / data scientists): my experience is similar to yours in that the large majority of the technical candidates I've been interviewing have no visible trace on GitHub (either because they worked on closed source, or because they are out of school without not a lot of personal drive to work on OSS).

But at the same time, as a freelance consultant for the last 10 years, having work online available for everyone to see or use (OSS or other) has driven a lot of valuable leads to me (e.g. on my niche doing Ruby ETL http://www.kiba-etl.org/).

Last note is I agree with the premise of the article that we are shifting away from "week-end contributors". For me OSS is something I work during the day, even as a single-man shop, and something that is (if properly managed) bringing in a sizeable part of my income.

Or because they work extensively on OSS projects that don't use GitHub.

To give examples:

- Git https://github.com/git/git,

- Linux https://github.com/torvalds/linux,

- LibreOffice https://github.com/LibreOffice/core,

- Firefox https://github.com/mozilla/gecko-dev

On the other hand at the last job where I was on the selection/interviewing side of things (somewhat peripherally) I did look at GitHub projects.

Can also confirm that most Github accounts are made of a dozen forks of existing projects with a trivial commit or two slapped on top. Also doesn't tell me much about your proficiency.

The next stage is all about 1on1 conversations and pairing sessions.

In some concrete fields like web/SNS, I believe completely surrendering your persona online is already a requirement. Let's hope this doesn't spread.

When looking at candidates I almost always find some correlation between a meaningful public commit history and quality.

Sure, it'd be nice if everything I worked on was available open source, but let's just look at one example where that's not a good idea: video games.

Good luck getting the game industry to make their AAA games open source, especially before release, when hundreds of people are chomping at the bit to have a dirt easy time of cloning whatever game out there and tossing it on the app stores to make a few bucks off their broken, half-stolen mess of a game. It's a rampant problem right now (for example, 2048 and Flappy Bird both had open source versions, possibly unofficial... look how many clones of those games hit the app stores).

Not to mention, game development often is a creative one where features are tried and then have to be cut for time, while audiences assume that anything they see will be in the final game, and if not they were maliciously lied to. This leads to any information about the game being closely guarded except for planned waaay in advance marketing campaigns, for most games (indies is a little different, indies need whatever exposure they can get usually).

So no, not everyone is going to be working on open source software, and that's not going to change in the 2 year 'Mark my words!' timeline this guy has provided.

As a long-time developer from the embedded world, I'll add the same sentiment. I've written 25 years of code that's 100% proprietary to my employers and my customers.

I've never touched Github and, at this point in my career, it looks like I never will.

Granted, I have a product portfolio that I can point to instead. The rubber has to meet the road sometime so yeah, in the open-source world that's the only visibility you have so you go with it.

This seems like the real takeaway. An experienced programmer should have some evidence that they do good work, whether that's products or OSS commits or something else altogether (e.g. someone in security who can't talk about their work details but does papers and conferences). Good hiring means being able to adapt to where a candidate has spent their effort.

...if it exists at all anymore!

In many cases, the examples of my work have evaporated. At one point, I could point to certain websites I had a hand in developing as an employee for past employers - but those sites have since changed, moved on to other software development companies (one of my past employers folded and those clients went to other agencies for web dev work). I can still list I worked on such work, but I have no code or other proof.

So my github (and interview results/conversations/etc) are where its at - and ultimately, that's where its always been (I've been doing software development work since the early 90s, when I was coding on VT100 terminals over a serial link).

Ironically game development is one if the areas where tech & algo is discussed widely and openly(which is what GDC used to be before it became a bit more commercialized). Most studios are happy to share their latest pathfinding/ai/rendering techniques which is almost always held close to the chest in other industries.

Their techniques doesn't save corporations that could purchase their software time and money, for example, it just helps make one aspect of the game look or feel cool.

Never worked in the industry (and don't have a desire - though one time I did), but I'd have to say that's spot on. You can have all the fancy shader tech and other 3d gismo engine whatever at hand, but without the story/plot and creative content, anything you made using it wouldn't amount to much.

...and that content is very difficult to make! Even a simple 2D game can have a load of content and design behind it that can't be easily replicated for a new title by a single person. Though this kinda argues against why more companies don't release their engines and tech as open source - especially once the tech has "aged out" (fortunately, a few companies have - like Id Software, among a couple others).

Even with these releases, though, you don't see a slew of others coming out with games and such based on the code.

A lot of it is also driven by the popularity of consoles and mobile devices which are still largely locked-down walled gardens. They intentionally make it difficult to share code between platforms too. But, soon enough game developers will get sick of writing the same code over and over again, just as OS developers did in the 90s. Once this happens you'll start to see a lot more ad-hoc code sharing which will pave the way for more engines being made free software.

For instance UE3 makes a horrible engine for open-world games since it's built on loading levels whole-sale and doing very little streaming aside from textures. If you need a game that requires 60FPS(racing, fighting/etc) something that is GC based won't cut it.

I've worked in in-house and external engines(UE3, Unity) and you always have to re-write large portions to make them work for your gameplay. There are fundamental tradeoffs that make it hard to do otherwise. At every project there comes a point where you no longer take unlevels from mainline, fork the code and make deliberate breaking changes to ship the game vision that was set out by the team.

Rinse. Repeat...

The great thing about viral licenses like the GPL is that they effectively openly track the provenance of the original idea/implementation. If someone comes up with a really neat game (in terms of its concept and, ultimately, source code) and that gets built upon openly, the original copyright holder will still be credited. Plus, if the source freely exists, I think most would be more inclined to fork than to reimplement a clone from scratch (modulo platform support, I suppose).

Between mods and Ludum Dare there is plenty of room to make a name for oneself in the open.

I know you're using them just as an example in your comment and this might lure people away from your points, but the "original" 2048 (the one we all fell in love with) really is open source. In fact, it got to the front of HN with almost 3k votes, and the author left multiple comments in that thread.

So yeah, my point is, the "original" 2048 is not only open source, but HN definitely had some sort of an impact on it becoming a thing.

https://news.ycombinator.com/item?id=7373566

Your examples of AAA games with open-source versions are Flappy Bird and 2048? We have different ideas of what makes a AAA game...

2048 and Flappy Bird were to demonstrate the cloning problem that App stores have been dealing with, in part because of how simple those games were to recreate, but also in part because it was made even simpler because the code was easily available.

For an example of something closer to the problem that AAA would face if they made their code open, look to the shitshow that Steam Greenlight faced that Valve had to put a stop to. People were downloading some Unity assets and slapping together total broken crap as fast as they could and selling them as full games. That's the type of thing you could expect if AAA was more open with its code.

"The future is already here, it's just not evenly distributed yet." - William Gibson

I don't deny that open source is now more prevalent than it was in the past, I just don't think it's on the verge of taking over the world, where every sector will be open source, especially in the ridiculously short timeline of 12-24 months you stated in the article. There's too much value for certain industries, sectors, or companies to keep some, or even most things close to the chest, and there are plenty of companies that haven't been convinced that opening up their codebase would be worth the extra time and effort it would take to do so.

You didn't even address my example of the game industry, so I have no choice but to assume you either agree with me for that industry or just don't have any way to disprove it.

Yes, Microsoft, once known as the chief closed-source proponent, is now embracing open source more, but that's a single company with completely different management than it had ten years ago and in an environment where they're no longer the king of the development world. And in particular for developers, being more open is usually a good thing because it gives us more freedom when developing. But that's only one sector of the programming world.

I have worked for at least a dozen companies over the years, and while I've incorporated at least little pieces of open source software or libraries in most of those jobs, the resulting codebases for those companies was never opened up, nor was there ever any talk about possibly opening it up. We were generally always too busy working on the next iteration to worry about opening our software up or dealing with that. Additionally, at least once I recall us rewriting our application to remove an open source portal software (uPortal) it relied heavily upon because uPortal was just a convoluted, restrictive mess to try to do any real customization with it.

And quoting William Gibson, is cute, yet proves nothing. He's a talented writer who tells good, believable stories about future technology, but he's hardly a prophet.

> One of the principles of open source is meritocracy — the best idea wins, the most commits wins, the most passing tests wins, the best implementation wins, etc.

Have we learned nothing?

"When a measure becomes a target, it ceases to be a good measure." - Goodhart's law

"Best idea" and "best implementation" are fine, but that's because they're subjective. Goodhart's Law is a great thing to reference here - the only thing you can't game is "actually producing good outcomes".

"The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor." - Campbell's law (1976)

"It is naive to try to predict the effects of a change in economic policy entirely on the basis of relationships observed in historical data, especially highly aggregated historical data." - Lucas critique (1976)

[1] https://en.wikipedia.org/wiki/Perverse_incentive

LOL. Thank you.

A modern incarnation: High incentives for the destruction of a harmful chemical stimulates it's production.

1. GitHub represents the major part of software development world.

No. It's a tip of an iceberg. I don't think I have to elaborate this one.

2. Open source software development model is an absolute winner.

No. It's just one model of development which fits some kinds of projects better than the others. Companies tend to open-source tools. Product's code is usually closed source. Obviously there are a lot of developers who spend most of their time on closed source projects. Some of them also have life.

3. Your open source projects contribution helps recruiters to evaluate you performance for any kind of software development project.

Not true. A lot of jobs are either legacy projects work, niche technologies work or both. Some niche technologies are closed source. Some legacy technologies predate open-source culture. The problems you face doing open source projects are very different from those you face doing b2b, b2c projects.

Having said that the author's opinion looks invalid to me.

I enjoy my job, but simply want to do other things in my off time.

Being rejected as a candidate because of a lacking Github profile is not unheard of.

File that one along with requiring CVs in Word format, requiring applications via their own custom online form, proposing "we own everything you ever do" IP clauses in employment contracts, proposing multi-year non-compete agreements, and interviews full of brain teasers and/or questions about obscure technical details you probably won't ever need to know and could readily look up if you did.

They're under "handy signs that I probably shouldn't accept an offer from this business".

I'm honestly much more comfortable in enterprisey environments than in companies that try to be hip and cool, so if a company cares about my GitHub, they're probably not a company I'd want to work for.

I always send a link to my github repos when I apply for a project, this removes most of the dumb "can you really code"-style questions.

The Software industry needs more humility and less magicians.

I believe that strong engineering skills are worth far more than a Github profile, and good recruiters will know how to spot this.

If however you are looking to be hired as the new "Rockstar developer" of the latest trending startup running buzzword architecture, then a good public brand might be useful indeed.

[0] http://www.finlex.fi/en/laki/kaannokset/2004/20040759

    > Over the next 12–24 months
    > — in other words, between
    > 2018 and 2019 — how software
    > developers are hired is 
    > going to change radically.

I don't want to look back on my life with that feeling. As adults, we have very little free time and spending it on software seems like a gross misallocation of resources, even if our careers would benefit. There's more to life than work.

If I was out of work I would be leaning on my friends and family for moral and even practical support. Doing nothing but work is a waste of a life.

Maybe realize that some people struggle to find happiness and will constantly be struggling. Not everybody can have a family. Not everyone can find a job after school. Not everything is easy.

Maybe keep that in mind.

That is not a life I want to live in the slightest. I mean it: I'd rather kill myself than live that kind of life. I only work so I can fund my personal life. No personal life, no reason to work.

I'm just an inherently noncompetitive person, and I'm not career-minded in the least.

I've been like that my whole life. When I was in high school, people told me I had to take a ton of AP classes and do a ton of extracurriculars if I wanted to get into a good college. I refused. I took a tiny handful of honors classes -- just the ones that interested me, I coasted through all my regular classes and made more As than not with minimal effort, and I was involved in exactly one club which had very little time commitment. In the yearbook, all the other seniors had this long list of clubs below their pictures, my entry looked almost empty because I had exactly one. After high school, I went to a state university, got my CS degree, and got a job out of college at a fairly conservative B2B company.

TBH, even though I'm lesbian, solidly aromantic, and an extreme introvert, I wish I was straight and able to tolerate living with other people so I could eventually marry a man and spend the rest of my life as a housewife. I'm like the total opposite of career-minded.

But, really, I think you're overstating it. There's a certain segment of the industry that's really competitive, and the rest of the industry isn't like that. Yeah, sure, you need an impressive resume to get into the Big Four or to join some Silicon Valley startup that's pioneering emerging technologies and has dreams of changing the world. But for every company in that mold, there are dozen conservative, enterprisey corporations with headquarters in "flyover country" (I hate that term) that just want interchangeable fleshy cogs to maintain 20-year-old legacy software or a colossal J2EE stack filled with FactoryFactories and the most enterprisey enterprise piles of code you can imagine (or both, with a legacy backend and a J2EE portal). And a decent chunk of them aren't tech companies but are banks, healthcare companies, local governments, etc. You're not going to find them automating software engineering with AI; the managers probably think AI doesn't exist outside of Terminator.

I read about those laid-back enterprise shops, and think about the coal miner who just wants to live his life, mine some coal, and retire, all the while not competing with anyone. Or the factory worker who just wants to put in a solid 8 turning a wrench and go home to get on with her life, not worrying about the robot that will do the job 25% more efficiently and with 85% fewer errors. Or (very soon) the truck driver. Or (also sooner than we think) the generic white collar paper pushing office worker... Fortunately, so far software has been safe. Software does not yet write itself. But it's only a matter of time. We are all slowly being forced to compete ever more fiercely, with more people, for fewer and fewer jobs. The trend is inevitable and irreversible.

I'm not naturally a competitive person, but over the years I felt I have had to train myself to be so, and I will teach my (now infant) daughter to be _ruthless_. It's a matter of career security for me--it will be a matter of survival for her.

Maybe your github contribs are different from mine, but all the projects I can see myself working on now would just make me a better buggy-whip maker.

Programmers generally want, in no particular order: - a good work environment - good pay - interesting things to work on

If you don't provide one you'd better make sure you well compensate with the other two. In practice, employers just say "meh, tech shortage" instead of taking responsibility and admiting "yeah, we kinda suck, the people we'd truly want working for us don't even consider applying so we're stuck with the rest".

Well programming is one of the most entertaining thing that exists. It can be a great hobby, just like some others will do wind surfing, build RC vehicles or go to the club. Even if you are already paid for it during the day. Contributing to common goods and exploring new stuff is very fulfilling.

Yes, I totally agree. But doing it 40 hours a week is enough for me and after 5pm I want to do other things as well.

Interviewer: I see you have a impressive profile on Github, but can you write an algorithm for quick sort on the whiteboard?

It's right up there with predicting that no one will ever need ${product}, or writing news headlines with yes/no questions.

We are knowledge workers. We work by thinking and acting. A graph captures none of the first. The most valuable code I've ever written for an employer was about 100 lines that took 2 weeks to write. Would the commit graph capture that?

I have gotten into arguments with my boss about hiring based on commit graphs and commit counts. I lost. We hired someone who checks in a lot of stuff, but often has to fix it with other changes. His graph and change count looks great. It's a nightmare working with him.

In my experience, commit graphs are bogus.

> For those of us who spent the past decade making a billion dollar open source software company however, there is nothing free or spare time about working in the open.

> [...]

> The way to get a job at Red Hat last decade was obvious. You just started collaborating with Red Hat engineers on some piece of technology that they were working on in the open, then when it was clear that you were making a valuable contribution and were a great person to work with, you would apply for a job. Or they would hit you up.

Actually, this sounds exactly like working for free. You do some spec work and if they like it maybe they'll hire you.

Except the difference is that the with your doing is also applicable to you (presumably that's the reason you decided to hack on it). I got my job at SUSE in a similar fashion, but I never assumed I would get a job out of my contributions -- I was just a high school student at the time, playing with container runtimes.

All of that being said, hiring people solely based on their online profile is a shitty idea. It might be useful to get leads that way, but if you have an applicant who has no online profile you should consider it an opportunity to convert them to a free software developer (not as a candidate who doesn't want to work in the open).

[1]: http://elections.stackexchange.com/#stackoverflow

At least in SO's case there's not a promise of possible employment being dangled in people's faces though -- it's all upfront.

The author seems unconcerned about a particular company having so much control. Note that he compares not having a Github account to not having email or a cellphone in general, rather than to not having e.g. Gmail or an iPhone in particular, which would be a more apt analogy. It's a disheartening reminder of the trend of the internet moving away from decentralized protocols to centralized services.

For those of us who do have open source code on Github, the consensus is clear : despite the hype, most employers don't really look at Github in any depth. They mostly prefer to grill candidates, rather than look at what they've actually done. I guess it must be more enjoyable.

When I interview people I like to grill them on what they've actually done. All evidence you may find on a CV or on github is secondary to what they can actually speak to. That's my opinion of course, everyone has their way of finding good people.

Sorry, but I have to really object to this idea that programming every waking hour with great passion is a positive job qualification. Sounds more like a recipe for burnout.

Edited for clarity.

i.e. at significantly greater risk of burnout. I'd prefer to hire staff with a healthy work/life balance

If I am interviewing people then I would try to avoid this line of thinking (i.e. how much time is spent out of work programming) as it strikes me as unfair. My reasons are that not all candidates could spend every waking hour of their time even if they wanted to for various legitimate reasons. For example if you are a parent looking after a baby/toddler, it would be totally unreasonable to expect you to be coding "every waking hour".

If you had two candidates that were 100% equal except one had no real non-work-commitments of note and spent their evenings messing around on github, and the other was a parent who wanted to code all night but had to look after their kids in the evenings, which would you pick? If you picked the non-parent based only on the non-work github commits are you descriminating someone based on the fact they have kids? I dunno - but I thinik it would need careful consideration.

As I said - I dunno, but it strikes me as this would be an unfair thing to look for. Afterall, you're recruiting fill a role, not recruiting a lifestyle.

Not really. It doesn't tell me how well they play with others, or how well they work to someone else's requirements. Finding obnoxious pricks who know how to write code but stink up the workplace with a terrible attitude isn't particularly hard.

A good looking github contribution graph looks kind of professional, also if you have starred some repositorys (which probably means you are active and love what you are doing)

WTF how is this a good thing?

Of course, if being a develoepr is only a "job" - this sucks.

For example, I am coding 8h+ a day during my fulltime job. When I am back at home/weekends, I also spend a lot of my time to code private projects instead of playing games

Someone can certainly enjoy their job--and software development is certainly nothing special--without also wanting to spend their nights and weekends doing the same thing. For that matter, I'd probably take such a narrow set of interests as something of a disqualification.

It doesn't mean that you have a narrow set of interests. It just mean I use a part of my free time to code. Others are watching tv, playing games or doing other time wasting stuff.

There's no need to say X is "wasting time" in such an objective tone. For many, spending hours on the weekend doing programming is a waste of time (and it can be, most of the time). For you, it's fun. For others, they just don't have time to do it. No need to judge or expect others to live the same life as you.

https://help.github.com/articles/why-are-my-contributions-no...

Good god.... I love GitHub and what it allows for but let's not paint this as the "commoners" knocking down the walls that protect the "elites" in their ivory castles. Commiting to GitHub does not, on it's own, make you a better developer or a better person. In the same way that not committing to GitHub does not, on it's own, make you worse developer or a worse person.

I've met people who don't have single commit to a public GitHub repo that are FAR better developers (and people in some cases) than ones I've know that are deeply ingrained in a public project. In some, not all, cases there are different skillsets required for OS work vs working at a "closed source" company. And while we are on that subject I'm quite sick of some of the attitudes I see on HN sometimes around "closed source" like it's some evil thing. It's not, people have to eat, have to pay rent, have to support their families and anyone that thinks you can do easily that while working for a for-profit company are living in a dream world. How many times have we seen posts here about how little money is actually given to OS? Sure I'd love to be able to only work on OS or work for a company that is open but there are very few success stories in that area. The cognitive dissidence the HN crowd expels when they fawn over the SasS companies or various other SV unicorns (all closed source) here and then derides closed source is astounding.

All of this to say the message of "Your GitHub profile will mean everything for your career" is simply bullshit. CAN it give you a leg up? Of course, but experience working for a company and in that kind of setting is much more valuable to the vast majority of companies. Take a look at Linus Torvalds, undoubtedly a genius and a person who has done immense good for the OS community, however his temper/attitude are legendary with HN periodically posting links to his smack downs on mailing lists or the like. That said do you think many companies are looking for that kind of an employee? I think not (No disrespect meant to him at all, it works for him and I doubt he is looking for a job at those kind of places anyways).

Most of the companies I've worked for or interviewed with have either not cared at all about my GitHub profile or even if they say they do care they don't give it more than a passing glance at best. Focus on being good at what you do and if that happens in public on GitHub/GitLab/etc then all the better but don't bend over backwards to make your profile look good at the expense of actually knowing your shit.

If you're able to fuck around with projects on Github, you are the privileged elite.

>> Proprietary software generally leaves society worse off than if that same software were free and open source. In that sense, it is some evil thing.

I can agree with that but it also must follow that the choice is "closed" or "open" when often the choice is "closed" or not at all. It reminds me of the piracy arguments that equate 1 downloaded movie to 1 lost movie sale when in fact if the pirate was unable to download it for free they would not have paid for it at all and just gone without

>> I would like to think that the "closed source software is evil" crowd is mutually exclusive to the "fawning over SV unicorn" crowd.

You are probably largely right here. I wouldn't go as far as to say "mutually exclusive" as it's easy for people to get caught up in the hype of the moment and chide someone for not OS'ing something or complaining that more stuff should be OS minutes after they commented about how great Uber/Lyft are (or similar). I know that I have, at times, felt the "righteous anger" against something being closed source or been ready to jump on the commenting bandwagon before stopping to think about it.

The correct counterfactual to argue is, would the software exist at all if it weren't proprietary? Usually the answer is a resounding "No."

No, it does not.

Yeah except for the tiny niggle that an overwhelming majority of contracts stipulate that you can't actually contribute to OSS either on or off the job due to the fact that every single thing you think of while employed (and sometimes for a period after your employment ends) belongs fully to your employer.

In the near future all of our problems will be solved by minor celebrities of fashionable Github repos.

But I've always made a point of writing OSS code the same way I write closed projects: Well structured, documented code, proper tests, user guides and API documentation, architectural diagrams if necessary, and a professional attitude when dealing with users. Every major repository or sourceforge or sunsite tarball is a public statement to how I write real products that people use.

Over the past 20 years I've written close to 500KLOC of finished OSS code. It's honed my skills, kept me sharp, helped others, and gotten me jobs.

Companies (and VCs like YC) not only do not adequately compensate those who produce the free software they use to build and grow their businesses, but they show no greater inclination to hire them, despite using their software. (Zed Shaw has written about his.) Absent a clear monetization strategy, I think the time developers spend working on open source side projects would be better spent building personal wealth, especially considering how many of them will effectively become unemployable once they turn forty.

I'd recommend OSS and GitHub not as a prerequisite to landing a job, but as a means of adding direction to your career. At your day job you don't always get to pick the technologies and sometimes you drift into the backwater of old legacy code (which the companies, understandably, need to maintain). Doing OSS can be a way of getting your feet wet doing exciting stuff of choice, building experience for your next job and maybe even build a network. Doing fun stuff. That should be the main reason IMHO.

This is so wrong that it's hilarious. Lots of garbage gets popular and there's tons of gems that go unnoticed. The meritocracy myth needs to die.

The times I've looked at Github it was either "meh, this doesn't tell me much" or "Holy shit, run away". And about 5X in favor of running away.

So it's been useful, in a sense, but not as a positive signal.

My guess is that, in general, the submitters wanted to look good to people (e.g., HR) who were not technical. They sure didn't pass a "I want to continue looking at this person" filter.

If you want to interview people effectively try this crazy formula:

0. Ask for a remote tech screen. Ask for a simple piece of work that you can evaluate and that resembles real work. Make sure it can be built and tested imperially (the best way is automatically). This should be simple and not 8 hours of work. Don't ask people to code on a whiteboard or do their best algorithmic design in a high stress interview session, you won't get it.

1. Be prepared. Know what you're interviewing for and list out he skills. Read a candidates resume and review the prior work they offer. Read their code first.

2. Code review their tech screen.

3. Make sure to ask questions about their approach to work, leadership and projects. Encourage them to ask you similar questions.

4. Have a broad cross section of your company interview. Mix up who does this, diversity is a plus here. Also, make sure designers and HR folks get a bit of time, not just engineers.

5. If the position is senior tech, whitebiarding is acceptable for architecture or planning or diagrams.

I'm guessing that would > 80% of all software developed globally?

I'm actually slightly less sure of this today... It's probably true for startups/"tech" companies; but many, many programmers work LOB in non-tech companies and I haven't heard/seen much that the hiring process has changed. If anything, we've come closer to the consensus that a small "work sample" is the best possible kind of interview - show up, here's a laptop and a small CR or project, implement. This has the advantage of being do-able remotely too, of course.

Pull requests back to languages and frameworks works if you're at the skill level and motivation to work at the framework level (e.g. Google, Facebook, Microsoft; the companies making the mainstream frameworks). But it's a dis-service to ignore many, many programmers working successfully at a lower level. It seems like the portfolio-as-key to being hired is still not very true for that category.

Haven't people been saying this for like, 10 years now?

Enough people I know and respect have moved on to other companies that my own network has actually grown. If I chose to apply elsewhere the first thing I'd do is reach out in my own network, not spam recruiters with my Github account.

Your Github reputation can be used in addition to your network, or as a substitute if you have no network, but it will not replace the impact of having others already in the industry/company personally vouch for you.

"Who you know" is still the best way to get your foot in the door, because we are all still social animals.

Sometimes, in some cases, it makes sense to filter candidates by looking at their GH. But I would not bet on that: the better filter is the code being written today, which is unlikely to be available for most of the developers.

I can't imagine spending three years of weekends developing x companies software for a chance at an interview.

Github will allow the cream to rise to the top, sure, but those "Just a job" programmer roles are going to exist for a long time. This is because many companies simply want contract fulfilling crap, not quality code.

Another issue is what happens to GitHub if they are not successful as a company. There was a story a few months ago here about how the company itself is losing money. How much will your profile be worth if GitHub goes out of business?

Hire or No Hire?

Most people don't get the time and resources to work on open source. Some times, you can't even open source something, despite wanting to. For example, when I was in academia, I wanted to open source some worthwhile projects I had completed, but was never allowed to by superiors, because they considered them as competitive advantage IP.

OK, a nice GitHub profile is a plus, but as a hiring manager it is never a make-it-or-break-it kind of thing.

Does this really take that much time to teach on the job?

I haven't used source control outside of work, but I had no problem figuring out CVS, SVN, SeaPine Surround SCM (What a flaming pile of crap), or Perforce.

Likewise, I've never used a bug tracker before work, but figuring out Jira/Bugzilla/(Whatever garbage HP sells) is much easier then reversing a linked list... Or explaining the *Nix everything-is-a-file model - both of which are parts of the typical CS degree.

Unfortunately, I don't think any of the above is realistically going to happen at any point in the next 10 years. The majority of paid-for-code is proprietary, meaning that your 9-5 work-product can never be "googled" by outsiders. As a consequence of this, recruiters and hiring managers will continue to treat open-source work as second-class-indicators, behind your resume, CV and references. It's going to take a major paradigm shift in engineering/business culture, before any of this changes.

That said, the author might be wrong about the timeframe, but he does paint a noble vision for the future. One that I'm sure future generations will be working in, and one that I hope I can experience one day.

Clear to whom and to what degree or how exactly? Then even getting over this stratagem, they might ...or not! Maybe not, most likely. I understand that this might hurt some feelings or dispel some fantasies, but this is exactly the way you (as workforce asset) are encouraged to think, and not in your best interest, really. The reality, more likely than not, is that a business has to be run and the people responsible for it have to cover the business model's needs with some X number of engineers. If the business is doing well and the men with the ropes see real benefits in hiring more, than there you go -- green light for the lucky department for getting a new pal along. The circle of developers in that area already know the contributors and just open the gate for one(s) they like. That, of course, has nothing to do with absolute quality of the contributions. It's not necessarily the best of open-source contributors that get hired, it's not even the best contributors of some specific open-source commercial project like Red Hat, it's just the best (read "convenient") in the area they need at the moment. Realizing that we're talking about an entity living under business laws of survival, you also have to assume it has to employ some of the same prosaic principles in order to survive, just like anyone else. The rest is propaganda. Be assured that your position as free contributor suits the recipients a great deal already and they won't change anything about it just because.

That being said, I agree that the exposed work works very well for engineering, just as for any other portfolio-based enrollment.

Code is objective. It solves problems, passes tests, does something new, and performs better.... or it doesn't. Social media presence has no bearing on this at all. Yet, each impart a type of online trust. One is capabilities (competence) trust and the other is marketing or branding trust.

For people who don't know the difference or don't understand the value in the code marketing/branding trust is the only thing that exists. For everybody else trust in branding loses value quickly and must struggle to compete with the other more objective trust factor. It should be noted this "everybody else" category is the minority but is more influential on things get built of prioritized.

'We' is including a domain of engineers, students, employees, employers, scholars, bug complainants, star-ers, watchers, forkers, and jobCreators...

'Our identity' is including a domain of identification, participation, faithfulness, ownership, responsibility, responsivity, lineage, heritage, autonomy, unity, temporality, follows, followed-by, and profile pictures...

Them 'perceiving' may now be an employer, fellow engineer, or utility algorithm, but I would like to plan for possible futures with higher orders of transparency in all these products.

I ask HN because I know this community will be a transforming force that anneals or explodes the potent artifacts of github. My opinion may be that github is a value, but my observation is that it has given me value. Now, what may we hypothesize together?

This creates 2 things as a byproduct:

- It keeps my standards high as it's a paid for product

- It forces me to actively maintain the projects and even provide a tiny bit of customer service

I really don't care if people have a problem with this. It's their problem at that point, not mine. I have no issue demonstrating anything or talking about it, but we're not going over lines of code in my stuff. I choose not to treat my code hosting platform as a social network.

If you work for someone else you can advocate for this. If you employ coders you can use it as a talent attraction piece, or just do it because it's a good thing to do for them.

Surely, in the course of your daily work using giant open source projects you'll file a bug, comment on an issue or even submit a pull request. Most large applications are built off of dozens, or hundreds, of open source libraries—all of which have bugs at various times.

I don't expect all web developers to have side-projects or libraries, but I would expect they'll interact with open source projects in some way. This way of thinking clearly doesn't apply in more closed source worlds like games, finance or giant enterprise—but it certainly holds for startup/web work in my experience.

I've worked at multiple companies where the red tape involved in having my contribution merged into a public repo was such a pain that it just wasn't worth it.

I've building a team of about 70 sw engineers and one of my best hires was an art student who learned code a few years earlier and the other had just finished his graduation. Both are not really what one would consider as social skilled.

If you give people a chance, a challenge, a good environment and respect them.. they will surprise you.

Everything else only matters to the startup scene in Silicon Valley, or startups in other parts of the world that want to look cool and pretend they are actually located there.

Or students believing the hype and trying to create a portfolio to cater to such companies.

Many of us work with software that isn't allowed to go outside the virtual walls of the intranet and the last thing we want to do after 8 - 10 h work, is to sit again in front of a computer.

Most consumers of Typescript for example, would be unable to contribute to the core codebase, the same goes for Rails, Redux, React, etc.

The actual percentage of consumers vs contributors I would reckon at less than 0.01%, possibly lower.

As a developer looking for a job, I would use GitHub to build a small project end-to-end to demonstrate competency, but that's just me and the slice of the programmer world I live in.

Github isn't exactly new and there is plenty of time for others to innovate in this space. Why haven't we seen this effect already? If it could happen fast it would already have happened. Why won't it be a slow taking a decade or more like the proliferation of Social networks?

Look at how much OpenBSD code gets used in highly profitable commercial products, then compare it to the level of donations they get from the same companies...

Please, please stop assuming that "software development" is a thing that you personally are inside of.

Once your time is actually overcommitted by all the things you can do for your employer, half of which aren't even code, GitHub is the wrong priority.

#FakeCommitNews