As your professional accomplishments increase, the value of GitHub profiles (for most) as a marketing tool diminishes dramatically, but can still be helpful.

For developers at any level, repos are a good conversation piece for interviews. The interviewer can ask why choices were made, what the candidate might do differently now (shows growth), and start interesting technical debates.

I always ask my clients (I'm a resume writer and career consultant) if they have a GitHub profile if I don't see one listed, but I don't always include it on the resume. New entrants to the industry are not exactly punished for not having one, but it's becoming an expectation. This is different than expecting an older adult that may have life responsibilities that prevent (or simply no interest in) coding outside work.

Having a portfolio to show what your capable of is a great way to set yourself apart. I don't think anyone is expecting you to have developed Linux from scratch. But something is better than nothing. Which do you think is more likely to get an interview, someone with several source GitHub projects or someone that says "all my work was closed sourced" and has nothing to show.

Having founded three startups now (2x acquired), most of the best engineers I have ever worked with have a noticeably more active Github/Bitbucket/Gitlab portfolio than the average. In my experience, great engineers have public proof (open source, a self produced product, book, etc) of their craft vs nothing at all.

Now to be clear, just because someone has an active Github, or a book, or whatever doesn't mean you should hire on the spot. But should be someone you'd prioritize over someone that is seemingly too lazy to do any related extra circular activity.

I saw PHP, game dev, JSON. I saw that he does do OSS stuff, though not much. I saw that he can write a decent readme.

That's the kind of thing a hiring manager gets from a github profile. It's not a one-dimensional test like how many checkins does the dev have.

- GitHub also allows you to display your activity on private projects (as long as their development also happens on GitHub, of course). - It’s not a great indicator, but it’s an indicator of what kind of programming people do for fun (or alternatively, that their employment/life circumstances don’t allow them to be active on GitHub).

I don’t think not having anything on there is a bad thing, but I’d like to talk to the candidate about why. Sometimes you’ll learn that people have the most fun non-programming hobbies or the most responsibly-filled lives.

I am currently working on building a tool [1] that helps developers build profiles that articulate very clearly both what they bring to a team and what they are looking for in a next job. We're approaching this as a data problem, but unlike many dark recruiting tools, we think it's important for the developer to be completely in control of the information that makes it into their profile.

[1]: https://www.fizbuz.com

One crazy idea I have it to experiment with some kind of "Sabermetrics for software engineers"–think "WAR for developers" [0]. Using GitHub would be an obvious data-source (how to use it and if its a good idea is an entirely different discussion).

While I think this article makes some good points, he seems to only touch the most simple approaches. There's a lot of things you can do with a GitHub profile. To me, they'd never be deciding factors, but you can definitely extract some pluses out of a person's profile.

[0] https://www.fangraphs.com/library/misc/war/

In fact, contributing to public open source has been the proven tipping point that shifts hiring decisions in my favor if the hiring manager is on the fence. In all other cases the combination of a frequent open source contributions and a strong interview have allowed me to nail senior positions as the top candidate.

Whether or not any of this makes me a rockstar is completely subjective, but beating out all other candidates (several dozen) hands down on multiple occasions really increases my self-esteem.

So no one should be "filtering out" inactive or boring profiles.

The exception I'll claim is for junior engineers. At that stage in someone's career, having a portfolio matters, and should be actively cultivating some kind of public code presence.

This generalized statement is false; some do, some don't.

Been at multiple startups and the best candidates hired have great open source projects on github that indicates they're qualified for the role more than someone with nothing to show.

There are people who believe in it, it seems reasonable, but in reality nobody cares. Just another cargo cult.

It shows me they can code, perhaps in the languages I am hiring for. It also shows me they know how to use version control.

Case in point, the candidates I interviewed -- if they had any public Github projects: (1) had maybe one or two projects of their own that were public. (2) They were personal projects of varying levels of "quality", i.e. not their day job. (3) They were the only developer/committer and new commits were somewhat rare. For the most part, just the existence of a profile with some projects was a plus. Most candidates didn't give me a way to see that they could actually write software (fizz/buzz?) -- though there are ways to solve that without resorting to white-board or in-interview programming.

I started using GitHub and "external work" as an interview technique after an experience with one of my best hires. This was a candidate not unlike others that had a pretty dead profile, but there was one project that showed code quality and thought that far exceeded "the typical". It was clearly "That One Project(tm)"; his baby. The code quality was quite good, it had documentation and it had thought put to its design[0]. It had zero stars or forks, but it was obvious this was a tool he wrote for himself and really cared about. His interview started out very badly because he was nervous, but the project saved him. Mainly because I started wondering if he actually wrote the code in that project (because he failed to answer some pretty basic code design questions), I pulled up his project and started asking him specific questions about his code. He went from nervous to excited[1] and was suddenly able to explain things that he had a difficult time with when they were presented simply as abstract concepts.

I used to facilitate many technical interviews, but it's been a little while since I've done one due to a new job/different company, however, I think the method I use is still the one I'd go to. The technique I used after this gentleman was to call the candidate a week in advance of the interview and ask if they have anything public, code wise (blog posts, SO/Github/Gitlab/Bitbucket profiles), that they can point me at or if they could provide some samples[2]. I always explicitly state "This doesn't need to be your best work, or even terribly great code, it just gives me a starting point to discuss development practices" and I recommend they pick something they've done recently since "any code we've written more than 6-months ago might as well have been written by someone else" The technical interviews would then, generally, be that candidate explaining their code, the choices they made, why they made them and what they think improvements would be in order of priority. That has worked really well for me and beats the daylights out of any paper/pencil, whiteboard or even "code this on this laptop while I look over your shoulder"[3]. Assuming you successfully disarm the candidate with the "we're not judging your code (!)" preamble, I've found that people are far more comfortable (and most legitimately enjoy) talking about things they've written -- even critiquing them[4].

[0] In this case, a unit tests covering the right parts of code, documentation, build instructions, logical layout/design -- he cared about this code and it gave a really good insight into

[1] Given his performance in the interview, I would have expected this person to be introverted and not a terribly motivated programmer... goes to show how terrible interviews are at judging people -- this guy ended up being the guy everyone else on the team looks to -- he was passionate in a job that, frankly, wasn't the sexiest programming job.

[2] This last point, to be clear, I expect to never receive proprietary samples. It did happen, once, and I didn't think this was something I had to actually state, but I wouldn't have hired someone who would share code they had agreed to protect since they'd be agreeing to the same thing working on the team they'd be going to.

[3] The difference between a great developer and a great developer who gets anxious during interviews is that the latter might be a little introverted/not good at interviewing -- a personality trait that I've found to be common and for every job I've done interviews for -- not a negative (and can just as much be a positive) for the work I was assisting in hiring for. One of the hardest working people I know -- a guy I'd work with on literally anything because he'll make up for any deficiencies with sheer will and hard work -- has such anxiety in interviews that he actually forgot his middle name in an interview (not completely, he just spaced -- hard -- my boss hired him anyway on my strong recommendation).

[4] A small tip: Complimenting the work is an easy way to get things started smoothly -- it doesn't need to be phony; there's usually some way to point out a few positive things about the work. Start there, ask questions in a manner that simply states a desire to understand the code more, and let things roll from there.

"I've only had one job interview in the last decade or so, but as far as I could tell none of the people interviewing me checked out my GitHub profile before the interview"

So that makes this guy an expert?

In a genuine passion project, I'm having fun. If you're checking whether I've dotted the Is and crossed the Ts in terms of testing, documentation, edge cases, etc. you'll find that I haven't, because the whole point of programming outside of work is release from the tedium of professionalism and an opportunity to go straight for the novelty and joy of making things work at all.

For projects specifically intended as portfolio pieces, I'm not sure how I could design software appropriately (or evaluate candidates' designs) in the contextual vacuum of "needing something to put on Github."

