Because I myself feel that this is such a good and reasonable way of hiring people, I wouldn't want to work for an employer that wouldn't let me do open source work.
I mean, it's also because I consider open source to be the public sphere, and I really do believe in software freedom. Maybe my professional metaphor would be the coder as a writer. Of course I want to see your published work.
I would guess the environment candidates are selected from influences these numbers significantly.
And you're right, I'd understand that in some of these environments, OSS isn't necessarily considered fun or relevant.
Then again it's all speculation.
Out of curiosity, what do you mean by this? What sorts of things do they all have in common?
Regardless, I actually think this paradigm works for entry level jobs at most companies. You don't have to know anything for your first year in most cases. You just have to be able to show up and follow instructions.
show me freebsd or linux kernel contribution on github, for example
I do understand what you're saying though but I don't think people are going to just search Github for your name on the off-chance that you're on there, I suspect that what most people do is look at the things that you've specifically mentioned in your CV.
The wrong empoyers don't care. The right ones do. My github portfolio is a means for me to determine if a potential employer is suitable for me, not the other way around. It's not a test for me to pass, it's a test for a potential employer to pass.
If a recruiter brings up things listed on my LinkedIn page, I know they're not suitable for me. If they bring up things on my github, I'm reasonably positive I want to talk to them. One company's CEO asked me a whole bunch of questions about one of my projects. Not as an interview, but as a peer. He had a genuine interest in my side projects. If he'd asked me to come work for him, I would have said yes in an instance.
I will never understand the belief that side projects are in any way necessary. I'd much rather have a well rounded individual who isn't moonlighting on other things but rather can bring his clear focused mind to the office.
I really like it when my specialist has a prominent public profile.
A recent case: tenure at a major university, had written or was quoted in many good journals and papers, and had a number of impressive accreditations (for example he was also head of his specialty's medical association for the country). This showed dedication and interest as well as some measure of intelligence.
I was accordingly confident he was on top of the latest developments in his field and would be able to deal with complications better than your run of the mill specialist. The care was great throughout.
Similarly, our lawyer has been quoted twice by the Supreme Court in Singapore, has written many articles in the Straits Times, and does great (and visible) pro bono work, all of which I could find off a quick Google for his name. Whilst I hired him based on a recommendation, it was comforting to see this public confirmation of his ability and interest in the field.
My reasoning is that if someone is very good in his line of work, some of that work starts to spill out to the public, either by research, teaching, articles, blog posts, etc.. If a person is not a pure introvert, working all by himself, and is quite good, invariably someone will notice it..
Why it's cool... I don't know. I agree it helped me in the early days of my career, but at this point, as a senior developer I can pick up new technology much faster than my early days. I can come up with a working solutions much faster.
I like my job, and I like programming... But there are other things I like too.
So, why do I need to work long hours and program outside of my job? I have good enough communication skills to convey my experience. If I'm not hired for not having an active github account, or a side project, there are five other companies that would.
Just because we do side projects does not mean that we do not have a life outside of coding.
But certain people believe that in order to be a good coder, one of your hobbies MUST be coding.
Hair dressers don't have this problem, they are actually cutting hair 8 hours a day.
Carpenters have a more hands on education compared to compsci which is more maths than version control.
Doctors require 2 years of practice supervised by other doctors before they are certified.
I don't understand how you equate doing side code projects to not bringing clear focused mind to the office.
Would you also much rather bring a well rounded individual who does not take art classes after work? Do you think taking arts classes after work would affect one's ability to focus in the office?
Then why do you make similar assumptions about doing side code projects? For many of us, doing side code project is like taking art classes. It is art for us and it helps us learn new things about the art of software development that is not always easy to learn in the constraints of real world software business. Most importantly, it is a relaxing and enjoyable experience. It refreshes our soul and combined with a good night's sleep, it helps us to better focus next day at work, not the other way around.
Are you saying that you would much rather not hire people like us who care about the art of software development because from your high horse, we don't look like "well rounded" individuals? If you hold this kind of irrational conservative beliefs, I'd much rather not work for you.
I don't think it's wrong to work on side project. Some people like or want to. Who am I to judge what they do on their free time? It might happen to overlap with their job, or it might not.
But I agree, I don't require my surgeon to do surgery in his spare time. I've worked with plenty of great engineers who wanted to leave work at work, and after 40 hours of engineering, enough was enough and spent their free time doing something that wasn't engineering. I've also worked with people who did side projects, and were equally amazing.
I don't expect a brain surgeon to mess with somebody's head because he's bored at weekend, though :p
This is a huge problem in the industry and is the source of massive waste.
What makes software engineering different from surgery is that when a surgeon learns something new, he does not have a live patient at his home to practice the new thing he has learnt, but as software engineers, most of the times we can immediately fire up an editor and write a PoC or a toy project to practice the new thing we have learnt.
Its strange that such natural and obvious curiosity and desire to try something out outside of work deserves the kind of criticism that it is receiving in the original article and some of the comments here.
The critic points out that it is no longer curiosity which drives you when people expect you to do it.
I do not get this obsession with putting everything out there. I have a huge local directory with my old test programs, PoCs, started but abandoned ideas, etc. I regularly try new stuff, new libraries, programming languages, what have you. But my github account is empty.
The internet needs less stuff on it, not more.
It's not obsession. It's just a matter of convenience. git add; git commit; git push; and all my experimental code is safe on someone else's server that is managed much better than I can manage my set of USB drives and hard disks.
> The internet needs less stuff on it, not more.
I disagree!
What I do after the office hours is really none of your business. I should be able to do whatever I please (write code, play guitar, etc.) after office hours without you raising concerns about it.
If you believe I do not bring my clear focused mind to the office, then that is a separate issue to be discussed separately without bringing in what I do after office hours into the discussion. It is my prerogative, not yours, to decide if I need to give up what I am doing after office hours in order to focus better at office.
Some of the things you can learn outside of this field are what overtraining is (actually not that different from the AI concept), perspective on the learning and teaching process, the importance of preparation and good tools, patience with new ideas, and the dangers of trying to rush through the learning process.
I bet that even people who have spend 20 years on side projects haven't reached those 10K hours of practice yet.
Roughly 220 work days a year, 5 hours a day at work if you are full time, 6 if you dabble a bit outside of office hours, that’s around 5 years out of school, which isn’t too far off from my experiences prior to Malcolm Gladwell.
When I'm building some CRUD interface for my job, there's nothing I'm practicing with that. When I spend my entire day doing that, I've gained 0 relevant hours for Malcom's 10K.
Some jobs are easier to do on the side than others. I'll bet the gardener has some side projects too.
If you were looking for a drummer for a band, you would want to hear him play.
The latter one, sure. Makes me wonder if we should call interviews as auditions.
Nice! Agree with that.
I've hired plenty of great engineers who didn't have side projects on github. I have never specifically been looking for people that don't have a life outside the field, and unlike GP I have found that there are other ways to evaluate people that can identify great engineers with very few mistakes.
But that doesn't mean I wouldn't see your high quality or impressive open source code as a huge plus. Quantity doesn't matter -- if anything if you're super prolific I might wonder if you have much energy for your day job -- but I'm not going to pass up a chance to see what kind of work you do.
And because quantity doesn't matter, I think that writing a little bit of code "for your resume" (every once in a while, to reflect your continuing development as an engineer) is a pretty reasonable investment even if you don't happen to want to spend your whole life outside work programming. It's not required, but it might get you a really great position some day, even if like the OP you're up front about having a life outside of software engineering.
It's all good, it wasn't the role for me, I'm more creative dev than programmer and I didn't get a good impression of the company anyway. I've moved on.
I wrote most of the 'fizzbuzz' function but couldn't remember the "%" operator. Tests are annoying because it's not how developers work, at least I don't work that way, without any way to verify syntax or look anything up.
I recall an interview from years ago where I was asked to show the code behind my websites and step through it explaining what it did and why I did it. This is better than a test, because you're explaining how the code works and also showing off your work.
Later I moved that project to a github-organization, as it didn't need to be tied solely to me, and I wanted to allow others to commit, etc.
I'm not sure if the SPAM-mails went away because recruiters stopped scanning github for profiles, or because there was no obvious link between that particular project and my personal email.
Granted, this has been for gigs (or temp-to-perm) situations, not official, up-front fulltime roles. And some of these people ended up being flakey or sketchy (as spontaneous / whimsical people sometimes are). But nonetheless, hired (or substantially fast-tracked into their process, bypassing most of the usual interview crap) - pretty much on the basis of single demo or code sample (or in one case, literally on the basis of a single stats plot).
Because by this point, pretty much everyone knows how silly those live fizzbuzz sesions are anyway - including those administering them.
I guess that isn't the idea here. I think the idea is for them to grab a dev from the next cubicle/floor, point them to the repo, ask "can he code?", and the dev says "sure looks like code to me, yeah."
"Showing up" is 90% of every move. Sure, the guy who copy-pasted something together could get the job that more talented dude who was too timid to share their stuff would be much more suitable for, but such are the trade-offs here.
In my experience, it is employers signaling how cool they are before they ask you to do their multi-hour coding test for no money.
Where do all of you keep finding those companies? Is that an SV thing, or am I just not applying to "prestigious" enough companies? I've been on my fair share of interviews and haven't had that happen once, along with no whiteboard interviews. I can echo your experience about Github projects playing a small role apart from signaling though. Once, an interviewer mentioned one of the Github projects I worked on and we exchanged 2-3 sentences about it, but I don't think it had a significant impact on the result of the interview.
As a rule, I don't and have never consented to them because I find them exploitative.
- Long home coding challenge (for no pay of course) - Hours of whiteboard coding talk. If you're lucky it relates to the job at hand, most of the time it doesn't - Doing coding tests online, either through their propitiatory app or through sites like HackerRank. - A conversation type interview, where you talk about the job (have only had this one in my recent attempt. Didn't get past that phase)
Of the roughly 30 interviews that I've done in the last ten weeks, only one place ever asked about my github profile (which I don't have yet, currently revamping it since most of the code was years old and pretty meh). Almost every one of them had questions about my linkedin profile though.
There is a way to do this. But some people go a little too far.
Last years one start up asked me to write an entire backend application for them for free.
That they declared bankruptcy this year has been a tasty bit of schadenfreude.
Nothing to do with prestige, it's a simple "will this monkey jump through hoops" test to see if you'll work in shitty conditions for shitty pay.
My go to response is asking them to look at my git instead, which ends the process in about half the cases. The other half they look at it for <5 minutes and point out the error that isn't an error (yes I know what an SQL injection is, and I've taken steps to make sure it won't be an issue).
I'm not sure where I'd put the comment, since in the part where router paths are set up, it's self-documenting/obvious that it isn't an issue, and if the person skips that and looks at individual functions only, then I'd have to put it in too many places.
Another option is to create a function like _escape_numeric_string that returns its input after asserting the string is numeric and has a comment explaining, and use it everywhere. Although yes, that does mean changing all your individual functions.
Generally if a code reviewer suggests a change it is worth documenting why the change isn't practical. That can be adding a test or adding a comment.
Anecdote time! I had a potential employer ask me to do the tutorial for their framework before the interview. I submitted a pull request to fix errors in their documentation during the interview. I got the offer but didn't wind up taking it. I don't do those types of things anymore because it's more beneficial to them than it is to me. I could see the value in doing it if I was a junior dev trying to get my foot in the door though.
They are not that successful, a few dozens stars generally for the most serious ones. And also, there are not especially trendy (no fancy react app or js library, but stuff in python (lib, web ui), C, a puppet module, some shell scripts and little bit of perl).
With that, in 5 years, I was contacted only by 2 or 3 recruiters/contacts that emailed me because of my projects. For two of them, it was more a general look at which languages I used in my projects ("hey, this guy knows Python and Bash, he may be good for an SRE position").
The last one actually came across one of my project which is a little bit domain specific (an RFC 3161 timestamp server), not sure if it would have ended in a recruitment offer however.
I get more offers through my crappy linkedin profile.
This - the non-portable aspect - is what irks me the most.
Especially for enterprise developers. Since most of the software we develop is under NDA, we cannot put any of it online to showcase our skills.
I've had to do 3 different take-home "coding exercises" over the last 10 days. 1 was for a Hedge Fund, another for a Real Estate company and a 3rd for an Accounting SaaS company.
I'm in the process of publishing these coding exercise solutions after polishing it up a bit more onto my github profile. Still, I feel like this will also be a waste, because like OP says, most companies have their own specific "Coding tests" and wouldn't take an already coded solution to accept skills and experience of the candidate.
Would you expect a musician to practice their instrument in their free time or only play their instrument during paid gigs?
I've had too many "tests" that were a giant waste of my time to ask it of others.
Good employers care. I care. Its not signaling. Its important.
It's not important. There are plenty of good companies who don't do these things that manage to pay developers $100k salaries. They may assess in other ways, but it's not the only signal.
It's only important to you. You choose what you want to see in candidates. You need buy-in from the candidates that your process is conducive to a good environment, good code, and good delivery. In turn, you cultivate a team who share something in common, and the team gets along well and makes good code.
It's people finding like-minded people -- the same social movements that are in every other profession. There's nothing wrong with it, but there's currently no prevailing right or wrong way to do it, otherwise that would be the technical interview.
Practically, development is still in demand. So if I get rejected, I can go apply some place else. That's why it's not important.
Maybe your pay is slightly above those other companies, but is a marginal pay increase really worth all of the extra effort? That's up to the developer. But the employers that don't use this criteria are not non-good employers.
Worst company I worked (work) for (but pays well) had me answer a few questions on a whiteboard. One of which was 'not even wrong' (the answer was: "HTML5 gave us the <strong> tag to replace <b>").
They were desperate for bodies after a bunch of people left. They also partake in the usual H1B/contractor games and wonder why they have shit code. Meh, my project is going well. If they have me work on their main .NET monstrosity though, I'll quit. Haha, jokes on them.
i bet the question was: "what has HTML5 done for us?"
I said, "CSS, but it doesn't have much to do with HTML5's features."
The interviewer has checked the "codes in his spare time" checkbox" and I've guilt tripped them into skipping the dance like a monkey test once or twice by pointing them at my github but that's about it.
I'd be super impressed if a prospective employer looked and made some sort of salient comment, but it's never happened and probably won't.
One question I have for the grandparent post: what would a meaningful question be? Is the description I mention above seem like a meaningful way to discuss the work you took the time to share with me?
It's pretty useful for screening candidates, especially looking at code written <1 year ago. I do keep in mind that code written in free time might not have the same standards as production code, but often there are some red flags that carry over.
Besides, you are only using this as a negative ? So you'll actually hire people who don't put in extra effort over people who put slightly substandard free time code online ? That seems like a losing strategy.
I've always found that willingness to put in effort vastly outperforms ability. Not to an infinite extent, but quite a bit.
If someone knows that much git, I'd hire them regardless. I'm so sick of untangling other peoples failed merges or trying to explain what the "not a fast-forward" issue means when their push fails.
It is fair to expect a developer to invest sometime in learning their tools well but git is a different beast. I know it solves a very complex problem but the fact that it exposes a complex interface to the user to do so seems like a shortcoming of the tool to me.
Heck, we even have a comic for it that shows how sometimes just saving my work, deleting my clone, re-cloning the repo and applying the changes in my work is easier than understanding the Git error messages: https://xkcd.com/1597/.
The tooltip in the comic is also sound advice: If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
Compared to something like Rails, iOS development, or React + Redux + Redux Saga, Git is just a couple of commands and basic concepts. Everything is listed here, and I don't think that's an unreasonable number of commands to know: https://git-scm.com/docs
Either Git has a complex user interface like I claim or I am beginning to grow old.
I disagree. Like everyone, I've experienced a failed merge that turns into a diff nightmare. However, when it has happened I've figured out how to solve it myself instead of wasting someone else's time with it, and it hasn't happened in years now leading me to believe it is directly correlated with git skill-level.
Same for regular expressions. Once you know the syntax, they're pretty easy to understand. It just takes practice.
Yea, but why would someone bother in this case?
>Besides, you are only using this as a negative ? So you'll actually hire people who don't put in extra effort over people who put slightly substandard free time code online ? That seems like a losing strategy.
That's not what I said at all. It's potentially a positive or a negative, just like anything else on a resume. I've seen plenty of Github profiles that have files with 2000 lines of spaghetti code and no structure or testability. Just like I've seen profiles with neat projects and excellent code.
>I've always found that willingness to put in effort vastly outperforms ability. Not to an infinite extent, but quite a bit.
I agree with this in general too.
As for why I don't take Github profiles too seriously, we had plenty of applicants who did have projects on their Github profiles who tripped all over themselves on our simple coding test. Maybe we would have found out something similar by digging into their commit history, but that would be an even greater time investment than the hiring process already was.
It's still useful to have material for non tech people, though. That's why, additionally to my github profile, I maintain an angelList profile on which I document the why's and how's of my projects from a non developer perspective.
But of course, the single most important thing you can do in an interview with a non tech guy is to show them you understand their business, what they're trying to achieve, and that you find it exciting (provided it's true, obviously). From having been on the hiring side, I've learned that the worst thing to say is : "yeah, actually it doesn't really matter what we will do, I'm mostly interested in coding".
If you have projects that you're proud of — mention them on your website, on your Twitter's bio, on your LinkedIn profile, mention them everywhere. Even better, once per year go to a conference and talk about those projects in front of an audience, such that you can then have videos on YouTube too.
We like building things and there's absolutely no shame in marketing ourselves or in talking about the things we've built.
Employers do not care. Other people? Sure. Employers? No.
You just have to know your real market value, how good are you compared to others.
Github was used in this hiring process to reveal a fraud - a different 'success' story to others commenting here, but it definitely birthed 'a meaningful question' or two.
Another time I rejected due to side work was a candidate claimed to have written the "worlds fastest framework". Even if it was fast it's possible there's something out there faster, so it showed lack of touch with reality, ego, and lack of self awareness. Note I gave the candidate the chance to substantiate their claims and was met with profanity
feel like they'll fit right in with any number of startups out there! But good for you on calling them on it.
Employers don't care. Employers say they care, but it's signaling. If I didn't write code on my own because I like it, it would be a serious negative to do so on the off chance that you run into the black-swan employer who takes the question seriously.