Hacker News Reader

Comment by baskethead | Hacker News Reader

Your technique has already been proven to create unconscious bias, because you are more likely to hire people that are like you. You even said it yourself, you want to work with people that you like and that you get along with.

Here's one of hundreds of articles that talk about this:

https://www.forbes.com/sites/forbescoachescouncil/2018/05/01...

Unless there's data that backs your choices vs the ones that you rejected, all you're doing is reinforcing particular stereotypes in your company and in the software industry.

View on HN

> You even said it yourself, you want to work with people that you like and that you get along with.

And you.. don't?

> Unless there's data that backs your choices vs the ones that you rejected, all you're doing is reinforcing particular stereotypes in your company and in the software industry.

I've gotten plenty of training that makes it extremely clear that discrimination based on protected classes is unacceptable in all contexts, especially interviews.

At some point, you have to trust your team to build your team. Not everything can be blindly metrics driven.

You're hiring humans to work with other humans.

The point is to hire people who mastered skills different than what you have. You see interest in text editing as a major factor, but there are probably many software engineers who have no interest in text editing and just writes stuff manually with no focus on tricks, and are still very productive since really writing 100 lines of code is just a few minutes of typing but still plenty for a days worth of work.

> The point is to hire people who mastered skills different than what you have.

That's the job of the other engineers. I only know how to screen for the skills I do have.

Most engineers spend all day in their text editor and on Google, debugging code and searching for solutions.

I have never met a good craftsman that doesn't customize their tools.

I'm not saying everyone has to customize their editor. But if you move quickly and intuitively through the chrome debugger, the only way you got that skill was by doing it every day for way too many hours.

Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.

I customize my shell and tools all day. Editor? Not so much, CUA FTW. In fact had to think five minutes before I remembered my snippets. They’ve been in git for 5-10 years.

> That's the job of the other engineers. I only know how to screen for the skills I do have.

But to strengthen a team you want to add people who have skills the other people in the team lacks, so your interview needs to be able to find such people easily.

In general you want the interview to test that they have done the basics of the work before, that they are smart and that they are nice. Your test helps assert the first, they have done the work before, and the discussion tells you whether they are nice. But it doesn't tell you whether they are smart. And if you think a bit there are probably simpler questions you can ask to check they have done the work that are more general and will pass more people, you want to sort by intelligence and not passion for text editing so the "have they programmed before" question should be as low level as possible and not require any special skills.

The algorithm interview is what the industry settled on to solve this. It tests extremely trivial coding, so you can do the coding if you have ever coded before. The hard part is the algorithms, and that might require some to study, but since it is standardized that becomes a reasonable proxy for intelligence. And social comes from being able to talk about a technical problem and describe what you are doing in a stressful situation, that is good enough to work on a team.

> Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.

This is true, but you don't need to customize anything for that. VSCode text search gets you 99% there.

> I have never met a good craftsman that doesn't customize their tools.

To the contrary, personally I even take some pride I can work on any PC you can possibly give me immediately. This has tons of upsides - from helping someone walking over to them, to knowing tools in their default configurations inside out and explaining keybindings or quirks that are guaranteed to work (and writing better docs).

Programming really isn't about my personality, I want to strip any of that and produce the least amount of very default, simple code anyone can work with. And you don't need to type fast or use scripts to produce that small amount of code.

Largely same goes for debugging, I better create a good logging and monitoring system than spend time tweaking my tools, because that'll immensely benefit the person who maintains the code after I'm gone. Nobody will install my personal tweaks to catch bugs. Granted I mostly work with very good tooling already (C#).

>I've gotten plenty of training that makes it extremely clear that discrimination based on protected classes is unacceptable in all contexts

There are plenty of cases where discrimination against unprotected classes still happens. Cases where studies cannot find a correlation between selected candidates and things like retention rate, performance etc. These include cases where one would be skipped over despite having personality attributes the team is sorely lacking.

>You're hiring humans to work with other humans.

It's because we work together as humans, most of the things you said don't really matter. Most humans can work together despite their differences. That's one huge problem with hiring as a whole, trying to find carbon copies of each other while espousing they value diversity.

That's not to mention all this "one of us" hoo-ha just stimulates chameleon behavior. Which benefits the person opposite of you, but it doesn't do you much favor in the long run.

> And you.. don't?

The problem in this situation is that YOU are the one acting as a gatekeeper as to who gets into the company.

The company should be the one setting the standards, and determine the best person for the job, and you should be able to work with whoever is best suited for the job, regardless of whether or not you like them.

This is where the unconscious bias comes from.

If he said it himself, then it’s not an unconscious bias, is it?

The point of interviewing is bias in the first place - to find people who are good - and it’s not unreasonable to assume that “I want to be good” and “this potential hire is good” would result in correlated features

If one can’t escape or compensate for it, then it doesn’t matter if it’s conscious or unconscious bias.

You can escape it by becoming a better software engineer.

Up to the limit of your IQ, which is the real bias that everyone sweeps under the rug, especially all the bigtech companies espousing “inclusivity” (all lies, actually exclusivity, as they don’t hire most people, especially stupid people).

> You can escape it by becoming a better software engineer.

Why? Are better software engineers less biased? Why would that be? I would assume that they are human, and therefore just as prone to biases, like everyone else.

Rationality doesn't work when studies have repeatedly found virtually no correlation between 'someone good doing hiring as they like' and good candidates in the context of retention, performance, and more.

Even rationally it doesn't make much sense. You're judging people on what they do in a year given how much an individual likes them and believes them to be good given a day's worth of input. Even if such an individual finds a lot of 'good' hits, nothing would tell them if it was this particular selection mechanism, other selection mechanisms, the workplace, luck, or none of them. The same goes the other way around for 'bad' hits.

Not to mention, if rationality worked, we'd see 'years of experience' have great correlation with 'good' candidates. Yet YoE always fails to contribute greatly given the presence of other metrics.

Cool, next time you're hiring, remember this and hire someone with no experience, no technical interviewing, just by "divine inspiration" (a.k.a. your emotions) and/or chance.

The other alternative is soullessness via standardized tests. Why? Isn’t it better for people to hire people?

Reply on news.ycombinator.com