* 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.
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.
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.
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.
First time I'm hearing about such a policy. Can you explain the reasoning?
It's most likely an overly broad means of protecting against employment discrimination.
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.
In the specific case it is probably overblown, but HR fears aren't entirely rational.
