* 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.
* 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.