I made the mistake of thinking an active github account was a good proxy for "Is this person interested in tech enough to work here?". I was called out on it at a conference (fortunately for me at a bar and not when I was on stage), by someone who pointed out that many people just don't have time to work on side projects and push them to Github.
Maybe they work 8 hours a day on a bank or government project that is all private and then they spend the rest of the day acting as a care giver to a relative, studying, or volunteering in a women's refuge. All noble activities that I would consider positives for a candidate, but I'd never know if I just checked "Do you go home and cut code out of hours?".
I mistook my own privilege of free time as a universal truth and I'm glad I was called out on it early on and able to change my (interviewing/screening) ways. I wonder what else I need someone to call me out on...
In my case, I have found trying to contribute to open source to be a huge waste of time.
For example, I once found and patched a bug in paperclip, explained why it happened and sent a PR. It was ignored for 5 years and then they abandoned the project.
Or I once fixed Heroku issues by upgrading the ImageMagick version with a custom build pack. They featured it somewhere and suddenly I was getting entitled emails every day by random strangers who strongly felt that I should fix their Heroku deployment.
Then there's the issue of dependencies. My cool tool for analysing satellite photos won't be of much use to anyone who doesn't have API access to a satellite ground station. I.e. there's no benefit in making it open source.
And lastly, I've had the unpleasant experience of a company taking my open source project, adding copy protection and then selling it as theirs while simultaneously refusing to adhere to my license of either following GPL or paying for closed source use.
Nowadays, I only share source code for hobby projects with friends, but not publicly. Otherwise it's more work and less pleasant for me.
> In my case, I have found trying to contribute to open source to be a huge waste of time.
You mentioned the full extent of your attempt at contributing to open source consisted of a grand total of two meager pull requests.
I'm sorry to say but if throughout all those years you only managed to put together two patches then quite obviously you did close to zero contributions, both in absolute and in relative terms.
In fact, it seems you complain more about floss than actually contribute stuff.
I find that I general it's terribly easy to get your pull requests accepted to random FLOSS projects. Whether your PR is janitorial work, fixing bugs or adding features, you don't need much work to get your contribution in. So, quite frankly it sounds like you are grossly exaggerating and overstating not only the extents of your work but also the challenges you supposedly face.
> Then there's the issue of dependencies. My cool tool for analysing satellite photos won't be of much use to anyone who doesn't have API access to a satellite ground station.
In that case your so called cool tool to analyse satellite photos sounds very poorly designed. I mean, the whole FLOSS earth observation stack is designed literally from the ground up with extensive separation of concerns in mind (see GDAL and proj4 and orpheo toolbox for example) and apparently somehow you failed to learn the lesson that everyone doing professional, academic, and even amateur work knows by heart.
I'm happy to report that of course I sent in much more PRs and some even got accepted, but I highlighted one that didn't as an example of why it feels like a waste of time.
Similarly, I've had unpleasant experiences with entitled users more than once, I just picked the Heroku buildpack randomly.
As for the satellite tool, open tools will only take you so far. I do use GDAL, for example. But when you need to take photos on demand, you need very precise real-time trajectory and weather data, for which there is no free equivalent. Plus you actually need to send your photo request somewhere. And that's when you become dependent on an NDA-ed proprietary API.
There's good open source tools if you want to do offline analysis of static archive images. But not everyone has such relaxed requirements for refresh period and processing latency.
Consider using satellite photos to analyze traffic. You schedule photos with a proprietary API, use proprietary modules to download them, followed by proprietary file format converters. And then there's a block of image processing that I could open source, but that won't be helpful without the data acquisition and conversion pipeline. But actually it's a TensorFlow AI trained on proprietary data, so even releasing that is a legal nightmare. The whole project is commercially tainted from start to finish.
This is one of the most fascinating things about the internet. If someone were to read this incredibly extreme and atypical experience of sending in two(!) pull requests, they would think they'd be better off getting punched in the face than to send in a fix they made.
Opensource is enormous at this point. One data point(or even 30!) is no longer particularly relevant. Instead think of it like any endeavor in life. You are taking a leap of faith. Sometimes you'll have a great experience that may even blossom into greater things you never expected. Sometimes you'll be let down despite your best efforts and intentions.
I'm a bit surprised that you thought I only tried sending two pull requests. Those were just examples. I'm pretty sure I submitted 50+ by now, and a few were even accepted, but overall my conclusion is that it wasn't worth my time.
are you the only person on this planet with access to a satelite ground station?
niche projects that can only be used by a small group of people still benefit from open collaboration that FOSS enables.
also, i might patch your code to work without that ground station on publicly available satellite image data.
that last example is clearly a copyright violation. you should have legal means to go after them. i realize that is not trivial and may cost you a lot of effort, and while i would love to say there is help available i can't right now point you to one.
is there an organization that helps any FOSS project (not just their own) with license violations?
I'm the person who signed the NDA that I will not disclose the secret proprietary API for that ground station, so while others might substitute their own API, I would have to deliver things as a broken non-compilable project, which is sure to raise questions.
And yes, I did eventually succeed in resolving the copyright violation. But it was still a lot of work for me which I could have avoided entirely by keeping my source code secret.
I disagree that these examples are a waste of time. In all cases you benefit from having created the code to address your own use case, but perhaps don't see further direct benefit from sharing your work.
Submitting a PR allows others in the community to apply your patch (or incorporate into a forked version of the project) if the PR doesn't get merged or deleted. From a project maintainer's point of view, significant patches can be difficult to test & review, and merging a PR implies accepting the long term maintenance of those changes. I've left some promising PRs for much longer than I'd prefer to because of factors like time to review and the risk of merging code which may not have adequate tests. If an open PR attracts some community interest or discussion, that can give project contributors a helpful signal for prioritising.
If a PR is featured somewhere, this can be an opportunity to raise your profile and perhaps introduce those inquiring users to something you can benefit from more directly. If I get direct emails about a PR or project I contribute to, I try to politely point those users to the right channel (eg raise a GitHub issue) and ideally a contributor guide so they can be empowered to contribute directly. This may not be a straightforward reflex to develop, but I think responding with "This is a volunteer effort -- here's how you can help with docs, testing, or code" is a better viewpoint than "Ugh, more entitled users". I've been pleasantly surprised to see this approach turn some agitators into useful contributors.
If a project has very niche dependencies (like requiring API access to a satellite ground station), there can still be an audience and they may be even more motivated to collaborate on your open source project. I feel like this may have the best upside in terms of potential ratio of users to collaborators.
I think your last example is the most challenging. If you are concerned about someone else benefiting by stealing or repackaging a project you have openly shared, it would be best to keep that effort private. Compliance with open source licenses (or the spirit of open collaboration) requires ethics that are not universal across developers, companies, and countries. This problem isn't unique to open source (commercial licenses also don't prevent piracy), but is a harder blow when you are personally affected.
Notably the first. You fixed a bug, you contributed, you did your part but it was ignored. Did you learn anything from that? Beyond "Open Source is a waste of time" I guess?
It's easy to look at things negatively, but there's often positives to be found if you simply look for them. Not to say you're wrong, just, trying to offer some perspective.
I do not use GitHub because their political views do not align with mine. And what does politics have to do with programming? I do not know, you have to ask them, they are the ones trying to bring politics into IT.
I just self-host Gogs, GitLab, Trac, cgit, etc. They are independent of each other, of course. :) Different teams, different needs. As far as my personal projects go, I just self-host cgit, and I accept "pull requests" through e-mail. It works.
Thank you! You are right, I should. I will not mention this any more, just this one last time: I honestly just have no clue why politics is so pervasive, and I would like it if people did not read too much into it, and I would like to think that it does not say anything about my political views. :D
I tend to not share my political views anywhere, especially not on Twitter. I do not even own a Twitter account! If I express my beliefs, it is under a pseudonym. Sometimes I even argue in favor of something with what I disagree only to learn more.
you wrote about keeping politics out of work and that cost you job opportunities?
could you elaborate?
a place that forces me to get involved in political arguments or where partisan politics influences business decisions or the company openly favors a particular party such that all employees are assumed to support that choice, is not a place where i want to work.
The idea of companies caring about politics is usually followed quite closely by corruption in most cultures.
By all means, they can care about politics- but they cant force me to care about their politics and they should not be as reactionary as they are when I take my business elsewhere.
I am just a dude who likes computers. I don’t need to shoulder problems from half a world away on behalf of billion-dollar corporations.
Last year I was phone screened by a manager in a e-commerce shop from LA while I was living in Chicago. They seemed to be too fixated on my Github contributions. This was not a startup trying to accelerate- it's merely an agency that sees modest growth with a modest volume of clients.
Don't know what they though that my involvement in open-source projects would correlate well to e-commerce CMS work (I've worked in e-commerce dev well before opening a Github account). But it's probably some weird "tie breaker" decision given that I am not local to LA.
> What many fail to understand is that disinterest in Github absolutely does not tell you anything meaningful about that programmer.
Well, it does. It says he doesn't have a portfolio for some reason. Is it because he is incompetent and has nothing to show for? Perhaps not, but if the candidate makes it difficult for recruiters and interviewers to get an objective way to corroborate his claims regarding his level of expertise then just for the sake of avoiding wasting your time with yet another paper tiger... It would be better to cut him out of the shortlist for further interviews.
>> Well, it does. It says he doesn't have a portfolio for some reason.
No, you do not have to have a "reason" for not having a public portfolio. Not having a public portfolio doesn't say anything at all about someone's competence.
>> if the candidate makes it difficult for recruiters and interviewers to get an objective way to corroborate his claims regarding his level of expertise
Public code is not the only way to assess skills, indeed as I mentioned elsewhere in this thread its actually a pretty bad way to assess skills. If the best tools you have for assessing competence is github then your recruiting process is lacking.
>> It would be better to cut him out of the shortlist for further interviews.
I can imagine employers with this attitude lamenting how hard it is to find good people.
What bothers me so much is that my work is supposed to be my hobby. After programming for 8 hours a day, I go home and do something else, I have no interested in programming once I'm done working.
Some companies I've interviewed with claim that I'm just not enthusiastic about programming, or that I'm not motivated enough, simply because I don't do any programming at home. They also questioned how I could learn new things. And my answer is usually the same; if they expect someone that wants to program 24/7, then I'm definitely not the right person. I have other hobbies I'm interested in, and I have no desire to burn out. I also expect to be given the time to keep up with new tech on the job.
Not to mention this signal is easily gamed. I know many people who light up their Github activity graph with one line commits to READMEs or codestyle changes somewhere.
git commits have two dates, an author date and a committer date; the github profile page thingy is based on the author date of commits. just set it to whatever
I work for a bank and I have contributions to the python project and a multitude of projects on Github.
Yes those things I did took a lot of time but I typically do it out of boredom . To be honest my GitHub projects are demos and I just like giving presentations .
If you compare yourself or anyone on any given metric you will feel bad. What is even worse is when people tell you all the time about a metric that you should do but once you do it you find that it wasn’t necessary at all and it’s some kind of mental gatekeeping.
The point isn't that the hypothetical banker can't have an active github profile, it's that there are reasons they might not.
Take me for instance, I haven't really done anything significant in the public for over a decade now. The vast majority of my code has been for one private company or another.
And that's the case because either my job has me working the hours or after putting in 8 to 10 hours of code in private, there's exercising, practicing guitar, socializing with friends and family, building Lego sets, reading, playing video games, and other activities that don't involve me writing more code.
That's not to say I don't, it's just I don't have that much time to do it outside of work.
Cool story. I have a kid and all our work commits are to a private Atlassian Bitbucket repo, so the only commits from me on GitHub are my dotfiles, once in a blue moon.
I've been coding since 1995 and my open source contributions tailed off around 2002 or so. Wasn't how I wanted to invest my spare time.
As noted I was using examples. I wasn't saying everyone who works for a bank can't commit code to GitHub, just that in the grand scheme of things it's more likely.
I just spent the past 4 years getting an MBA, my github repos are all horribly out of date because I had more important things to do. It doesn't mean I'm any less passionate about the technology.
I will still think odd that’s someone who is a professional hasn’t found one bug in an open source lib that is worth a PR or even an issue in a decade of work.
I don't know about a decade, but what percentage of people with >10 years of coding experience do you believe have submitted a public PR for an open source library?
Based on the people I've worked with (both great and mediocre programmers), I think that is highly uncommon.
Very true. I can't sadly think of a single instance where any of my colleagues in the last ten years would've contributed a bugfix upstream. It would always be a workaround or creating a local copy of the code in question to customize it.
Most software engineers will be on a commercial contract that doesn't allow contributing to open source projects. Even if you issued a PR or raised an issue, it would have to be on a throw away account and you wouldn't include it in a CV.
There are also a lot of software developer's that have contracts where they can contribute to open source but it has to go through legal. Which makes it to much of a pain to actually be worth doing.
And if they did, what value do you derive from it? Fixing a small logic error or one-off error gives you about as many data points about someone as them having absolutely nothing on github.
That they care enough to give back a little? Even from a pure selfish perspective, I would still open a PR or an issue to double check that my logic is sound.
> I will still think odd that’s someone who is a professional hasn’t found one bug in an open source lib that is worth a PR or even an issue in a decade of work.
It seems like the person is surprised how nobody has any contributions from just their professional work. Naturally unless I had no life outside of programming I would spend the vast majority of my time doing my 9-5 stuff.
In NA, it's common for software dev. employment contracts to prevent you from working on software in your own time, and/or to claim moral rights to anything you do work on, regardless of field or business interest overlap.
I have no idea about enforcement, and most coworkers I've had have ignored those clauses.
Not allowed everywhere. Any code I write ay any point of time is owned by my employer legally and in an EU country. This is because I work at a large consulting company that touches on any and all business fields.
Free Github private repos has been a blessing for just storing modifications to existing projects.
I've not heard of that before - is that a legal employment restriction. Not that it necessarily has to be to stop people, of course.
I'm going to guess you're in USA, is it legal to stop phone workers using the phone outside work. Seems like not allowing people to work on things directly related to their actual work (due to IPR claims by the employer) would be a thing, but no OSS at all?
I’m a decent developer. I’ve shipped code, led projects, and worked at scale. My employer owns everything I code. I’m not supposed to, legally, even write code during an interview if I’m looking for another job as they own it. I can contribute or create open source but everything must be approved by my org first. For many, that hurdle alone is too big to justify working on open source. I got a talking to for contribution to documentation on a Go project out of Facebook without proper paperwork being done and “exposing risk to my employer.”
I thought we were talking about contributions at work? I find bugs in OSS libraries from working 8 hours a day on software (including in glibc and python).
My last company did have a policy that you are prohibited from participating in OSS, unless getting a bunch of approvals per project or per patch. I'm risking my job sending a PR.
It's work related, it should be fixed at work. (I certainly don't want to patch things in my spare time because the company forbids me to work at work).
I did find a bug in svelte but not sure if it was worth a PR. I cloned their repo, tracked down the issue, learned how their codebase worked, fixed it, wrote some tests for it, wrote an elaborate issue and pull request explaining the issue and nuances. It took around 4-5 hours over a couple of days even though the fix was a one line diff. The PR was ignored for 6 months. I was considering bumping it but then I read in another PR that it's bad manners and just decided to remove it instead.
This. I give people lots of room, I don’t even care if it’s in an ancient sourceforge repo, I still like seeing this kind of professional exploration and participation in new hires(like since 2010 at least). Not a requirement but a curious absence for me that suggests a more deeper interview is worth having.
I have worked in software engineering for over 15 years, and I have never contributed to open source as my employment contracts never allowed this. According to my contract, and this is typical for many commercial companies, any code I write is owned by my company, even if I would write it in my own time. If I would contribute to an open source project, there would be legal implications for both me and the open source project maintainer.
I hear you, and it’s why I also only consider it a curious marker and not a detractor. Nowhere did I say I wouldn’t employ someone, only that it sparks more curiosity in me.
Let's be clear - it's OK to write shit code. There are many many contexts in which writing shit code is perfectly valid. Indeed there are times when writing shit code is almost a requirement. You're experimenting, you're researching, you're learning, you're having fun, you're in the initial build stages of something, you're under time constraints.
And lots of code should not have tests, or be works of art, or be bug free, or be commented, or be comprehensible to less experienced developers.
It's a problem that Github is used for assessing programming skills at all because those assessments ALWAYS look for consistent perfect code as a high arts with full code coverage etc etc.
Public code also has time context - maybe you wrote that four years ago when you were new at some technology or skill - what exactly does that mean to the assessor who is seeking perfection?
I don't want to direct anyone to my code as an assessment because it's always misread by the assessor. Even worse I find myself rethinking posting code online because I think "but what if I get assessed on this will it hurt my career"?
I think that analysis of people's public/Github code is a hiring antipattern and the fallback of those unskilled in assessing candidates.
When interviewing someone I will try to track down their GitHub profile, and having some decent code on their is probably going to make me more inclined to hire you since it gives me a data point on how you work. However for all the reasons listed in this article I’m just going to disregard the lack of a profile or a profile with limited content, I’m trying to hire a professional software developer to do work here, and whether or not your hobby is running a large open source project doesn’t really influence how good you are at your day job.
I had an interesting interview a few months back, the interviewers said "Please pick a smallish repository and walk us through the design and implementation".
I talked for nearly an hour about one of my projects, first of all the broad design, then various interesting aspects of the implementation. (Most projects have lots of "dull"/"boring" code, but I certainly highlighted the areas I had the most fun/pleasure/difficulty implementing.)
Was a nice interview, although it was only possible because I've posted a whole bunch of projects online. I know other people keep their stuff private, or don't even write code in their spare times.
I've interviewed people who don't have public repositories so instead I'll ask them to bring some code with them that they can talk about. It could be a school project, it could be a single function or an entire system. For me, the exercise is mostly about evaluating communication skills.
I mean, I can't bring my work code with me, because NDA. I might not have side projects because life, and school was a long time ago --- actually, I don't know if I even have that code, most of it I archived on the school shell server and they kicked me off around 10 years after I graduated.
Also, my side project code is garbage, because only I am going to look at it, and so it only needs to make sense to me (and maybe, future me), and it's more fun to write awful things.
I'm sure this gets you good insights on some candidates, and probably is pretty decent for fresh grads (who should have something from school), but I can't imagine it working well for a lot of experienced candidates.
Hearing why your side project code is garbage is useful too. The code itself is rarely very interesting. It's all about hearing you describe what's interesting (for positive or negative reasons) and to see how you answer questions or challenges.
Same. For me, a great github profile with repos and contributions may add to someone’s prospects when it comes to getting a first round interview. An empty profile or half baked commits? I will completely ignore it.
However, if I see someone engaging in an issue or PR discussion in a way that would make me nervous about having that person in my team’s slack channel, I am much more likely to pass on them.
>whether or not your hobby is running a large open source project doesn’t really influence how good you are at your day job.
I got a ton of useful experience doing open source that aided me in my day job. Experience building abstractions and DSLs, building frameworks, and testing stuff really effectively are all examples.
There's a kind of common thread with all of these things in that in my day job I didn't really practice and hone my skills in these areas because of the constant churn of work that the business wanted done. The incentive structure of corporate development encourages a kind of frantic slap-dash "just get it good enough and get it out there" approach while open source is much more relaxed and pensive and thoughtful and elegance is valued much more highly (sometimes too much).
There is valuable experience to be gained from both environments - I wouldn't say either one is really ideal. Open source, for instance, doesn't put the same emphasis on customer feedback that business does and often takes too long to develop new stuff.
Do you actually scroll through and asses the code quality though? The only thing I can tell at a glance is "they bothered to clean this up and document it" which is one useful sign.
The more useful signal for me is GitHub as a portfolio piece, if they got some concrete relevant work done that I can ask them about in the interview but I don't need to see the source code for that.
I give it a quick skim, unless it’s something that interests me on a deeper level than “this is just some code”. It’s essentially a somewhat deeper fizzbuzz test, if someone has half decent code which shows baseline knowledge I’ll skip doing a screening test.
I don't see why everything has to be bucketed into 'good' vs. 'bad'.
A well-populated GitHub profile can be a positive signal to me. It makes it easier for me to see how a prospective candidate works and thinks, and provides me with a more useful and instructive set of questions to ask during an interview.
It is also possible that I will discover that the candidate is not sufficiently experienced to meet the requirements of the position that they are applying for, but at least this way I don't have to try to ferret out these answers or waste their time.
An unpopulated GitHub profile is a neutral signal for me, and means that I need to spend more time trying to tease out the answers that are simply given to me with a well-populated profile.
> It makes it easier for me to see how a prospective candidate works and thinks
Be careful making even these assumptions. My GitHub is a subset of my side projects combined with some old work stuff that was reprioritized. Many of my repos lack tests because they're for such a small number of users it's more efficient just to test manually and handle issues personally. That doesn't mean I don't write tests in my professional life. Similarly, many projects may be older and my habits have evolved since then.
A says: “I like it when a candidate has a github, because it gives me and idea about how they code”
B replies: “please don’t. My github code, like an unknown proportion of all github profiles, is hobby code and doesn’t follow any of the standards my professional code follows.”
In this case, you need a prior that says “even if it looks legitimate, the data might be completely invalid and we cannot tell from the data”
In a competitive scenario, like multiple people applying to only one open position, a “neutral” signal versus a positive signal is effectively a negative signal.
No. It's not. It's a neutral signal. It can't tell you anything either way.
Even the github profile isn't a strong positive signal, it's a weak signal. But that's ok. That's really what we're looking for: a lot of weak positive signals.
So that person had a github profile. Everything else could either be a neutral or negative signal. Compare that with someone without a github, but has every other positive signal you could ask for. I'd take non-github person over github person every single time.
First thing I do when a resume crosses my desk (as a hiring manager) is check their GitHub (or GitLab) profile, if they supply one. It is an important weapon in our arsenal for helping determine which hire from a shortlist gets called in for interviews. Just having an empty profile is better than no profile, but one with repos of your work is best and worth extra points. It has made the difference in our hiring decisions.
Unfortunately for me, I came from a world where everything had to be open source, but moved to a closed source world where everything I produce, even in my private time, belongs to The Company. IP lawyers have to check the bowl before I flush. I am paranoid that my public commit log being empty will affect my chances of getting a job in the FLOSS realm once again.
If you are going to use public commit profiles as part of your screening process and hiring decisions, I would encourage you to ask candidates what aspects of their public activity are relevant. For example, ask for a few specific highlights and why the candidate thinks those are interesting.
Hobby projects and open source contributions are evidence of patterns of collaboration and commits, but may not be indicative of one's typical (or best) work. There are also many reasons why a great software engineer may not have a public activity profile.
The majority of my public commits are scratching itches on open source projects, and are very opportunistic depending on other life and work commitments at the time. Code may not always be pristine, but I can probably rationalise why I took a certain approach (following existing code style, hacking for my own use, actually aiming for quality and performance, ...).
As a hiring manager, I'm also OK if candidates want to do something with their personal time that doesn't involve committing to public repos :).
I also have a contract like that. They don't sue you, but everything I produce is intellectual property of my employer.
Not very useful when working on open source, which is why I don't.
I argued about this before signing, but this has been in every contract I have ever read and when I argue about this they will always say it is standard practice to include.
And people just as surprised as you are are designing interview pipelines for their companies. They seem to not know they are asking lots of potential candidates to literally break contracts for the privilege to interview.
Lets face it, recruiters do a terrible job of screening. They dont understand the job, so how could they ever detect the tells of in group / out group?
Plus, you can generate activity for your profile. It's a game of cat and mouse.
Honestly, I think the biggest problem is our own expectations. The way IT recruitment is just now, is not substainable and makes little sense.
* There are more developer jobs than developers
* We're constantly afraid of developers who can't code
* We decide to test every developer often with non-real-world scenarios and weird things they'll never do in their job and if they did do, you would be very concerned.
* Not only do we test them for things things they won't be doing, we also expect them to spend hours and sometimes days doing these tests.
* We reject people for weird random reasons. They don't understand one concept correctly, so clearly they can't do the job ever.
* We then hire recruiters, who realise how screwed out recruiting is and that it's often potluck. And realise this is a basic funnel, so they go and search out anyone who has a rough chance of doing being able job.
* We then blame the recruiters because people don't meet our weird standards.
For real, most companies need to realise they are not FAANG. They do not have an endless source of people wanting to work for them because of the reputation. Many of these companies that are acting like they can expect people to jump through hoop and hoop, have employee churn rates of 6-12 months and are competing with many other companies in their local area for the same talent. We continually act like like doing this job always requires the best. From what I see at most companies, you need one or two people who can archectect your system and explain the designs to people and after that you just need people who can follow the designs. We can say "But everyone should be able to do archectecture designs", if you want to spend your days discuss design plans and the benefits of this and that fair enough. But that's not what a company needs, a company needs people to write code they don't need 8 out of 10 to be designing code, they need 8 out of 10 to be "boilerplate" code so to speak. And if someone is able to take a code design and implement it without making it more complex then they're good enough for the job. Google is famous for making people jump through hoops and then have them do basic tasks, because doing basic tasks is what is important.
That's just my rant of the week on IT recruitment.
Most of these companies would only need 1/2 - 1/4 as many "coders" if they'd get rid of their Not Invented Here syndrome and let the coders dictate how the product functions (technically). So many times I've had to build products that are arbitrarily designed by non-technical folks who don't realize that dictating their preferences, instead of flowing with the existing tech, quadruples the implementation time.
That's just my rant of the week on stubborn folks who think their company is a snowflake that requires a bespoke software solution.
Of course if you already have a job in tech and 3 other companies on the resume it doesn't matter so much.
For people straight out of university their side projects are interesting to recruiters though as there's not that many other references you have. This is even more true for people not coming through the normal CS pipeline, working on their own projects and shipping something is a good way to show that you know what you are doing.
Especially when so many people coming out of CS studies don't even know how to code.
That is so bizarre to me, in Portugal pure CS theory without any kind of project deliverables is a math degree specialisation, what one would do the last two years of a 5 year degree in maths.
Spending 5 years in any kind of engineering degree without being evaluated just doesn't happen, unless one would be cheating on their project assignments.
Main difference would be the time pressure. Our coding assignments could be done generally at our own pace, though of course there were deadlines. Also the "tricky algorithm" and "off the top of your head" aspects generally weren't there - of course way back when, there wasn't a whole lot of code public so you couldn't just copy off the internet. though of course some cheated and copied each other's work.
Perhaps universities should start acting like more like what the companies are testing for nowadays, in order to prepare their students better. Timed coding quizzes every week, automatically validated like HackerRank, Leetcode, etc.. It wouldn't even have to be these tricky algorithms - maybe just a something like implement quicksort, etc. (without using the API calls) in like 30 minutes.
It's not too hard to get passable marks in a subject you don't understand well and then forget most it.
Suppose a given class has a 40/60 applied/theory split. Our hypothetical student is average in some sense and gets 75% on the theory. Now if they get at least 37.5% on the applied portion they barely pass the class.
There are minimum GPA considerations, and you might need at least a C in some classes rather than a D to continue, but it's pretty common to spread the hardest classes out so that you only have one super hard class to focus on each semester, and easier courses and generals will help pad out the Ds on your transcript to maintain a passing GPA. Throw in a retake or two for a couple screw-ups, and you still graduate in 4 years with a whisper of a shadow of an ability to program.
Filtering for high GPAs and whatnot can help (or it might exclude people who had family emergencies or other complicating factors and still know their shit), but in the worst case that's just a measure of the amount of time and dedication spent per course. You also probably need to set a pretty high threshold -- you can bomb all your algorithms, data structures, and applied programming courses and still have a 3.5+ GPA if you do well enough elsewhere.
People have different standards of "know how to code". It could means you were able to solve this tricky algorithm problem I gave you in < 30 minutes. It could means you know some of the darker corners of C++, know the STL backwards and forwards without having to consult references (like whats the complexity of inserting into a map vs unordered_map), how to do a custom comparator for std::priority_queue, or custom class for unordered_map (again without looking it up), know how to use std::function etc. Alot of that stuff was not taught at university at least where I went - the profs/TAs largely didn't care how your code looked, as long as it ran correctly, we didn't have timed coding exercise- the timed exams were writing out things by hand, mainly in pseudocode. Of course this was all 20+ years ago so perhaps things have changed.
Every customer I worked with stores their code either on github or bitbucket. The only one who doesn't let me use my self hosted git repository (I mean the copy on a server of mine.) They also have a copy they can pull from there.
That doesn't help much. Our org, for example, runs private github instance. Only few things end up in github.com, and this is mostly boring stuff like patches to existing projects.
Why do we have to make everything so forcefully career driven? Just enjoy writing code and showing it to the world if you want - no strings attached. Github helps in this case.
I've been using Github long enough that I have my first name (not a terribly uncommon name) as a username.
I have no idea what it even means to follow somebody on github.
Why? I use github to host my code, to collaborate with others. I use issues, sometimes wiki, pull requests (obviously) and so on. But it's not a social platform for me. I don't want it to be a social platform.
I guess following means I get some kind of notification when they do something? I'm drowning in gh notifications already, and switched off most.
So I'd discard followers on github as any kind of metric right from the start.
Maybe I missed the forest for the trees, but it sounds like OP is almost discouraging people from contributing to their GitHub profiles?
If you are a well know or experienced dev with a long resume of working for closed-source companies, then, yes, you don't need a GitHub profile.
For younger people or developers switching domains, GitHub contributions and personal projects might be the only way of showing their worth to future employers.
> Maybe I missed the forest for the trees, but it sounds like OP is almost discouraging people from contributing to their GitHub profiles?
It wouldn't surprise me. There is a lot of content online that appears to be created for the sole purpose of finding work or as part of school/university projects. A lot of that is of limited value, which diminishes the signal:noise.
But I think the main point of the article is that it is unlikely to be used in the hiring process. People either don't see if as being of value or realize that it can be gamed.
I asked ~50 candidates for some code I could look at, and not one had anything public to show me. I think being active on GitHub and having personal projects is a great sign, but it's so uncommon that you can't really knock people for lacking it. I personally use GitHub, but don't have anything of substance public. My previous employer actively fought against us contributing to open source (even though the company operated 100% on OSS). I still did so anyway, for tiny fixes that irked me.
I was on the panel for 300+ candidates and only 2 had any substantial gh presence - one had a bunch of prototypes that he specifically created to show off during interviews (“let me show you how i implement deque in a new language over two weeks”) and the other one was legit and worked for OSS company.
I think I agree with "Followers on GitHub Show Popularity Not Talent" to some small scale, but that example is idiotic, who is going to submit a fictional character's GitHub profile as their own.
Most of the time when there is +50 people following someone it means that at the very least they have one significant repository, published article or somewhat known through other means (blogs are one).
Followers on GitHub is nothing but a popularity contest. I know, because until recently I had like a dozen followers, mostly people I knew, some prolific followers, and a handful of people who actually probably did so because they enjoyed my work. Then I wrote a couple of blog posts about Homebrew and companies choosing their tech stacks and suddenly I had a hundred new people following me-not because they thought my code was any good, but presumably because they enjoyed my writing, which had essentially nothing to do with the kinds of things I put on GitHub. (I hope they’re not disappointed, to be honest.) If you look at highly-followed accounts, they are always people who write giant “awesome” lists, or maybe have a substantial Twitter presence, or are the primary maintainer of one popular project. There’s a huge number of highly-skilled people who have essentially no followers at all.
He doesn't say that someone submitted a fictional characters profile as his own.
He says github popularity is a useless metric because even fictional characters have a higher popularity as nearly all github users.
Yea, the author performed an argument by selective observation in the followers section. Choosing a GitHub user from a famous TV show to prove his point makes the line of argumentation particularly fallacious.
I'd need to crunch the numbers, but would suspect that number of followers is highly correlated with GitHub stars, PyPi / NPM downloads, etc.
It just indicates that his account has followers.
A couple of friends or some fake accounts and everbody cam have followers.
The pure existence of followers says nothing just like everywhere else.
My activity graph is almost solid green just due to commits to my private dotfiles repository, so yeah it’s not that useful. On the other hand even if no one looks at my profile, the projects on there allow me to put extra keywords on my CV which could help with resume screening if nothing else.
Fwiw I was interviewed at the beginning of the year because a recruiter found a 5yo stackoverflow post that I completely forgot about (I probably have something like 3 posts on SO).
Actually, GH doesn't just show open-source contributions. It will also show private repos, if you set that (I think it's on by default).
Some folks use this to "game" their activity logs. I've heard of people writing scripts to draw pictures in the activity log. I haven't actually seen it, though. That's mostly because I haven't bothered to look.
I encountered one activity graph that was insane. It had about 15,000 commits per year. I work 10-12 hours a day, 7 days a week, and have about 3,000. I know of folks with 5-6K, that I believe are legit.
Then I clicked on one of the squares, and saw that it had about 600 commits in one day, in a private repo, along about a 24-hour cycle.
The person obviously had written a script, that checks stuff into a "dump" repo, automatically.
So, the lesson is, caveat emptor. The activity log is an outstanding way to view someone's working style and velocity. Since I do pretty much everything in open-source, you can run number-crunchers on my ID, and see what I do, when. GH has an API. I suspect there's some interesting stuff out there (someone posted a pretty cool CLI tool in HN, a while ago, that showed graphs of the time of day most people did checkins).
Back when I was a hiring manager, I would have killed for the kind of info the GH activity log can give. Totally knocks "Draw Spunky" tests into a cocked hat.
Important caveats to the private repo contributions:
1. It is opt-in, so your private contributions do not show up on your profile by default[0].
2. Not every org is running on GitHub public. If you're using a GitHub Private server, or if your employer uses something else like GitLab/Gitea/...
3. If you leave the org, your contributions to private repos might get removed from your profile. Unless you read the docs and remember to STAR the repos you worked on. Apparently, now they also count opening an issue/PR for this, but I haven't tested this[1]
[0]: By default, visitors only see public contributions on your profile.
> The person obviously had written a script, that checks stuff into a "dump" repo, automatically.
Or they had automation committing things into a private repository for some purpose (e.g. machine states). It doesn't have to be an attempt at "tricking" anyone.
Good point. I didn't think it was a deliberate trick, as it wouldn't have been that extreme, if the person wanted to misrepresent themselves. It just made their GH profile worthless, for me.
I do think that tools like GH are important for helping to introduce ourselves to others. As with any tool, it is up to us to use it properly.
For me, I am not actually looking for work, but I get tired of not being taken seriously, so I make a point of ensuring that my work is made available for anyone that wants to see it.
My motto is "Don't just take my word for it. See for yourself." I am grateful for tools like GH, that allow me to do this. The Stack Overflow Story is another one.
The main thing that makes me wary of relying on something like GH in particular (esp. suggestions like scraping its API for data) is that not everybody uses those.
For example, almost all of my open-source contributions happen on privately hosted infrastructure. Instead of looking at my Github you'd have to look at my Gerrit[0] - otherwise you might get the impression I have no active open-source footprint.
I think it is valuable to look at publicly available contributions of candidates, as long as it's not constrained to a particular location.
You're right (and, from what I can see, talented).
But it doesn't hurt to have it out there, on a case-by-case basis.
If I were interviewing two candidates, and one has a big open-source history available (regardless of the vehicle), then that candidate automatically has more value to me. I may not hire them, as their history may show something that I don't like (damolcean sword, and all that), but they make my life, as an evaluator, easier.
Sure, a lot of great people do not contribute to open source, yet I do (maintain a sizeable popular project), and nearly half of the interviews spend a good time discussing the work I do in opensource.
I've been a hiring manager for 10+ years and I've used the candidate's code on GitHub for helping pre-interview screening decisions numerous times. Good code on GitHub is a good sign, of course I can change my mind after actually interviewing the candidate.
This phrase from the article over simplifies this and is frankly childish: "People still seem to think that you can figure out how talented a developer is merely by looking at their open source contributions"
Duh. It says that some people "still" think that you can do that by "merely" looking at their OSS contributions. But maybe, just maybe, others can use it "merely" as a data point.
I laugh at that as an job application requirement and move on. Anyone thinking a look at a GitHub profile will prove skill, is sadly mistaken and not sometime if want to work with. Considering most code is property of employers, nothing to see.
To argue that GitHub won't help you with hiring doesn't just require showing that it's not perfect, it requires that other methods of assessing people (Interviews? Degrees?) absolutely dominate it. But the arguments made against github would work against any such method. Yes there are impressive people without an impressive github page, there are also impressive people who fail interviews, don't have degrees, etc.
> Not only are GitHub profiles not that helpful for hiring developers, it also seems like they aren't that much help for developers that are looking for work.
Why try to dissuade people from something they aren't doing anyway?
> While he has written a ton of code at his work in the last year, he hasn't posted anything that can be viewed publicly: he has no public commits, he hasn't created any repositories of his own and he has an insignificant number of followers. Despite all that he's still the best developer I've ever had the pleasure of working with.
This is more a problem for the developer, not the company. The company may have a smaller pool of candidates by evaluating based on GitHub profiles, but they will have more data to use in their evaluation. If they don't have the resources to pay for the premium of being selective, they may evaluate candidates from a wider pool (those without GitHub profiles/history). The candidates without GitHub profiles will receive the attention from those companies not willing to pay a premium for their services.
This can be generalized in other ways beyond GitHub. GitHub, in this sense, serves as a marketing tool, similar to LinkedIn, a personal site, a blog, a resume, etc. Provided it's a free marketing tool, the developer has little to lose by investing their time into marketing theirself and a lot to gain by receiving more demand.
Have you ever been able to look at someone's code and immediately figure out whether it's good or not? I think it can be easy to see if it's really bad, but sometimes it can be hard to tell if it's okay code, or really good code. The problem is that you might have extra information to make a hiring decision, but it requires orders of magnitude more time to evaluate.
For example, if the whole project is done by a single person do you evaluate their design and code? What if it was just a one-off project that they didn't care about so it has copy-paste code in a few places. Is that bad?
If you ask candidates to point out examples of good code, then is that really meaningful? What if a mediocre programmer can find a few places where they wrote some strong code. What if that code was made good through a strong review process?
I think the problem is that it's too difficult to determine if open source contributions are actually representative of the way someone will code in a job.
I don't think the most useful info you can get from someone's Github involves the sort of deep analysis you're attacking in your comment.
Nobody is deep diving your code like this, btw.
Looking at someone's code projects can tell you some things like how they might write a README, if there is one. It might present a concrete project they built that you can discuss in an interview; what was the hardest part of this project? It can tell you where they are roughly on the scale of "barely started programming" and "clearly are experienced" (an experienced developer can glean this very quickly from someone else's code—even what they choose to paste from Stack Overflow—it isn't as hard as you think).
Reading the code line by line looking for "strong code" is something that beginners think employers will be doing, but they don't. Just like developers don't evaluate libraries like this, they do a more topical, holistic page-through.
Of course it isn't going to tell you exactly how someone will perform on the job. That's not the goal post (the absence of Github usually means you have nothing to look at at all). It just has a few useful signals like looking at a chair that a carpenter has built.
It seems like you are suggesting that the chair a carpenter built in his own time couldn't possibly give you any reliable signal about how the carpenter works, because what if the carpenter was in a rush? Well, let me point out that a rushed veteran and a rushed beginner will cut completely different corners. Kind of like how a skilled artist with only 10 seconds to draw something can still express a great deal of their expertise merely by how they attacked the problem.
Let's look at that chair analogy, you are presuming that someone can look at a finished chair and say it's a good chair, and the carpenter who built it is probably good. But in order to do that evaluation, you need to spend time examining the chair. And you don't have any guarantee that the chair was actually made by the person presenting it to you. Maybe someone else helped them build it, or they built it using step by step instructions they found online. My issue is that the evaluation can take a lot of time, and if you are not familiar with the project, it makes it really difficult to get anything useful.
If your hiring process always requires github code, then the chance of people faking it, or presenting code that isn't theirs is going to increase. And if you are looking at it for a project a candidate can discuss, you can do the same thing by choosing something from their resume.
In my opinion, it just doesn't add that much and will wind up taking up a lot of time. You would also need to decide when in the process you look at the projects. Doing a proper eval would still likely take hours for a small handful of candidates, so you wouldn't want to do it until a person was well down the interview path. And at that point is it really adding much more than you already know?
My team lead would sometimes ask me to help evaluate potential candidates and sometimes we looked at GitHub profiles if one was supplied. No problem if not, but if so then it's a data point.
The claim above from the article is true. Mostly nothing is actually impressive and if you're not careful it's easy to have something count against you. It's actually a bit of a trap.
As a result of that I decided to make all 50 public repos I had private and instead just work on a single public repo of decent depth/quality.
What I wound up doing is create a small web app in a domain I would never be interested in trying to turn it into a commercial product, then I use it as not a single project, but a series of inter-related projects that build on each other. Mostly it's a playground for me to learn new things and explore ideas. So I first did an API. Then once I had an API I took the opportunity to learn a new front end tech and made a front end with it. Now I'm working my way through learning IaC with it. After that I'm gonna use it to learn serverless.
Each additional project with it makes it more valuable to me. More valuable in the sense that each project completed increases my motivation to do the next one because it becomes a more fully fleshed out piece of software and feels more "worth it".
I haven't switched employers since I started it about a year ago, but I think it'll definitely help with positioning. As it is it helps me with my career anyways as I have a semi-realistic environment in which to try things out to evaluate their pros and cons.
I somewhat disagree with the article only because as a co-founder and also as early engineer in previous startups I've worn the interviewer hat a lot and candidates with solid github portfolio projects demonstrated to be better suited for the role than those that didn't have projects to demonstrate their skills. I agree that there are a ton of 10x engineers that don't do any public open source stuff but at the same time you'd know they're good just by having a conversation with them or reading posts they've written. One of my previous employers has also expressed that they were impressed by my github projects and I feel like that gave me leverage over other candidates. It really depends on the employer and I think the larger the company the less they care about your open source projects or how good your portfolio since there's a lot of churn and they can afford it unlike early stage startups where they do a little more diligence on early hires.
By showing that almost no recruiter check the GitHub repos cannot tell if such contributions make a candidate stand out.
If someone has tangible contributions through GitHub, they probably write that down in the resume. The interviewers may check their claims either during interview or on GitHub before/after the interview.
The problem is that if a candidate performs moderately well in the interview (e.g. coding interview), while he/she has made many contributions through GitHub, should the interviewer recommend the candidate? My belief is that most interviewers will not take the risk or take the responsibility for a potentially wrong hire.
But someone who created and maintained a good repo, that's actually used by other people (doesn't have to be many), where the code is relatively clean and actually works ... this says quite a lot actually.
Of course the major caveat is that this doesn't mean that someone who does not have this is 'not good'.
Finally, if someone has made any number of contributions and they are objectively 'not good' - this is also a negative signal.
So 'if there is a github profile' and the code/usage can actually be looked at, it might be useful criteria it just needs to be contextualized.
Thank you! I have been complaining about this forever. 99% of software I write is closed source! It seems like we get punished for this when in reality it’s the company’s policy not to publicly expose proprietary information.
While the author makes some valid points, I disagree with the general stance of the post (and, more broadly, quite dislike most generalizations like that). Obviously, no decent hiring manager in their right mind will base their decision purely on someone's GitHub profile. At the same time, relevant profiles with enough information could be a very useful signal and data point. In other words, I think that using GitHub profiles to augment other available information is a worthwhile element of the overall hiring strategy for [software] engineering teams.
I fell into this cycle where I posted my projects on GitHub. I was constantly chasing the green tick every single day. All my projects were representation of bad code. At the end, I learnt that successful developers usually pay mere attention to Github and more attention to problem solving and consistent learning. These days, I use Github as a reference to concepts I learn. When a day come where I can consider myself a master on a language, I’ll take on an open source project to solve a real world problem with the knowledge gained.
This 100%. Especially the 'most projects are uninteresting' part.
I see a lot of enthusiastic students writing yet another Tensorflow something of 2 files and uploading it to GitHub. That does not mean these projects are interesting.
It is hard to get great project ideas. On the other hand it is quite easy to slap together yet another python data visualization 'project'.
Another thing is, plagiarism. Some people create repository out of cloned files. (if forked, it will be shown as forked on GitHub).
While the article is technically correct, it is completely wrong on its message. I can't use GitHub profile as a negative factor, but totally can as a positive one. So, active GitHub profile literally helps with hiring like in "requires less effort from both candidate and company sides".
Non-representative counter example: we produce only Open Source products, and I review the public code contributions of all technical staff during pre-interview assessment. If you're hiring Open Source developers then past Open Source contributions to other projects are useful and important.
I've taken to maintaining a singular "portfolio" repo that contains bits of a code with pointless code (like standard framework boilerplate files) omitted, with a README in each folder for context and explanation.
I agree with the article that the quantitative metrics(contribution statistics, followers, stars, LOC, etc) are not really good vor evaluating someone. But its still good for checking 1. The type of code one writes and in what languages, maybe documentation and 2. The interactions with other people in form of PRs and issues.
I guess that most recruiters don't have the time to look at that but it definitely could be valuable.
having worked at multiple of most peoples "dream companies", i can tell you very few of the engineers i met had every contributed to open source, and no one cared. and furthermore the company wouldnt let employees contribute, as it created copyright issues
I don't get it. Obviously assessing candidates by only looking at their GitHub is a bad idea. But if a candidate does have a good GitHub, that's useful information.
GitHub also record contributions in form of issues and pull requests. Not contributing to projects you are using for your work looks like a bad signal for me.
Not everyone uses open source for their work. Even if they do how likely is it they’d have anything to contribute? Can you mark down most developers who use Java or Spring because they haven’t found a bug in them to report?
If they do, I'd say it should be very likely the moment they start using anything smaller than Java/Spring for anything serious. I opened issues and/or PRs for about a dozen libraries and frameworks, and that's probably 50% of what I could open if I had more willingness.
> The vast majority of software being produced is closed source software
I found this claim surprising. I would have guessed that the narrow majority of software produced these days is open source, but I don't have a citation for that. Do others agree with the article's "vast majority" claim?
Open source IS prevalent, but most of it leads to closed source. A large majority of those employed as developers are using open source libraries and languages to build closed software.
Look at all the software running on your computer right now, how much of it is open source? (Including OS, drivers, ssd/efi/cpu/misc controllers firmware).
Email every website you visit and ask to get the source code.
Go and check all gadgets in your house which contains a microcontroller or cpu, how many of those can you get the source code for?
Ask your car manufacturer for the source code of all its systems.
Go out in your city, look at all computerized utilities (screens, payment systems, traffic lights, elevators, power plants, public transport, the list goes on..)
Does it really need to be checked? Seems blatantly obvious to me that most software is proprietary.
> Look at all the software running on your computer right now, how much of it is open source?
Most of it? The hardware, OS, web browser, window manager, terminal emulator, and text editor all are, anyway. There are a few proprietary bibs and bobs, but really not that many.
> Go and check all gadgets in your house which contains a microcontroller or cpu, how many of those can you get the source code for?
My impression is that most of this IoT-type devices run Linux of some variety. They might have some proprietary stuff on top (though not a ton, given the GPL), but that seems to be basically another check in the "open source" column.
> Ask your car manufacturer for the source code of all its systems.
Well, it's a Toyota, so it's running Automotive Grade Linux, so…
> Does it really need to be checked? Seems blatantly obvious to me that most software is proprietary.
It doesn't seem blatantly obvious to me, but it's interesting to hear your perspective
Do you count web sites? Can you run own copy of for example google search? Browser in nothing without these applications. There are just a few exceptions - Hacker News, WordPress, GitLab, there is a platform https://sandstorm.io/
Do you have a smartphone? Is it LineageOS microG and F-Droid applications or postmarketOS? Maybe something else from quite a limited list [1]?
I use Linux, there is much more software for Windows and it is not open source.
Just because some part of the underlying software is open source (AGL) does not suddenly make the whole thing open source. And you’re in a minority if you’re using linux or some variant of it as your OS. The world outside of tech circles is much more closed source.
Correct, but that wasn't what was being responded to, it was this claim:
"you’re in a minority if you’re using linux or some variant of it as your OS"
Ultimately the point you made here is what's important: that there is plenty of closed source that runs the world, even if underlying infrastructure is open.
When contemplating how much software is closed vs open and specifically in the context of the value of github profile/activity for hiring, I am much more inclined to count the production and maintenance activity (the dollars and human hours) not the deployment count.
If 75 million sites are running Wordpress, I think that counts as “closer to 1000 (because Wordpress is large) than 75,000,000”.
Coding since mid-80's, never worked for a company that would allow me to publish work related code, with exception of my time spent in research institutions.
I bet this applies to the large majority of developers out there, but I am extrapolating.
Yes. The vast majority of developer jobs are primarily working on closed code, and I don't think contributions made in people's free time etc are enough to compensate for that. What I think distorts the perception is that you'll find a lot of open-source code underpinning closed software - but thousands of projects using the same open-source library doesn't increase the amount of open code.
This seems likely to me. Programming is a relatively lucrative profession, so people who do it a lot tend to try to get paid for doing it. People who get paid to program will tend to write closed-source code for 40+ hours per week.
Maybe they work 8 hours a day on a bank or government project that is all private and then they spend the rest of the day acting as a care giver to a relative, studying, or volunteering in a women's refuge. All noble activities that I would consider positives for a candidate, but I'd never know if I just checked "Do you go home and cut code out of hours?".
I mistook my own privilege of free time as a universal truth and I'm glad I was called out on it early on and able to change my (interviewing/screening) ways. I wonder what else I need someone to call me out on...