While I agree that they're less important, especially if there are commercial products/accomplishments that the candidate can point to, I wouldn't say that they diminish dramatically.

For a candidate that has years of industry experience, a look at a GitHub profile can serve as a solid metric for their growth as a developer. I want to not only know that a developer "has been doing something for a while" but that they're honing that craft. For me, personally, I want to look back on anything that's 6-months old and be able to point out everything that I'd do differently[0].

It can also serve much the same purpose that it does for grads/bootcampers. It gives you an opportunity to show off your knowledge in areas that may not be covered by your professional work -- maybe you're doing mostly back-end/systems and want to demonstrate knowledge in React/TypeScript/Angular/front-end. I knew a guy who's repo is filled with rust projects. Professionally, he was a (very capable) Java developer[1]. His rust-filled repo landed him an interview for a job doing mostly systems work in C/C++ with a hope toward moving things over to rust where it made sense ... and no Java work[1].

> I don't always include it on the resume.

I don't include mine, either. The best advice I received on resume writing was "It's to get you an interview, not a job", so I treat it as marketing copy. My github repos (I have a few github accounts) contain a lot of code that I shared because a few others wanted it and Github was the most convenient way to do it -- but that code was hastily written and was never meant to demonstrate my abilities. Some of it -- were it encountered by someone who doesn't understand that caveat -- would make me look bad. If I get a pre-interview (phone interview), I already have an e-mail ready with links to all of that waiting for a "To" field which includes boilerplate that I've also already casually joked about "I'm happy to send all of these to you to reduce time spent googling, as long as you promise you won't judge the thing I wrote in an hour at 2:00 AM on a Saturday night as a prime example of my coding ability and will at least give me an opportunity to apologize for some of the evil I've unleashed on the world."

