I've noticed that your github profile doesn't even get looked at until you jump through all the standard phonescreen/homework hoops.
Even after than many interviewers look at your resume like 10 minutes before the interview there is no chance that they would read through your code on github. github as your resume is overrated.
I am curious to know if people hire or get hired purely based on their github profile without a technical interview.
* If you don't provide a link to your github profile, I'm not supposed to look at it. This an HR requirement. Other companies may use this same policy.
* I definitely look at github, but it's not always easy to tell if a project is original or not. Quite often I'm presented with either 30 forks, or a few projects that seem like they started as some boilerplate.
* Don't just provide github, also provide a specific project to look at. Even better, point out a particular section that you are proud of.
* Even with a well-stocked github, I will still ask you to code. This likely isn't to tell if you can code, but to figure out what it would be like to work with you.
It's really, really easy to tell what contributions were made to a project by the person whose profile you're looking at. There's literally a "contributors" section where you can click on them and see every commit they ever made to that project.
Also, asking someone to code in front of you is a terrible way to figure out what it would be like to work with them.
1) It's an artificial non-cooperative environment.
2) It doesn't tell you anything at all about how they present and communicate their ideas.
3) The absolute best-case scenario is you figure out one degree of conscientiousness, which isn't enough to build a working profile model of them.
I'd be curious to know if you know the personality profiles of the people you already work with, which profile framework you use, if you know what composite mix of profiles will lead to meeting your institutional success criteria, and then how you go about assessing a person's profile to fill the gaps that you have in that composite.
I over simplified to make a simple bullet list. This is not a "code in front of my while I sit in silence" kind of thing. It's collaborative, it's discussing requirements, strategies, etc. It's back and forth and suggestions. It's also open Internet and questions are encouraged.
FWIW, we follow-up on what candidates thought of the interview process and it is overwhelmingly positive. I don't think it is overly stressful. Although, I'm not sure it's possible to make an interview not stressful at all! :)
EDIT: It's simple if you think of it in terms of a single project. But, if you think of it in terms of many, most of which are no contribution or a small bug fix, it can represent a large time investment. That's why I recommend candidates point out a specific piece of code.
Well, I'm not sure how you're correcting for bias in the feedback. For the same reasons you don't think it's possible for an interview to be not-stressful at all; you also can't get feedback about that process without the bias that they're not going to want to tell you that your process might be bad.
You'd more or less need to get feedback only from people who are already happily and gainfully employed who are also close to neutral on the 'agreeableness' spectrum.
At any rate. You can remove the stress from an interview mostly the same way a therapist can remove stress from iterative therapy. By building an ad-hoc environment of trust, safety, cooperation, and goal alignment.
Hiring is probably the most important thing you can do in/for any company. It should be a time investment on your part. If you don't feel like you're given enough time to do hiring correctly, then I'd suggest setting different expectations with your leadership about how to use your time or what quality of candidate to expect given the time you have.
Seeing a bunch of bug fixes across many projects tells you a lot about that person. So rather than going into the process looking for an extremely narrow thing (like some big project they are the sole maintainer of); go into it looking for anything that's there and see what kind of information is there to help you construct a useful narrative/model of that candidate.
Lots of bug fixes across many projects may not indicate that they can own a singular vision from start to finish (though you can assess that from getting them to tell you a story about literally anything), but it does tell you that they can read other people's code, supply feedback in the way of working alternatives, will take the initiative to solve a problem themselves rather than wait for the maintainer or someone else to get around to it, and focuses on getting things working rather than design-paralysis.
My issue with the whole "github resume" thing is all my best code is in private projects because they are related to serious side projects I intend to monetize. I suspect the same could be said for any other developer who is serious about their side projects.
Exactly. A frequently under-appreciated fact. Another one is that much (complete/quality) code may be from past employers/clients, which you have no right or ability to display publicly.
>>* If you don't provide a link to your github profile, I'm not allowed to look at it. This an HR requirement. Other companies may use this same policy.
First time I'm hearing about such a policy. Can you explain the reasoning?
I don't know the specific reasoning behind it. It's not specific to github. We aren't supposed to look at any reference that isn't provided by the candidate. This includes linkedin, facebook, etc.
It's most likely an overly broad means of protecting against employment discrimination.
Considering that much of what's on people's Facebook pages is against the law to even ask about (in some jurisdictions) it's probably a wise choice. Stick to what's provided by the candidate. I provide a link to my LinkedIn page on my résumé, but nothing on it touches on areas I know would cause problems. Most of my coding is in private projects so I generally don't bother with listing my GitHub.
For example, I know that where I am it's against the law to ask if someone is married during the hiring process and that's pretty clear on many Facebook pages.
You google the candidate. You find a webpage that matches. It talks about the candidates works for the gay/lesbian alliance. You don't hire the candidate because he sucks. He sues your company, alleging that you discriminated against his gayness.
In the specific case it is probably overblown, but HR fears aren't entirely rational.
Various states have laws that amount to information about the candidates past or current conditions that should not be used for job decisions. HR is there to protect the company, so they often will tell people what they can consider. Think of it as the human equivalent of not being able to comment on crime data when selling a home.
Same here, companies don't ever look at my Github code.
I built up a portfolio partly in the hope to make future interviews easier, but it hasn't worked at all!
I remember reading that comment about Google... even though a ton of people at Google use Homebrew. The question is, what would would you be writing at Google? Would you be reversing binary trees? Would you need to instantly know which sorting algorithm would be most efficient at the drop of a hat? or would you be building more tools like you already have. The one thing that isn't immediately clear from your GitHub is if YOU wrote the code and HOW you wrote the code. I'm not defending worthless practices like asking you all kinds of CS riddles that the interviewer doesn't even remember... but I am saying that there are reasons to test your ability to reason through a legitimate problem. Because of this, I am a huge fan of this style of interviewing: "We have a problem... tell us how you might approach solving this. What resources would you use? Why?"
"The one thing that isn't immediately clear from your GitHub is if YOU wrote the code and HOW you wrote the code."
Spend a few minutes looking at the commit history and all shall be revealed...
If you can copypasta a complex project with >dozens of active users and a commit history showing that you've made improvements to it over time, I'd argue that it's hard / pointless to distinguish that from actual programming. If you can ship working code, support it over time, and enough people appreciate what you've created to use it regularly / rely on it, why does it matter if some parts are even verbatim copied from SO or elsewhere? Thought experiment: compare this to using a library someone else wrote.
That "github is the new resume" meme a few years ago was quite funny, in retrospect. People panicking that they'd never be able to get another job, as they didn't have free time to code at the weekend...
Curious what you're doing that you never have to even reference GitHub or SO. That seems strange to me in 2016, unless e.g. You're only using some language / framework / libraries that your company made / paid libraries / .NET and all the documentation and ecosystem is private.
I've attempted to use StackOverflow, but by the time I have questions difficult enough to go there they're well above the level that SO is capable of answering. (At least, not without bribing people with rep, which I don't have because I don't use StackOverflow.) So it's pretty useless to me.
As for GitHub, I've downloaded libraries from it, but I have a pretty healthy dislike of Git, which is awful, and refuse to use it for any personal projects. (I only use it at work because I have to-- in any case, work repos are of course private.) I used to have a few projects publicly available on Google Code, but now that's shut down, so there's really just nothing. I do have private repos for my hobby work.
In case it matters, most of my development is in C#.NET.
I believe usability is the most important trait for a software product, and not only does Git have terrible usability, but its designed in such a way to make it nearly impossible for anybody else to improve its usability. (Although they can improve it's accessibility somewhat-- not everybody is capable of using a CLI interface.)
And it's in a product space (revision control) where the average product's usability is already bottom-of-the-barrel. It's kind of impressive in a way they managed to deepen the barrel a bit.
I'm forced to use (struggle with) Git at work, over my objections. There's no way in hell I'd use it for a hobby project where I have a choice.
I see just sharing my opinion of Git is enough to get voted-down on this site. Oh well. Vote me down. "Person dislikes something popular!" is obviously worthy of derision.
Wait is this a thing now, "send us links to your StackOverflow questions"? If you don't ask questions on StackOverflow you might not be a good candidate? What complete nonsense. Whats next my Uber passenger rating? There is something so ridiculous about this.
We literally never hire someone without a technical interview, but we do look at github/bitbucket/gitlab/whatever code we can find the day or so before the interview. If there's something interesting we'll ask questions about it during the interview.
So far, there hasn't been one candidate that had anything resembling a portfolio online, but we don't hire all that often and i've only been doing it for a bit over a year.
It shows something slightly different than a github profile since it doesn't typically show full projects but both can show off competence pretty well IMO.
Someone with a well written technical blog or good github portfolio is definitely going to have an advantage in any hiring I do.
I'm a college senior and I've gotten interviews based on my Github activity, but still have to go through the interview ceremony. Most interviews I get start by mentioning my projects.
Even after than many interviewers look at your resume like 10 minutes before the interview there is no chance that they would read through your code on github. github as your resume is overrated.
I am curious to know if people hire or get hired purely based on their github profile without a technical interview.