This way of looking at things is so corruptive. Does everything we do have to be about reputation? About our CV and how we're hired? About competition? How many commits does it take to compensate for that state of mind, for what it does to people? Whenever you bring those things, they only leave a scorched plain in their wake and the community is forced to move somewhere else.
> 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
"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)
> In Hanoi, under French colonial rule, a program paying people a bounty for each rat tail handed in was intended to exterminate rats. Instead, it led to the farming of rats.
"The most commits wins" and "the most passing tests wins" are pretty disturbing sentiments. That's not a way to write good code, it's a way to take on low-effort tasks for commit count or write 10,000 happy-path unit tests.
"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".
Disagree totally. There are gazillions of software developers quietly plugging away at gigantic companies with over 50k headcount whose contributions will never make it into open source. Think business intelligence software, accounting software, embedded systems developers, etc.
Probably. I imagine it's on the same level as having the right combination of buzzwords on your resume - you're unlikely to make it to the brain teaser round without it.
I wouldn't sweat it. Employers have been rejecting great tech candidates for dumb reasons for decades. I'd argue that if someone won't hire you because you don't have an account on some Internet service, you probably dodged a bullet and would not have wanted to work there in the first place.
Though of course it can't /hurt/ to have a kick-ass Github profile, but I also doubt we'd be at a stage where it'd be required to get a job in the industry easily.
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".
Plus, a lot of programmers just don't have/want to spend the time packaging things to be placed online, going through legal, or make blog posts about their code.
Exactly. I currently work in financial sector and if my employer found out that I post code to GitHub, I would get fired instantly. Also, I don't like doing for-free programming during my spare time -- I have more in life than crunching code all the time. Yes, I do have some programming related side projects, but I don't feel like posting them publicly as they are not polished to my usual coding standards. If some companies see programmers as some robots that write code 24/7 (even better - for free), I don't mind them skipping my CV as we probably are on different boat anyway.
Fired, sued, and perhaps arrested if Aleynikov is any guide. I don't see any problem with employers looking at a candidate's OSS/free-time programming if it exists, but that's very different standard than requiring it.
Not just gigantic companies... plenty of startup employees have empty profiles as well and are doing fine. Companies that open source are actually pretty rare.
Exactly. I work at a very conservative B2B telecom. Nothing we do is open source, and having worked at another B2B telecom in the past that largely avoided open source, I have a feeling the entire industry is like this.
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.
This almost seems like more of a hype article for Github than reality. It's certainly an extreme version of some truths (good and bad), but this is not how things are going to become for developers, certainly not as soon as 2018-2019.
I saw the reality of this on a job posting the other day, the recruiter wrote that applicants with github work will be given preference. This is pretty stupid really, a lot of really good developers are working on projects that cannot be shared or discussed or open sourced. Just because you haven't had the time between 1am and 3am to contribute to an open source project doesn't mean you suck as a developer.
No, it doesn't mean you suck. But it does mean that those with full GitHub profiles usually spend every waking our programming. If they have e that much passion and programming hours under their belt, and you can see their code examples, the chances of hiring a false positive is a lot lower. It's all about mitigating risk. No one is saying you are worse, but hiring you is more of a risk than hiring someone such as I just mentioned above. It's harder to really know how good/passionate you are.
>It's harder to really know how good/passionate you are.
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.
We interviewed a guy and without prompting (that's probably off limits anyway) he told us how he's divorced and has no real social life, so working long hours for us would be just fine by him. I wasn't impressed by him to start with, but that just put the final nail in the coffin for me. Not only did it sound a bit desperate, I'd prefer someone with a healthy attitude toward work and life. The other hiring managers felt the same way.
Marital status certainly is off-limits, and I've found a good general rule to be that anything that's impermissible for me to ask an interviewee is something that also doesn't merit mention when I'm on the other side of the table, both because to raise it puts my interlocutor in an uncomfortable position, and because such things really are not relevant in any case.
I'm glad to hear that attitude still exists among hiring managers. I'm working at an otherwise great company that doesn't give a rat's behind about work/life balance. I.e., if you're not still here at 6:30 or 7:00 PM you must not be a team player. Never mind if you have a wife and small child that you'd like to get home and have dinner with.
I agree to a certain extent that seeing examples of work reduces recruiting risk, but I disagree that looking for people spending "every waking hour" programming is something positive.
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.
> I agree to a certain extent that seeing examples of work reduces recruiting risk
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.
It's dumb. I lost my GitHub profile on my resume and I have yet had one person ask me about anything I put up there. It seems that having open source contributions is a check mark for you but is a pretty pointless piece of data for making a hiring decision. Nobody is reading through all your code to figure out if it's actually good or not.
You don't need to make your source public.
Just check it in as private repository and your contribution graph is going to be filled.
Some recruiter can now see that you work a lot - probably also on weekends and so on.
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)
A developer who loves his job/hobby also codes in his free time (because it is also a hobby)
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.
I realized that passion to your work has a huge impact to your application.
If you are software developer (what I excect) and have a job - yeah it is a valid opinion. If you don't want to code in your free time it is up to you.
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.
And others are spending time with friends, families, taking care of their sick relatives, their kids, going hiking, reading, volunteering, etc.
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.
I only just noticed that you can make private contributions show up on your contribution graph- still there are lots of reasons stuff might not show up on there.
At least in Finland (don't know about the rest of Europe) the information must be collected from the applicant and not by doing internet searches [0]. If a company wants to use any other sources, they must ask the applicants permission first.
> Smart people will take advantage of this — they’ll contribute patches, issues, and comments upstream to the languages and frameworks that they use on the daily in their job — TypeScript, .NET, Redux.
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.
Towards this end, is there a place that matches developers with small projects needing just a small amount of help? Say, a few small bug fixes or enhancements? I'd be happy to contribute but I don't want to commit too much of my time nor do I want to navigate the maze of a larger project.
I think this guy feels this will be true because that's the bubble he lives in (an open source bubble). His bubble is not reflective of the entire software development community, however.
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.
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.
Threes is great, and I bought it when I realized 2048 was based on it. And the makers of Threes were right! I have never gone back to 2048, but I still sometimes play Threes.
That's an interesting point - game companies are particularly defensive of their code, but shockingly willing to share the latest shader techniques and other insights most fields treat as secrets.
I think that's just because that for the most part, their competitive edge is the creative work as a whole, not some particular technique.
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.
That's a part of it for sure. I think another piece is that everyone I knew in the industry was there because they loved games and money wasnt a primary(but was an important) concern. For instance I knew every title locally under development long before(6+ mo) it was even leaked because there's a sense of shared community in that industry.
> their competitive edge is the creative work as a whole, not some particular technique.
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.
Game dev here. People don't share engines because there is no reason to. Unless I'm trying to license my engine out like Crytek or Epic there is no reason for me to open source my entire engine. You can talks all the time about the interesting parts of engines, tools, and techniques but there is no reason for a company to just be like "here is our engine bye"
25 years ago people would have said the same thing about OS kernels, and yet here we are. Some of the underlying problems I see are that the game industry is still young and hasn't really standardized everything yet. Because of that, there is still ruthless competition between the hardware and GFX card vendors. Vulkan is a step in the right direction, but it will obviously take time for it to become adopted.
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.
That's a pretty naive view of things, it's not the lack of GPU standardization that drives engines, it's the fact that fundamental bits of gameplay drive very diverse engine requirements.
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.
Games typically come with a lot of creative assets such as artwork, music, etc. that are copyrightable in their own right, but out of scope for open source licenses. Those assets could be released under a permissive license too (like Creative Commons), but a potential route for an "official", albeit open source game release would be to release the code freely, but not the assets. That could lead to clones with subpar assets, or -- just maybe -- someone/studio/whatever will create superior assets, improve on the game engine (as they're free to do so) and now you have a better game.
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).
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.
> 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.
My github is where I keep that, now. In the past, I had some example work I could pull up and show, but for the most part, all of the stuff of my past employers is behind closed doors, so to speak.
...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).
As someone who did mods for years I think it can vary widely. A mod can become as consuming as a job, yet without the benefits. While a few have hit it big there are plenty more whose creators have nothing tangible for their efforts.
> for example, 2048 and Flappy Bird both had open source versions, possibly unofficial
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.
Actually I knew that, the 'possibly unofficial' was more in reference to the Flappy Bird github repos I've encountered. I've checked the code for 2048 a few times to see how HTML5 games can be made (I used to make Flash games).
The original 2048 was not the 2048 we all know and love but the non-open-source iOS game "Threes" of which 2048 was a clone. Here is their story http://asherv.com/threes/threemails/
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.
> 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).
Your examples of AAA games with open-source versions are Flappy Bird and 2048? We have different ideas of what makes a AAA game...
No, I can't think of any AAA games that have intentionally released their code open source (unless it's years and years after the game has been released, like Quake, for example). They usually only add mod support. Probably the closest thing to a AAA game where the source code was fully available was Minecraft, but that's because it was originally written in Java and thus easily reverse-engineered.
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.
> Previously privileged developers will suddenly find their network disrupted.
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.
I'm quite sick of some of the attitudes I see on HN sometimes around "closed source" like it's some evil thing.
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.
It's not, people have to eat, have to pay rent, have to support their families
There are plenty of people who think of stripping, porn and prostitution as some evil thing. The argument that strippers, porn actors/actresses and prostitutes need to eat, pay rent, etc. does not detract from that. However, I do not think that there should be laws against porn nor against proprietary software.
I do agree with you that it is much easier to find a job doing proprietary software development. I would be a hypocrite if I suggested that people should not take those jobs. Companies will fund open source if and only if it furthers their business objectives. You are correct in saying that open source projects are, in general, woefully underfunded and the open source company success stories are few and far between.
I would like to think that the "closed source software is evil" crowd is mutually exclusive to the "fawning over SV unicorn" crowd.
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.
I agree. If you happen to do good work on GitHub, it can give you a leg up. Any effort poured into making one's profile "look good" is probably better spent actually doing good work or, failing that, studying for those silly data structures & algorithms whiteboard questions.
> I'm quite sick of some of the attitudes I see on HN sometimes around "closed source" like it's some evil thing.
>> 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.
> 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.
If you're able to fuck around with projects on Github, you are the privileged elite.
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.
>> They mostly prefer to grill candidates, rather than look at what they've actually done.
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.
Would you like to be judged by the number of lines of code you submit? It's not much different than being judged by your commit graph on GitHub. If we judge ourselves, and others by this ridiculous metric, we're cheapening our profession.
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.
I do a lot of recruiting, for both paid and volunteer coding roles. I've been hiring for about 13 years, and I've been coding professionally for about 25 years. Before that I coded as a hobby, from about age 11.
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.
I can confirm from the employee side. I've worked with 40-60 people total that I at least sort of remember.
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.
I used to be more into having side projects, and I continue to play with things, but due to employee IP contracts it's not really feasible to release them. My employer owns my brain, and while they can give permission to release things here and there, there are restrictions and processes to go through, and it really inhibits spontaneous contributions.
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've always fought such clauses, or if it's a standard contract that can't be changed, I made sure to get a written exemption stating that work done on my hardware, on my time, on my ideas (not anything the company is involved with) is mine.
I understand the company wanting to protect itself, but I have to protect myself too.
Often these intellectual property terms are mandatory conditions of employment. I always read here about people "fighting" these terms but nobody's ever willing to go into actual detail about what they did that was successful. At past employers I've tried the cute "strike the clauses out in your employment agreement and initial them" trick and that has always been followed up by a very stern "sign it unmodified or GTFO" talk from HR/legal. Responses to push-back are always along the lines of this is our policy and policies can't be changed. So how did you get this "written exemption"?
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.
You don't. The unwritten assumption or meme I keep hearing from the community (not necessarily here on HN) is that if you're good, you'll just keep turning down jobs with such clauses until you get an offer from somewhere without such clauses. Otherwise, too bad: you're not talented, passionate, 10x, or whatever enough. Sigh. Sucks to be tied down to a state that does enforce and seems to encourage those clauses.
I think the other way to look at it is trying to gradually engineer scenarios where you do have that flexibility to walk / take another offer.
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.
I fought a contract clause, it was a separation agreement rather than an employment contract. I imagine you would have a lot less leverage going in than you do going out.
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.
Well, they were switching architectures and wanted to retain me in a contracting capacity. They'd offered to keep me on but I was ready to move on. I got a nice severance and I'm still receiving contract income from that client. Getting my final check soon.
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.
You don't sign anything without your lawyer looking at it first. Then bring up that you do volunteer work, which may include thing like maintaining the website for your home owner's association, things like that. So have your lawyer counter with language designed to protect the non-profits that you may volunteer at. Then any open source work you do, assign copyright to the FSF (them being a registered non profit), and you are covered.
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?
Here is how I got approval for a contributor license agreement.
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.
Every contract I've had, had some clause that more or less said that any work I did in my personal time was owned by the company. Every contract has that clause removed when I requested it be removed. No company ever argued the point. (I've only been at 7 companies and ~15 contracts)
California protects these rights by default. And no company can take them away from you. (I'm not a lawyer, but this is my understanding of all current law).
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.
California protects those rights by default to the extent that they do not infringe on anything that your employer is working on. Not knowing that your employer was working on it does not protect you.
The bigger your employer, the less of a protection California's default is.
Right, so for example, if you work in one of the big places that has their finger in almost every pie, it's tough. What could you work on that's not conceptually related to something Microsoft or Google are doing? You couldn't even make video games.
There are limitations on what employers can demand regarding assignment of employee IP in several states: California, Delaware, Illinois, Kansas, Minnesota, North Carolina, Washington, and Utah. This list was current ca. 2001, so it may be different now. https://www.ieeeusa.org/members/IPandtheengineer.pdf
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.
I don't know what state you are in, but if you are in California, state law gives you pretty strong protections if your work is not on company time or using company resources.
Side projects are mostly important for new grads or students looking for internships, just to show - "look- I can do code that's not just my data structures homework assignment."
You would think, I've been in the industry 25 years and my side projects are still my biggest sales tools when it comes to changing jobs or joining projects. Makes a huge difference to be able to show that I stay constantly on top of the latest changes and best practices and apis even when my current day job may be using an outdated stack.
The biggest mishires I've experienced were generally students with a whole lot of history in their GitHub accounts. I haven't done a thorough post-mortem on what was going on there, but I wouldn't rule out plagiarism or an ability to make small tweaks but little sense for dealing with a larger, more complex project.
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.
>> The vast majority just don't have much to show, having spent their years working behind walls on closed software.
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 :-)
In the case of people with a portfolio on github, it's still somewhat hard to tell what they actually did in the projects, e.g. if they build an app from a template, it looks like a ton, you also can't tell if the resulting thing actually works.
For me, I'll certainly look at a Github if someone links it or mentions their OSS work on a resume. I'm looking for positive evidence that a candidate takes on substantive tasks and writes good code, which means looking to wherever a candidate has put their effort. It's never the only factor, so I have no problem saying I'll look to Github iff it has content.
I think this is mostly accurate in terms of using github as a way to determine someone's ability to do quality coding (though if someone didn't do well at "whiteboard" coding but had a long history of contributing quality code on github, I'd probably weigh the github code higher), but it seems to me that the benefit of github contributions is more on getting your foot in the door and establishing a reputation.
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.
But if you have hundreds of initial applicants to sift through, the one having some open-source contributions would surely standout. Even considering that it won't affect your final say, reaching the interview stage is definitely advantageous. I don't agree that lack of Github commits would ever be a deal breaker in hiring, but having them does signal a positive factor provided that the projects and contributions are purposeful.
> But if you have hundreds of initial applicants to sift through, the one having some open-source contributions would surely standout.
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.
If this line of thinking ever takes off, it will be just another one of those meaningless rituals you have to go through to signal that you're part of the club. Polish your resume, dress up nicely, read 'cracking the coding interview' the night before. There might actually be a great idea for a new book in there: "How to fill up your GitHub account with random crap so future employers think you're really really passionate".
Can confirm. I tested it out myself and created a bogus LinkedIn profile to match with it.
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.
Now it's expected of you to be impressed and to make a generous offer, of course! (Any further delay with any sorts of interviews is simply ludicrous, you see.)
I've got a fair amount of code on GitHub and on my website, but judging from my most recent job search, hardly anybody ever looks at it. And it certainly doesn't seem like it does anything to get you through the first sourcer/recruiter hiring layer, which almost entirely consists of people who are not engineers.
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.
There are two sides of the coin here, which should not be opposed in my opinion.
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.
> 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).
Or because they work extensively on OSS projects that don't use GitHub.
Actually no (not in my case, I mean! YMMV). Something I can tell with certainty is that in my recruitement channels for the last 2 years, people either do OSS on GitHub, or are not doing OSS at all.
That might be true in your recruitment channels, but in general it's a problematic assumption. Many prominent Open Source projects don't use GitHub; in particular, that applies to those large enough and/or old enough to have and maintain their own infrastructure. I've run into that problematic assumption a few times, and it seems worth calling attention to.
However, many prominent Open Source projects that don't use GitHub have mirrors on GitHub, and as long as you star them, they appear in your GitHub profile if you contributed to them using an email that is registered to your GitHub account.
Here's a question for you as a recruiter, from me as a potential employee:
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.
I use GitHub only to see if someone has a side project and their interests. Never to judge their code quality. I use GitHub to store code when I'm experimenting or teaching someone else.
As a person who has been recruiting software engineers for the past 12 years, and quite picky about it, there are two signals I'm looking for at the first stage of the funnel: LinkedIn (more specifically if we know anyone in common who can endorse you, and your recommendations), and your OSS profile. The only thing I use a CV for is to look up your contact details.
The next stage is all about 1on1 conversations and pairing sessions.
Probably that's how "there is huge programmers shortage!" myth starts. I don't use LinkedIn and will never use it as any other products that rely on dark patterns and disrespect for privacy. Problems with OSS I've written in my other comment. And I'm really not in minority -- most of very good programmers I know are like this. So sorry, but as a requiter you are only doing disfavor for yourself relying on minor pool of candidates.
As someone who is about to re-enter the job market (moving cross country soon, employer won't consider remote options), I cannot tell you how happy I am to read something like this, and all the agreements. I have almost no online presence for github, partly because of the "walled software" you mentioned. This helps alleviate a lot of stress I had about not finding jobs because of my github profile.
Seriously, I had to stop reading this article after the ridiculous hyperbole of the first sentence.
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 see having a great public profile more as a sufficient condition than a necessary one.
Meaning I wouldn't rule out someone if they didn't have a good public profile, but it could help the person if they did have one.
The value isn't the commit history, the value is the network of people you build up while creating the commit history. That network doesn't evaporate when you change jobs. That network will likely help you land your next job.
I'm concerned that many programmers who use mostly OSS (e.g. web developers) never submit a single patch to any of the multitude of projects they benefit from. Clients save millions of dollars because dev agencies leverage tons of free/open-source software. If programmers do a proper job they should routinely come across bugs or incompatibilities in at least a few of the myriad gems, node modules, etc. What could be more natural than for the developer to fix the bug and send a pull request back to the maintainer?
When looking at candidates I almost always find some correlation between a meaningful public commit history and quality.
I'm not so sure about this. My experience with contributing to (smaller) OSS projects on github have been mostly positive. However a few projects won't review/merge patches possibly because they've been abandoned.
Public work is just a bonus. Like, "oh, here's some stuff you've done. I can look at this."
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
Can confirm this as a hiring manager as well. Even if I do find Github activity, or even better strong OSS contributions, experience shows that those are generally terrible predictors of the candidate's ability to work in a team in a fast-paced continuous delivery style workflow.
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.
Actually, as a security and privacy advocate, I'm proud that you will get exactly 0 results (not counting person of the same name) entering my real name to Google search and I'm actively keeping it that way.
The opinion represented in the article is based on top of several false assumptions.
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 recently read a novel called "A Fine Balance" by Rohinton Mistry. One character, Ashraf Chacha, is a man who works as a tailor. He is extremely grieved by the death of his wife. He talks about how when she was alive it never bothered him to spend all of his time reading or sewing - just knowing she was there in another room was enough. But after she dies, he regrets all the time he foolishly spent away from her.
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.
I used to agree with that, but competition for employment has gotten so cut-throat that when you spend time not being productive, not learning, not building your network, not adding to your resume, you can be assured that your competition (people wanting your job or the job you also want) ARE doing these things. Thanks to AI and robotics, we can expect things to get more and more cut-throat as time goes on. When you're out of work and a few months from insolvency, you're not looking back and saying "Man I wish I spent more time slacking off with my friends and family".
Sounds like you have a great life and great network of people around you so maybe telling someone what they love is a waste of life is probably not a good use of your 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.
> competition for employment has gotten so cut-throat that when you spend time not being productive, not learning, not building your network, not adding to your resume, you can be assured that your competition (people wanting your job or the job you also want) ARE doing these things
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 appreciate your thoughtful comment. I don't think any sane, well-adjusted person _wants_ to live that life. But I think the unstoppable forces of globalization and automation are slowly forcing that kind of life onto everyone.
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.
I'm not trying to be dismissive of your concerns, but do you think the truck driver will keep his job when automation comes because he spent every waking moment trying to rise to the top of that industry? The world's best buggy-whip makers probably did not make a graceful transistion to more modern transportation.
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.
I have a strong suspicion the so-called tech shortage is just an excuse employers use to justify their own shortcomings.
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".
> As adults, we have very little free time and spending it on software seems like a gross misallocation of resources
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.
I used to feel like that. But now, 10+ years into my career, with a wife and 2-year old son, plus a full time programming gig, I just don't have the time or energy to dive into new projects after work or on the weekends.
15 years ago, you went to Freshmeat or SourceForge to find open source projects. Now it's Github. In 5-10 years, a different open source repository might be more popular.
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 software developers coming from a primarily closed source background, it’s not really clear yet what just happened. To them, open source equals “working for free in your spare time”.
I'm guessing that would > 80% of all software developed globally?
I have to say that this post was inspiring to read. It's everything that software developers had dreamed of and idealized. Owning your own career. Building your own brand. Doing your work in the open. Your career progress being decentralized and determined by the trust you've built in your network of colleagues, and not by some pointy haired business guy.
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.
I think that looking at a GitHub profile is tricky. Very few people get to work on open source projects. And quite frankly, Linux's model of "trying to get noticed by the admins" doesn't scale well at all. There is a lot more to it than he's suggesting.
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.
This article is a kind of half-truth. Sure, RedHat may reach out to you if you're consistently providing value, though that's probably the exception.
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...
245 comments
[ 2.0 ms ] story [ 612 ms ] thread> 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
"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.
"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".
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 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.
I enjoy my job, but simply want to do other things in my off time.
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.
Haven't people been saying this for like, 10 years now?
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.
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.
i.e. at significantly greater risk of burnout. I'd prefer to hire staff with a healthy work/life balance
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...
[0] http://www.finlex.fi/en/laki/kaannokset/2004/20040759
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.
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.
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).
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).
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
"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.
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.
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.
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.
It's not, people have to eat, have to pay rent, have to support their families
There are plenty of people who think of stripping, porn and prostitution as some evil thing. The argument that strippers, porn actors/actresses and prostitutes need to eat, pay rent, etc. does not detract from that. However, I do not think that there should be laws against porn nor against proprietary software.
I do agree with you that it is much easier to find a job doing proprietary software development. I would be a hypocrite if I suggested that people should not take those jobs. Companies will fund open source if and only if it furthers their business objectives. You are correct in saying that open source projects are, in general, woefully underfunded and the open source company success stories are few and far between.
I would like to think that the "closed source software is evil" crowd is mutually exclusive to the "fawning over SV unicorn" crowd.
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.
I agree. If you happen to do good work on GitHub, it can give you a leg up. Any effort poured into making one's profile "look good" is probably better spent actually doing good work or, failing that, studying for those silly data structures & algorithms whiteboard questions.
>> 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.
If you're able to fuck around with projects on Github, you are the privileged elite.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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
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.
The next stage is all about 1on1 conversations and pairing sessions.
Thank you! :)
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.
When looking at candidates I almost always find some correlation between a meaningful public commit history and quality.
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
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.
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.
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.
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 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.
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.
I'm guessing that would > 80% of all software developed globally?
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.
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.
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...