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.
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.
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.
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.
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 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.
>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.
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
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”.
> 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
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.
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.
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.
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.
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.
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.
> 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.
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.
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).
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.
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.
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).
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 :).
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.
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.
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?
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.
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 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.
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.
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 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.
> 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?
183 comments
[ 4.0 ms ] story [ 271 ms ] threadIf 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.
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.
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.
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.
Passing programming assignments or university projects is very different to actually knowing how to code or think about solutions on your own I think.
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.
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.
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 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.
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.
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.
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.
You can now make your private contributions a data-point on your public profile[1] without giving away private information
[1] https://docs.github.com/en/github/setting-up-and-managing-yo...
All of them are medium / small sized.
Once a company removes your access rights to their private repo, your historic commit record there disappears from your own commit timeline.
Same here lol
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.
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?
How do we know this to be true? Has anyone checked?
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.
Does it really need to be checked? Seems blatantly obvious to me that most software is proprietary.
Well 30% of websites alone run WordPress, so I could look at the source code. I'm not sure it's as blatantly obvious as you think it is.
If 75 million sites are running Wordpress, I think that counts as “closer to 1000 (because Wordpress is large) than 75,000,000”.
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 realise most people's primary computing device - their phone - is running open source Linux?
"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.
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.
[1] https://en.wikipedia.org/wiki/List_of_open-source_mobile_pho...
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.
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.
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.
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.
[0]: https://cl.tvl.fyi/q/owner:mail%2540tazj.in
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.
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.
[1]: https://docs.github.com/en/github/setting-up-and-managing-yo...
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).
Someone with followers still indicates that at the very least some people are interested in that person's projects.
I'd need to crunch the numbers, but would suspect that number of followers is highly correlated with GitHub stars, PyPi / NPM downloads, etc.
* BurntSushi: 4.4k followers
* wesm: 9.6k followers
* tj: 43.6k followers
The followers section of the post may have cherry picked a non-representative example.
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.
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 :).
So you can't even commit something own, when in private, because company you work for can sue you, just because?
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.
> 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?
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.
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 guess that most recruiters don't have the time to look at that but it definitely could be valuable.
Plus, you can generate activity for your profile. It's a game of cat and mouse.
https://hackernoon.com/how-to-hack-github-kind-of-12b08a46d0...
* 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.
https://github.com/adamtornhill/code-maat
You could identify high quality devs that are suddenly funemployed with a burst of github activity - and reach out to them in a non-sleazy manner.
Everything else is a less accurate proxy measurement. Unsupervised, self-motivated, goal-oriented adulting ... that's what I need
Doesn't matter what company, these basic requirements don't seem to change.
Because a lot of us have to code for a living, and employers often ask to see GitHub projects.
None of us are choosing this. It's just one of the many shitty trends in the world of software HR.
Hence the topic.
Having a Github profile is "being forcefully career-driven" because it's now a potential gate put in place to work at increasingly more companies.
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.
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.
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.
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?