> ” And yes, some hiring managers are gonna say "welp, this candidate isn't an open source ninja so we don't want them." But that's not all hiring managers.”

So probably is good risk management to not include your GitHub ever when applying.

Giving as few reasons to deny your application before an interview just seems like good practice. The whole process is arbitrary anyway.

This depends on how many options you have. If you have many options it can be a good thing to filter out companies that would not be a good match for you.

As a general rule of thumb, if you don't want to be evaluated at least in part based on something, don't put it on your resume.

(and the inverse holds as well: if you do want to be evaluated at least in part based on something, consider putting it on your resume).

Still, I'd be pretty irritated to learn that someone decided not to even talk to me because I included a github link to some toy project that they didn't like.

This strikes me as unnecessarily bitter and cynical. Application is a two way street. Would you even want to work for a company like that?

Not bitter at all, not sure where you got that impression from my post. If I have something that does not present me in my best light, why should I volunteer to show it in a hiring process? I am just being practical.

I do think all hiring processes have a component of arbitrariness, so I don’t think it is necessarily a bad sign that a company quickly dismiss candidates from poorly-maintained GitHub accounts. I would gladly not show my GitHub and try to get the job showing my skills in some other way.

A company doesn't necessarily begin and end with the person hiring.

Most people work where they find work, not where they want to work. It's less true in IT, but I'm still betting it's mostly true there

If they pay well – absolutely.

There are risks either way, and this is one of those processes where you just want a single good hit. So I guess the optimal course here is to maximize your risks (unless they are biased into not-hire), not to minimize them.

There are other processes where you must never fail. For those you want to minimize risks. If you want a job at X and nowhere else, this is your situation. But that's not very common.

Good point

What’s more common - hiring managers who see the inclusion of a GitHub as a small positive signal but don’t scrutinize heavily (or even more likely don’t bother to click into it), or those that dig deep and scrutinize open source contributions as a primary decision factor?

Or maybe the managers will decide to only interview people with a GitHub link?

Could go either way.

I've seen applicants with lots of Github repos, which all turn out to be forks, and all the applicant did was make a trivial change to the documentation (not fixing a technical error or expanding the comprehensiveness, but adding periods at the end of list items, capitalizing some proper noun that got missed, etc.)

It seems pretty clear that the Github link in resumes has been cargo-culted for several years now.

Too bad, because "fixing a technical error or expanding the comprehensiveness" of existing documentation would be a very strong signal to hire!

Yeah, honestly seeing someone add a big chunk of fresh, useful information to a project's documentation would be even better than seeing code go in, because most people hate doing docs! Unfortunately what I've seen is absolute lowest-level "get a commit into the tree" stuff.

You mean, when it's meant to signal that a given person fixes every little thing they come across, and not 'hey, this guy contributes to LLVM!'

I didn't know why people fork repos arbitrarily on their GitHub. I thought they were doing that unnecessarily before cloning or something. So this is the reason?

No. The reason is because when I and others investigate some code we like to make small refactorings as we go along. Change a variable name here, redefine a type here, and see what breaks. If you think those changes could ever be pushed upstream you save them in a github repo. That it looks "random" to hiring managers is something I've never thought of.

We are talking about different repos then. The ones I am talking about have no commits or refactoring going on, usually they are even with upstream or some commits behind. I was puzzled why they were forking these repos while a git clone will perfectly do.

Maybe a location thing. I am from India.

Quite often people will fork so they can tinker locally. It's not odd to see forked repos without any changes, it's just someone being curious or wanting to make a contribution but not having time to go through with it.

I'm sure it's not the only reason. Maybe some people fork repos they depend on just in case the original owner decides to take theirs offline, etc.

But if someone lists their Github on a resume, and then the whole account is just full of do-nothing forks and no original work, I'm going to be a little suspicious.

100% this. Show me you’re actually interested in this stuff.

I could show you, but my github account is not representative of my actual interests. That is precisely what resumes and motivation letters are for.

If recruiters start looking only at github accounts, dishonest job seekers will quickly learn to create fake github accounts, just as they present fake resumes now.

I’ve been interviewing candidates for ~5y across two companies and have yet to see a motivational letter. And most the resumes I see are either overly verbose and don’t tell me what you actually did, or are simply a soup of buzzwords.

A few of the most successful and memorable hires I was a part of have real github accounts with something more than a bunch of forks or fancy profile readme.

In my opinion, it doesn’t matter if the content isn’t representative of what you want to do at work. Seeing that you’re curious and interested in building things, trying weird experiments, and so on is a strong data point in and of it’s self.

Here’s a similar example from an unrelated field: there’s a handyman that lives down the street from me. His humble home is neatly manicured and I often see him outside in the morning, dressed for the job and working on projects. Observing the pride he takes in his craft was a signal to me that he probably does good work. And after hiring him for a small project, my hunch was correct.

Your example is excellent. I agree with you in that choosing a developer in basis to a github profile is not much different from choosing a handyman in basis to what he does in his garden on the mornings. What if there was a much cheaper and more efficient handyman living up the street, but he always works in his backyard so you have never seen him outside?

I am sure you can find valid candidates with your method, but also that you could be missing much better ones.

The soup of buzzwords is because of the shitty algorithm/outsource your org uses to pre-screen for candidates.

why do you care?