[danielharan]

"You will begin to get the (objectively) best candidates"

If "it's [everyone's] job to say no-hire" when they're "not sure" about a candidate, I'd like to know what is done to avoid systemic bias in hiring decisions.

Anyone here from FB able to comment? How diverse is the work force, especially compared to applicants?

[yishan]

Hi, I'm the author. Someone alerted me that this showed up on HN, so I figured I should come by to clarify.

I believe my statement might be clear. What I mean by that is "it's [everyone's] job to say no-hire," as opposed to anyone feeling like "well, I'm not sure about this candidate, but I'll let someone else reject them because I don't want to be perceived as mean." One problem with hiring is that everyone must be willing to uphold the standard - if you have too many people who are never willing to be the one to say no-hire, the standard will fall - everyone has to be willing to take the responsibility for saying no.

That said, systemic bias is an orthogonal (and real) issue. Being "not sure" should be applied to "does this candidate measure up" not "is this candidate a lot like me?"

[cpeterso]

Saying "no hire" can be hard for some people, but becomes easier if your team adopts the attitude that "maybe means no". It's probably better for the team to miss out hiring some promising "maybe" candidates than later trying to fire a bad one.

[danielharan]

Good to know. Does Facebook collect data about how they're doing internally to avoid these systemic biases? Is this tracked?

Although it appears orthogonal, if everyone starts making hiring decisions without any checks and balances that an HR person would put in, I'd assume more bias to creep in. At the very least, I'd want the "standard" to be clearly defined.

[tgflynn]

One of the things that strikes me about what I've heard about hiring practices is that they all seem primarily focussed on keeping the wrong people out rather than on finding the right people.

Does anyone consider the possibility that there might be really capable people who don't fit the model that N developers have of what a good candidate should be ?

[gvb]

Here is a personal anecdote on the cost of not hiring a right person.

I have a very strong background in low level (embedded as well as device driver) software development. I have a long and visible track record in U-Boot development, including being a sub-repository "lieutenant".

Canonical advertised for a "Ubuntu Mobile Developer - ARM" developer for which I felt (and still feel) I was a very strong candidate. I submitted my resume and got no response. I did some searching and found the contact within Canonical who was responsible for the position and got an immediate response when I contacted him.

I did a phone interview with a Canonical employee, not the person hiring but another who was a technical expert. I thought the interview went well overall, but he seemed disturbed that I had not actively used Bazaar even though I had used other DVCSes, including evaluating several of them for U-Boot - I ultimately recommended git for U-Boot. I've also used Mercurial extensively in my job, so I would say I have more than passing familiarity with DVCSes.

Anyway, I didn't "make the cut" with Canonical. I've since gotten a new job and am no longer in the market, but Canonical is now advertising for three software engineers for that position http://webapps.ubuntu.com/employment/canonical_SE%20PS%20HB1....

The kicker? Canonical did not have "familiarly with uBoot" [sic] as a desirable qualification for candidates before I applied. They added it immediately after I entered their interview process. In other words, Canonical did not even know they were looking for me before I applied, discovered that at least one of my qualifications were important because I applied, and yet did not hire me. A year and a half later, not only have they not filled the position, they now have three copies of the unfilled position.

Go figure.

[psaintla]

I once worked for a company that hired the way Facebook does and it is a recipe for disaster in the long term. Two things brought an end to the practice but it was too little too late:

1.) Employees were agreeing to hire people who weren't as skilled as they are because they were afraid of newer and younger competition. As each generation of new hires were brought in they were successively worse than the previous. The most senior employees saw the degradation of overall talent level and eventually left for greener pastures. The company slowly ended up becoming composed of people who were barely qualified for their positions and several years after I had left they were bought out for pennies.

2.) They were sued for discrimination, it was a ridiculous accusation, but the company had to settle. The reason was that without consciously trying we had all hired people who were of similar backgrounds to ourselves in many regards. Apparently "One of our team members wasn't sure about her" doesn't cut it in court.

[aprrrr]

Sure there are. The standard rationale is that when hiring, the cost of a false negative is far lower than the cost of a false positive.

I guess it's also true that the cost of a false negative is unknown and not felt. It would be a really extreme case to be forced to say, "Hey, remember that woman we didn't hire two years ago? She went off and founded Company Y that's now eating our lunch." With a false positive, you feel the pain of cleaning up their messes until after they're gone.

Finally, sad to say, the majority of job applicants are not competent to do serious engineering work. A negative bias is right most of the time.

[tgflynn]

Finally, sad to say, the majority of job applicants are not competent to do serious engineering work.

I've often heard this claim. I have no data for denying it.

However I have a suspicion that when people make this claim the observation that it is actually based on is that "the majority of job applicants aren't very good at answering programmer interview questions.". They are hence making an implicit assumption that not being good at interview questions implies not being competent to do serious engineering work. I think this assumption is highly suspect, because of the extreme differences in stress levels, time scales and general context between interviews and actual work situations.

[aristus]

That is a very good point, but what alternative do you suggest? Keep in mind that hiring can consume a lot of existing employee time.

[silverlake]

Strongly encourage applicants to contribute to any open source project. Reviewing this code will tell you more than any stupid programming question. This takes less time and can be done asychronously. An interview can be used to determine if the qualified applicant will fit in your culture.

And if they haven't contributed any open source code, then whack them with stupid programming questions.

[tgflynn]

I posted this comment on the subject a while ago that describes the process I would use:

http://news.ycombinator.com/item?id=1966689

The responses were interesting, ranging from "that would never work" to "that's what we do and it works great".