[notsureaboutpg]

>For a while we've had a take-home test and that has increased our success rate somewhat. But as you say, we really don't want to lay unreasonable expectations on people who may have other obligations

These are mutually exclusive things. Candidates who have more free time to code are more likely to be better at it than those who don't (all else equal). Candidates who have OSS maintenance / leadership experience are more likely to work well in teams (all else equal).

If you choose not to weight those things, to balance the playing field for people who have more obligations outside of work, then you'll also have lesser quality candidates (again, generally).

So if you're struggling to hire good candidates, maybe it's a good idea to weight these things (and bias against people with less free time outside work). Once you have good candidates, and this is no longer a pressure on your business, then it might be a good time to try and balance the playing field for new hires.

But you cannot balance the playing field and also hire the best candidates. The best candidates will have unfair advantages in general. You can either lean towards having the best or lean towards balancing the playing field.

[sokoloff]

We should try to eliminate irrelevant biases in the hiring process but we are fundamentally trying to select people to hire who will join our company and write good code. That quality is not evenly distributed in the population.

Some of the gymnastics thinking that I see seems to suggest that we’d seek to hire fluent English speakers by interviewing evenly across all populations. By all means, I’d be more than happy to hire someone fluent in English from China, but if I’m looking for a fluent English speaker, I shouldn’t spent 18.5% of my recruiting efforts/budget in China out of "fairness".

[potatoz2]

People in China often don't speak fluent English because they grow up in a country where it's not a spoken language.

People who don't contribute to OSS typically don't do it because they don't have the ability (some OSS code is held together by duct tape) but because they don't have time, interest or think it's harder than it is.

If you have better tools to determine if someone is good at writing code for your company, why use a proxy measure that's different in many ways?

[sokoloff]

Unless I’ve worked with you or someone that I deeply trust has and will vouch for you, I don’t have any stronger signal of your coding and teamwork abilities than a strong OSS contribution history can provide.

It’s rare for an interview process to provide more than 6 hours of content, some of which is non-evaluatable. Reference checks are all but useless compared to seeing actual work over time.

About 1 time in 6, you’ll interview a full standard deviation above or below your “true” ability. About 1 time in 50, you’ll turn in a +2σ (or -2σ) performance. That’s largely eliminated with personal experience, a trusted vouch, or a strong OSS portfolio.