[0] I always joke that I don't feel like I'm growing as a developer if code that I wrote 6-months ago doesn't mildly embarrass me.

[1] I learned, by accident, that he hated Java (I asked him if he was interested in putting his resume in for a Java position where I currently work) -- it was his first serious language and he'd since explored Clojure and many others but because he was known as "The Java Guy" where he was at, he wasn't able to get out of that line of work over there.

I’ve also hired developers. I have a simplified version of a real world project that we are working on. The methods are skeletons with no code and a bunch of failing unit tests. Part 1 they have to get the unit test passing. Then I give them a harder set of requirements with unit tests. They have to make the second set pass without breaking the first set.

It tells you a lot about how someone thinks.

Given the choice between not being able to interview and not being able to get references, you'd do better hiring sight unseen based off of strong recommendations from a source you trust than from conducting thorough interviews without references.

So people with life responsibilities are too "lazy" just because they don't code outside work?

Expecting potential hires to labor over portfolios and prepare extensively for auditions is a luxury enjoyed by the few most badly oversupplied artistic fields.

Some people aren't in the mood for extra curricular activity after working +14h a day. They rather unwind, and be productive the day after in their not-pushing-to-github jobs.

GitHub will not even remotely tell you that, though. There are tons of open source projects that are not hosted on GitHub. If you, say, contribute to the Linux kernel, or to Firefox, or perhaps Xfce, nothing will show up on your GitHub profile to give you "credit" for that.

I agree with another poster that GH can be useful to disqualify candidates (say if they've posted something they've plagiarized as their own), and you might find interesting things on a candidate's profile that increases your impression of them, but it's absolutely useless for comparing candidates or getting a full picture of what they've worked on in public.

For instance, the fact that some accounts are fakes for a TV show, or that some projects are jokes and listicles, has nothing to do with the particular GH project of a candidate that you're interviewing, having found that candidate in ways having nothing to do with GH.

Sure; GH being full of crap makes it impossible to use for searching for developers. (Not to mention that, oh, people don't use real names, and you don't know whether they live across the street or across the ocean).

The main valid point is that a great developer might have an inactive GH account.

"If you're looking for a thief, it isn't useful to look into pockets. Many pockets contain nothing, or lint. And those that contain something are almost always legitimate: stuff that the pocket owner owns. Some pockets are fake; just ornamental openings that are sewn shut, with no actual pockets behind them. The best thief I ever nabbed had nothing in his pockets; everything was in a big duffle bag in the trunk of his car."

It is not. If an employer can't ascertain your skill level through the interview process, their hiring is broken. It is a slippery slope where we allow employers to dictate uncompensated signaling necessary for a role.

Observe how it worked out for everyone who got a degree because employers won't hire without one, and then they don't get hired regardless of that degree. So we'll all toil on public Github projects in hopes that'll be what convinces an employer to hire? Will we all need to intern for several months for free next?

@always_good: Hiring is hard. If you succeed in hiring the right people, it won't be because they jumped through your hoops, but because they were passionate, had some of the skills and could grow fast, and a huge helping of luck.

That's what a resume is for. It explains the what and how I performed my last jobs. GitHub is possibly how I did my own hobby projects which have different requirements.

We're not artists who can easily keep a copy of the code we produce. That's a problem with asking for more effort on my own (unpaid) time.

Lots or most devs don't need to.