Why GitHub Won't Help with Hiring
benfrederickson.comI look at GitHub profiles to help filter / disqualify candidates. Just last weekend, I had a marketing candidate who had stolen three Wordpress projects from their current employer and post them as public repos on their personal GitHub account. In addition to the flagrant intellectual property theft, the repos contained the wp-config.php file with exposed database “root” credentials to live, client sites.
> flagrant intellectual property theft
Granted, this seems like a case that's less malice and more adequately explained by stupidity.
Not sure either bodes well for hiring.
I use GitHub accounts to provide context, after triaging CVs. The first sentence of the article mentions data aggregation, which is very far from how I use GitHub when evaluating technical candidates.
If you have already somebody's resume, GitHub provide clues and maybe a bit of evidence for your assessment of the candidate. Older, busy working software developer? Expect not many projects, possibly an intermittent commit history. Most GitHub projects are just unfinished exercises, so a workng project is unusual, and a clue that the candidate is also unusual. It's not scientific, but it's evidence that you can use, alongside the resume, and any communication with the candidate.
I know it's not really your responsibility but did you inform those sites and/or the candidate?
We did.
Did you also report the employer's "theft", as you put it, of WordPress's GPL'd code?
that's just...that's just not at all what GPL is
The GPL is a license. If you don't abide by it, you don't get to download a copy of the software, sell it or create derivative works.
The history of WP itself enforcing the GP is instructive. More recently, Panasonic Avionics has been sued for $100M due to GPL violations.
GPL does not force you to publish anything. But if you do publish a derivative work (including a binary) you must make sources available on request.
A WordPress-generated website is likely not a derivative work of WordPress source code. (Which is why Affero GPL exists.)
The further specifics depend on GPL version employed.
Ah, I'd been thinking this was a theme. If it's a site generated with WP, that's completely different.
My reaction was largely to the poster's self-righteous attitude about "theft", which has mapped to many GPL violators I've encountered.
"if you see something, say something"
Wow talk about a scummy thing to do to their employer. I am sure it will work for them before too... because not everyone would do their DD like you have.
FYI: WordPress.com requires plugins to be GPL for their public marketplace, so there may be nothing "flagrant" going on at all.
Perhaps I misunderstood. But isn't Github help you filter out such candidates, is it? They have some big projects, but their contribution calandar should be almost empty, cuz all the code is pushed into Github at once.
No one should look at the contribution calendar and hire based on it without looking more in depth. To answer your question it's based on commit time, but because of that you have things like: https://github.com/gelstudios/gitfiti
To all the down-voters, let me rephrase my opinion again. I do take serious look on candidates Github profile, if they include that in their resume. And if they has some reasonable big projects, but they calendar seems empty, I will immediately think that the code is not belong to them. Perhaps that just forks, or, worse, that are stolen code.
I would also check they PR, issue and comments, to get some idea about how they work with stranger; what are important to them when they suggest ideas, contribute to existing code base; how they reply to critic or question from project owner, etc.
Also, just my opinion, most of us - software developers - can't live without OSS. We should contribute back when we could. That's why I usually prefer resume with a non empty Github profile than the others.
I spent the majority of my time working on closed source.
GitHub profiles are incredibly useful for college grads, bootcampers, and self-taught devs that typically can't speak of professional accomplishments.
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.
They are also great in demonstrating knowledge in a new field. For example, if you do C# at your day job but you want to move into Go. Showcasing side projects can demonstrate some experience. This helps sidestep the "well, I don't have Go experience" issue.
This -- exactly. I know of at least one person who's done this and a few others who were able to move into areas of their preferred language (i.e. going from a job that was mainly web/C#/MVC to mainly REST/C#/Angular or React) by doing this.
Even within a larger organization it's possible to use side-project examples as a demonstration that you're ready to move from a team that uses one discipline/language to an unrelated team. While a large organization might be willing to move a senior developer who's a less-perfect-fit from a different department if they've demonstrated that they can be trained/learn what they need to know, it's a lot easier if they can demonstrate that they're a lot more than a "less-than-perfect fit"
Software engineering is highly contextual. As a professional, I write tested, documented code within mature and responsible architectures that harmonize with current and anticipated future business needs, my company's infrastructure, adjacent and legacy systems, pragmatic balance of technical excellence vs. deadline pressure, etc.
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."
> As your professional accomplishments increase, the value of GitHub profiles (for most) as a marketing tool diminishes dramatically, but can still be helpful.
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.
What should be the Dribbble equivalent for software engineers then? All I hear these days is, whiteboards for hiring is bad, asking to do a sample project for hiring is bad, now GitHub is bad. I don't know when software engineers became such "I don't want to show my work" industry.
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 do plenty of extra curricular activity.They don't involve coding.
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.
I do the same as well, I think it is a great approach. It is just a paring exercise, the language of their choice, their equipment, full internet access. We just build something like a calculator or pig latin translator. Something that you build up in layers. I usually read off the test cases one step at a time, in hopes that they write their own tests along the way.
But hiring good people is very time consuming. The reason GitHub as a portfolio makes sense, is that it helps compare potential candidates--that I know nothing about--faster. Biased or not, I have had the best experience with people that are very active publicly. From Battlebots competitors, book authors, to startup founders, etc.
Ivy League Colleges, VCs, even Y-Combinator works very much the same way--trying to make an assessment based on past accomplishments. The more visible, the better. With the caveat being a strong direct reference.
I am sure we all have extra circular activities besides coding, but depending on how strong your experience or professional network is, really depends on how much you need in a portfolio. I have been coding since I was nine and have decades of experience, I still have stuff I hack on that is public, from SlackBots that control GPIO pins to Sonos controllers, etc. I would think the more experience you have, the better chances you would have more stuff you can add to your GitHub (portfolio).
At the end of the day, as a someone hiring, I am going to gravitate to engineers that have more and better examples of their work ability and output vs where they worked on their Resume. Not to say that we should ignore anyone that doesn't have public projects--but they are certainly at a disadvantage against someone that has.
I had two positions open recently. The recruiter gave me 15 resumes, I narrowed that down to 6, spent one day doing phone screens, narrowed that down to three, invited both for the same day then I had them do the coding interview I mentioned above.
I narrowed that down to two and made offers the same day.
You're about a 13% hire rate. Google is about 0.2%, Apple 2%, and Harvard is 7%.
And not everyone wants to work for Google or Apple and not every company needs a Google level employee. Most developers are doing boring line of business apps....
Reid Hoffman has a great answer for this in his book. References are the most important thing there is.
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.
100% Agree!
> that is seemingly too lazy to do any related extra circular activity.
So people with life responsibilities are too "lazy" just because they don't code outside work?
>I don't know when software engineers became such "I don't want to show my work" industry.
Expecting potential hires to labor over portfolios and prepare extensively for auditions is a luxury enjoyed by the few most badly oversupplied artistic fields.
seemingly too lazy
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.
And here you are on HN. It is hard to buy this argument. Instead of reading HN for a week, hack out a little app and toss it up on GitHub. I am almost certain that is more valuable for you than opining here.
Another factor is very large employers having policies regarding open source and requiring each OSS contribution to go through legal.
HN, particularly under a pseudonym, is somewhat more accessible for those under the watchful eye of $BIG_CORP.
I am just tabbing over from looking at a github profile of a potential hire. It was somewhat useful as a way of understanding this person's technology style.
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.
> I saw that he does do OSS stuff, though not much.
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.
If you contribute to any of those large projects then you should have that on your resume/cv with a link to the instructions for pulling down a list of the commits related to your work. Easy Peasy.
> absolutely useless for comparing candidates or getting a full picture of what they've worked on in public.
You're absolutely right. Using a single source as a metric, even if that source is as huge as Github, would be terribly misleading. Though a simple google search would likely surface contributions to Linux/Firefox/Xfce, I don't get the sense that was the point you were trying to get at.
The issue is that there isn't a way to get that full picture. But using Github and other sources out there is a lot better than nothing at all.
I'm not terribly convinced there's a ton of value in it pre-interview, but there's been a lot of value -- for me (both on the giving and receiving side) during interviews.
Here's the thing -- at the time I was involved heavily in hiring developers -- I'd get a few hundred resumes and had time to interview about ... 5 (I was usually the last interview for those candidates) for a given position. It was really important to me that those 5 be worth interviewing. I'd with any links in the resume, itself, and I'd google. I'd happen upon Github, SO, blogs, and even HN profiles. I discarded anything that wasn't code-related[0]. If I don't find anything, I pick up the phone and ask if there is anything they can point me to or send directly to me, code-wise (this was for every candidate that got a phone-screen and was being considered for an in-person).
I get, at best, an hour to judge someone. Interviews are terrible -- I'd argue far worse than anything I can glean on Github/SO. However, combining the two ended up being really effective. Start with a bit of code the candidate wrote and -- after some disarming (i.e. "I know this is personal code and won't be up to your typical code quality -- we all have lives outside of work and can't dedicate the time we'd like to our hobby projects" etc) I start asking about choices that were made (why did you opt for a functional pattern there?) and how they'd improve on it. This gets right into how the developer reasons about code and since it's something they've written (hopefully recently), it's less difficult for them to do than if they're given someone else's code to evaluate[1].
And I've used it on the other side, as well. I received a great offer at a company after flatly refusing to do a whiteboard coding session. It was a job I didn't particularly want[2], so when they handed me a whiteboard marker, I (way more flippantly than I intended) said "I could kludge my way through that using the worst IDE in the world and without access Google, but if you want to log in to Bitbucket on your laptop there, I can show you several different implementations of that which I wrote for a backup application I've been working with for a few years". It was in a private repo, but was all my own code -- I was just a little more embarrassed by it than other projects, but it had the code he was looking for. We went an hour over in that interview and spent 1.5 hours talking about my code. I turned the job down, but it was one of my favorite interview experiences.
[0] Partly because I believed it was the right thing to do -- your politics/pet causes, your silliness/rants/divorce are irrelevant ... life is messy. And partly because it could be a problem for me to know certain things (your religious affiliation, sexual orientation, etc). I don't care about any of those things anyway but managing bias never hurts.
[1] I used to work very hard at disarming my candidates. I felt like nerves tended to hide good candidates and anything I could do to reduce those nerves and make the interview feel like a conversation, rather than a "contest"/"judgment", the better.
[2] Generally speaking, my resume is up-to-date and I enjoy interviewing, so if I'm offered an interview, I take it. Even if I have no intention of finding a new job, provided that my current employer isn't going to be notified about the interview, there's nothing to lose by taking an interview -- even if all you get out of it is a little bit of additional practice.
I wouldn't have been hired for the jobs i've had if it wasn't for my Github. I don't think false-negatives should lead you to disregard the ability to find that perfect developer. Is it not your responsibility as a developer to keep an accurate portfolio of your skill set?
The article's problem is that its arguments apply to trying to use GH as a search tool for candidates.
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."
A software designer at my company can add our software to his or her portfolio because the design itself is publicly-accessible. I can’t add our software to my portfolio, though, because while the final product is available to the public, the code itself is not. So I can point to the software without actually showing my work, or work many extra hours to have a portfolio of code. Which I guess is life, but I think it’s fair to point out that maintaining a code portfolio is far more time consuming than a design portfolio, for instance.
> Is it not your responsibility as a developer to keep an accurate portfolio of your skill set?
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 not entirely true. Candidates have to meet employers halfway.
Employer's have a limited amount of time and money too, why should they waste those resources having to mine for someone's skill level when there's plenty of candidates out there that will display that on some online site.
> Candidates have to meet employers halfway.
Perhaps in a recession, but in the current market, the employer must meet the candidate. That's how supply and demand works.
To confirm (as an example), check out the last HN Who's Hiring [1], and compare to the next one. I assure you, most of the positions go unfilled because demand is exceeding supply. A company can either make their filters more reasonable, pay more, or a combination of the two.
There may be more jobs available than developers, but all of those jobs aren't equal.
For the good jobs, you're competing against other good people. Good luck playing coy.
There were also more women than men in my university, but that didn't free up the cutest girl in the bar.
> For the good jobs, you're competing against other good people. Good luck playing coy.
Everyone does not need the best job. They all just need good enough jobs that continually must improve because demand outstrips supply. See Basecamp for an example; I'm confident developers reading that post began to think about their compensation after reading that.
"Basecamp doesn’t employ anyone in San Francisco, but now we pay everyone as though all did"
https://m.signalvnoise.com/basecamp-doesnt-employ-anyone-in-...
Sometimes an employer has more than one slot to fill, or the business is growing and gets another slot to fill. I may post the same thing next month, but that doesn't mean we haven't hired. There is an ongoing need.
> If an employer can't ascertain your skill level through the interview process, their hiring is broken.
That's just outright factually inaccurate. Are you expecting employers to hire on blind faith? If employers are hiring without evidence to support your skill-set, then their hiring process is broken.
> 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.
I don't have a degree, I got my first job because I walked into the interview with a portfolio; more specifically a fully functional completed piece of software that I live demonstrated. This wasn't an open-source project, but I sent them the code to be reviewed nonetheless (I own the IP).
The reason some people with degrees don't get jobs is because people with portfolio's (irrespective of degrees) can demonstrate their skill-set, where as waving around a piece of paper and having no demonstrable skills makes it extremely difficult for a potential employer to evaluate you.
> It is a slippery slope where we allow employers to dictate uncompensated signaling necessary for a role.
I do somewhat agree with this. However, your portfolio need not be open-source work, it's just common as there's some proof (version control, although not tamper-proof) indicating you did the work you're claiming you've done.
That's just outright factually inaccurate. Are you expecting employers to hire on blind faith? If employers are hiring without evidence to support your skill-set, then their hiring process is broken.
I haven't had any publicly accessible work to show off since I posted a HyperCard stack on AOL and freeware FTP sites while I was in college in 1995. I've been working as a professional developer since 1996, have never been asked to show code and have a pretty good track record for getting jobs based on solely my interview skills and knowledge.
At this point in my career, few companies waste time even asking me about technical trivia. I talk about the projects of the teams I've been on and led. I've gotten jobs over the past 10 years where I didn't meet half of the requirements going in.
Surely the argument isn't that a portfolio is a necessary positive signal, but rather that it's just a positive signal.
In other words, would you take the stance that having some quality work on Github can never work in your favor?
What about other positive-but-not-guaranteed signals like having a quality blog where you cover technical topics? Can that ever work in your favor? Or is it pure noise that can never demonstrate value?
I have to admit my own bias against actually doing side projects. While I will read technical books dealing with high level concepts, I've never done a side project outside of work.
I'd rather try to champion technology at my job and do a proof of concept or if that isn't possible, change jobs.
I've been able to find jobs where what I am good at is a "requirement" and where what I want to learn is a "nice to have" and learn the nice to have.
I find it carries a lot more weight to be able to talk about how you have used technology at work than a side project unless the side project was a really popular open source project.
Then again, I never work for companies with a large development team where I can't have a large, resume building impact.
> That's just outright factually inaccurate. Are you expecting employers to hire on blind faith? If employers are hiring without evidence to support your skill-set, then their hiring process is broken.
I have been working in tech for 18 years, as both an IC and a hiring manager. I do not believe it to be inaccurate. It's how I do hiring in my current role.
I also do not have a degree. In my current role, I was hired on the spot leaving the conference room after my interview. In my role before that, I had three video conference interviews and a take home project.
> I do somewhat agree with this. However, your portfolio need not be open-source work, it's just common as there's some proof (version control, although not tamper-proof) indicating you did the work you're claiming you've done.
I used to be an sysadmin|linux|network|infrastructure engineer. Now I'm in security architecture. What work would you have someone like me show that I did the work I claimed to be doing other than me explaining to you what I did and how I did it? No Github repo is going to be able to properly illustrate the work I've done, or the breadth and depth of my knowledge and understanding.
Public repos are a poor signal. Just my two cents. You want to figure out how people think, that's what an interview is for.
> I also do not have a degree. In my current role, I was hired on the spot leaving the conference room after my interview.
Sounds like a broken hiring process.
Don't get me wrong, I'm not at all saying you're bad it your job. I'm saying your employer got lucky.
> I used to be an infrastructure engineer. Now I'm in security architecture. What work would you have someone like me show that I did the work I claimed to be doing other than me explaining to you what I did and how I did it?
There's absolutely nothing stopping you publishing part of your solutions to Github, along with published articles explaining what you did and why you did it.
You've simply chosen not to, and you've artificially limited your hiring prospects by not doing so. You could have a better job.
> There's absolutely nothing stopping you publishing part of your solutions to Github, along with published articles explaining what you did and why you did it.
Except my intellectual property copyright assignment from both employers. This is pretty standard, even in startups. Your suggestion is unreasonable.
> You could have a better job.
My current job is pretty phenomenal (I do security for financial markets). Definitely interested if you know someone paying more than $230k/year for my skill set. Cash is king.
> Except my intellectual property copyright assignment from both employers. This is pretty standard, even in startups. Your suggestion is unreasonable.
I'm not suggesting you publish their IP. However, you've the legal right to learn (utilise and transfer between employers) skills that you learn on the clock.
You are absolutely entitled to publish (in one form or another) your personal learnings. Your contract with your employer may (if you have an extremely restrictive contract) simply prevent you claiming you're using those skills as part of your current role.
If employers had the right to prevent you utilising skills you learned on the clock, you'd have to somehow unlearn skills and start from scratch at every new job - that's not how it works.
>If employers are hiring without evidence to support your skill-set, then their hiring process is broken.
No one does this. It's just that talking is not evidence enough like it is for other industries because interviewers don't know the right questions to ask. So they add code challenges to fill in the gaps.
It's saying "your previous experience doesn't actually matter that much and we only care if you can actually put code down in the limited fashion of our technical tests". People are naturally annoyed at having to prove they know the basics after 3-5 years in the field.
There's definitely some who hire engineers based on conversation only though. If they can, why can't others?
> If an employer can't ascertain your skill level through the interview process, their hiring is broken.
Easier said than done, especially if you're talking about whiteboard interviews.
Nobody can even agree on what this perfect barrage of probing looks like.
> If an employer can't ascertain your skill level through the interview process, their hiring is broken.
I think the better way of putting that is "Interviewing is broken". Determining that a candidate meets a minimum level of skill-set is possible to do in an interview, however, determining much beyond that is highly elusive. I've had candidates that were incredible "Used Car Salesmen", who the previous interviewers wanted to "skip the technical interview" and just hire the guy outright because he was so convincing only to have his outcome in the technical interview end up being terrible (and I've had candidates get the job where this fact was discovered too late)[0]. I've had candidates that I've had to have a fight nearly come to blows to get a candidate hired because they were so nervous that they completely bombed the interview, and that "accurate portfolio of their skill set" was the only thing, outside of my insistence, that got them hired (out of the few this has happened with, all were good hires, too).
I'm not asking anyone to jump through my hoops (especially now that I'm working at a place where I, thankfully, no longer interview candidates). I don't ask candidates to white-board code (I wouldn't let them if they wanted to), but given a candidate who has a solid portfolio against a candidate who does not -- assuming all other things are equal (or the portfolio is incredible) -- I'm going to hire the one with a portfolio. And I feel it is a personal responsibility of mine to keep that stuff up-to-date. I could do a better job of it, myself, but if I failed to get a job because I lacked in that area, I wouldn't blame anyone but myself.
[0] I blame myself for this one -- he could talk up and down about concepts; was hugely into functional programming at a time when that was less mainstream. He not only knew all of the buzzwords, but he knew the "why"'s behind them. Academically speaking, he was incredibly knowledgeable. It wasn't until he had to actually learn an existing code base and contribute to it that it was discovered he lacked in execution. A manager on his team felt that he "froze up" ... would write something seven different ways and keep coming back to it while writing follow-on features until all he was doing was modifying code he'd already written to yield the same result, just slightly differently. I, arrogantly, assumed he was too good for the half-rate programmers we hired but upon running into someone who worked with him at the company he came from, it was discovered that he was not actually employed by them at the time he was interviewing as he'd been let go a couple of weeks prior ... and he had the same problem there.
>Is it not your responsibility as a developer to keep an accurate portfolio of your skill set?
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.
> Is it not your responsibility as a developer to keep an accurate portfolio of your skill set?
Lots or most devs don't need to.
While much of this article hits upon the right points, I’d like to add a few things.
- 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.
The argument that "GitHub isn't a useful indicator of skill" has the logically-following argument "we won't look at GitHubs at all because they're a waste of time." Which is a loss of helpful information for hiring a candidate, and ignoring relevant information seems inefficient.
Nobody actually wants to make the most informed decision, what they really want is to make the right decision. There's all kinds of places where additional information leads to worse decisions:
https://ignoranceanduncertainty.wordpress.com/2011/01/31/whe...
So you may in fact want to ignore relevant information to be more efficient.
Most people realize that "Github isn't your resume" unless you are paid to work on open source. Forking repos, submitting the occasional pull request or a random side project don't provide much signal compared the code you've written and the people you've worked with at past companies.
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.
You need to provide a privacy policy for this service.
Thank you for the reminder! A privacy policy has been added to the website.
I find this stuff fascinating, partly because I work in the industry and partly because I love sports statistics.
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.
According to the article I am clearly in the identified top 1% of GitHub users by commit quantity. While prospective employers may not dissect the code in my various GitHub repositories this certainly hasn't hurt when looking for jobs.
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.
Nonsense. The last two full time jobs and several gigs I've landed in the last five years I provided the hiring manager with a link to my public profile on github in lieu of a resume.
The author addresses that point in the introduction:
“As an example in the latest Hacker News' Who is Hiring thread, there are a bunch of different job ads asking for a Github profile as part of the job application.
...
While both of those posts give excellent reasons to reconsider asking for open source contributions when hiring, my take here isn't about why it is ethically dubious to require open source contributions or why GitHub isn't great for showcasing your projects.
Instead, this post is about why GitHub profiles just aren't all that useful when looking to hire developers.“
And my anecdote is that I provided a resume for the last 7 jobs I've had. I've never had a problem getting hired based solely on my resume and an interview.
What I think a lot of the comments are missing is that, sure, a strong GitHub profile can be a positive signal for hiring, but an inactive GitHub profile is not a negative signal.
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.
I very much check GitHub profiles when hiring. Even if a person has a simple project on there it shows they have interest in coding, and I can see their style of coding. That's enough to swing my judgement when I'm deciding between two candidates that are close. GitHub alone won't get you the job, but it certainly will play a positive role in your profile.
If we are being interviewed like carpenters, a carpenter's work may be a lot of effort to create and then none and it still remains created. Why is the age or spontaneity of the commits a factor? Yes I am working in a professional capacity and can't show any of that. Why not look at the table I created 2 years ago?
> "Interviewers Don't Check GitHub Profiles"
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.
The only question I can answer with GitHub is "can you use git." If I'm reviewing a candidate who says they are familiar with git based workflow and they provide a link to their GitHub with > 0 commits, check. If not, consider exploring in an interview.
So of the 7.4% of users who pushed more than 10 times in the last year, how many are bootcamp students? (after you remove the big,open source projects like all the big companies have up there) I just think these students should know this.
I think that "having github will help you" is the same kind of advice as "prefer to provide resume in pdf over doc".
There are people who believe in it, it seems reasonable, but in reality nobody cares. Just another cargo cult.
When I am hiring, I tend to use a github account with an active project as a positive signal.
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.
I rarely look at candidate's GitHub profiles anymore. I used to do it, but I didn't get much value from it, and I didn't notice any correlation to job performance.
One thing that have always annoyed me about Github is the lack of (free) private repos which makes the activity history patchy. So you show that you're active for months on end, then then radio-silence for a month. Or when you delete/move a repo and suddenly months of activity disappears. Just makes it look like you've lost interest in what you were working on =(
Please don't do this -- GitHub does not register activity or hobbies outside of GitHub. You are arbitrarily ruling out people on BitBucket, Gitlab, and elsewhere, in addition to the legions of programmers that cannot post their work publicly and do not want to produce stuff on their own, unpaid, time.
Even if you do work on GitHub, when a repo is deleted, your activity on that repo is also deleted.
You can have the activity graph show private contributions.
edit: I may have misunderstood, assuming you mean it's patchy because you're contributing to a private repo that's not on Github.
I use Microsoft's Visual Studio Team Services - their online hosted TFS version (yes they use Git). They give you free private repos, complete project management, either a hosted build server or you can use it to orchestrate your own private build agent, a wiki and a lot of other features.
I am starting a side project mostly for learning but have no real interest in making it public.
Having personally used GitHub to aid in hiring developers, I find it to be a very valuable resource ... provided it's used correctly. The author makes a few points that I would have considered somewhat obvious (i.e. social networking is not a metric that indicates a successful developer) and he's correctly pointing out that using it superficially as a sort-of "metrics engine" for developer candidate quality is going to yield poor results.
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.
Interesting, thanks. Do you specifically ask the candidates if the code in their repository is all their own work? One small thing that worries me about relying on GitHub is that I can't be 100% sure that the author actually wrote all of it.
Yes. But mainly only to direct my questions. Whether or not they were the primary author was mostly only important in knowing how well they knew the code in question. If it was written entirely by someone else but they fully understood the code, that worked for me, too.
It was more important to me that a candidate could reason about the code in question -- even (perhaps especially) if it was an implementation they pulled directly from an SO post. There were occasions where I'd see unique implementations of common tasks (i.e. pulling a value out of a URI string that carried an unusual formatting pattern where simply using the URI parser in .NET wouldn't have worked directly). Having worked with a few different frameworks that use unusual URI formatting, I might ask why a regular expression was used over writing a custom parser tied to the Uri type (or vice-versa) and I was more interested in hearing the argument and reasoning behind it as well as whether or not the candidate could come up with pros/cons for both methods. Sometimes it'd be a custom implementation for something that could be done directly with features available in the framework -- and often the answer was obvious[0].
And a little humility doesn't hurt, either. I remember asking why someone used a regular expression to do some rather involved data extraction from an HTML source versus using something like Angle# and I recall the response was something along the liens of "Well, it started with pulling just URLs for a limited case and exploded into getting some metadata around the link, but it was for something at home and I put a total of ten seconds into thinking about how to do it right and if it stopped working completely, it didn't affect me all that much". Good enough; a lot of developers would go off into tall weeds defending bad code rather than just saying "sometimes the tolerance for error greatly exceeds the availability of time" or "I just didn't care enough" -- especially in an interview where you are hyper-sensitive about looking bad -- and we all have a bunch of very dirty scripts that "work ... mostly". Provided it's not a theme of ambivalence throughout the interview, a little honesty at a time when it's tempting to fluff gave me confidence that when that developer made a mistake, he might actually own up to it.
[0] It's either "I didn't know it could be done that way" or the most common "I wrote it before that method/call existed" -- since I was hiring for .NET positions at a time shortly after Framework 2/3.5, this was a really common situation due to many new ways of doing things arriving with Generics/LINQ. And both were acceptable answers since it took some time for a lot of .NET folks to grok generics/LINQ and understand them well enough to realize the appropriate place for them (outside of just "oh, I can make a List of anything without having to use ArrayList of object types")
Why are we reading this post?
"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?
The amount of anecdote-fueled blog posts by nonexperts (or worse, beginner experts) in tech is staggering. I don't know what causes it but it seems to work as this is in the front page.
I'd wager this is the kind of HN post where people read the title and post in the comments without reading the post at all.
That's really not a charitable representation of the article. When the HN guidelines say: "please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize", it applies to authors as well as commenters.
Well, it is an honest question. And I don't think it is uncharitable at all. The premise of the article is that github does not help with interviews but it doesn't really provide facts to back that up.
He didn't claim to be an expert, and certainly not because of one interview. You cherry-picked a passing detail and used it to make him out to be an idiot ("So that makes this guy an expert?"). That's the kind of cheap shot the guidelines are written to preclude.
It provides plenty of facts and data, but few anecdotes. That seems like a desirable situation.
I don't want to get into a comment war here. Let's just say I respectfully disagree that there is plenty of facts and data, and that what facts and data are there area really more of an opinion with thin data that seems to violate the new guidelines that are being brought up to say that my comment is out of place. In my opinion the author has gone out of his way to cherry pick data to support his claim and has not put effort into finding data that would prove him wrong.
You are welcome to your opinion about the quality of data provided by the author. But your original comment was attacking the lack of personal experience/anecdotes. That wouldn't improve things much, one way or another.
Should have been clearer here: I've only been interviewed once, but I've given hundreds of interviews over the same time frame.
Github projects don't need to be impressive or have substantial technical depth to provide a positive signal.
For example, a good README can communicate someone's abilities in documentation, thoughtfulness, and design.
Stitchpunk needs to :set expandtab
Even when combined with your WakaTime profile to account for code written at work?
For ex: https://wakatime.com/@alan