No, but almost none of them are “good” if “good” is defined as “eliminates all influence of biases irrelevant to performance such that superficial things like appearance play a role not explicable by their ability to predict performance.”
People who are not serious about hiring think this is the goal.
This is not the goal. The goal is to bring people on board who will successfully utilize your resources to bring success to your organization.
Eliminating bias is a red herring. You’re better off trying to increase your bias so that it statistically gets you a higher chance of hiring the people you want.
My most cynical reason for seeking to reduce bias is because I want to hire — as you said — people that will bring success to our organization, without my biases clouding my judgement.
> You’re better off trying to increase your bias
Care to elaborate? That sounds like a terrible idea to me, I'd prefer to hire people based on their skills, not my biases. From the study:
> we do not find a strong correlation between “looking the part” and job performance
If you ask two separate candidates "what is 1 + 1?" and one responds "2" and the other responds "37" but played a card game when they were young, would you hire the latter? (hypotheticals are cheap, but you get my point)
You used the word “mitigate” but in the same post also expressed surprise that any bias effect was left at all, which indicated you expected elimination of the effect from a “good hiring process" rather than mere mitigation.
You responded to a post saying that the effect exists (neither characterizing magnitude nor what the base rate would be without mitigation) and said you were surprised that was the case.
If you only expect mitigation, there would be no basis for surprise, of any degree, at the mere fact of the effect existing.
If it was mitigated somewhat, the effect would still exist.
The issue is the expression of surprise with the mere statement that the effect exists. I’m not confused, you said two things that don't make sense together in one post, each of which is perfectly clear.
Semantics. Seems to me like OP was talking about the entire project of making and releasing the newest version. QA would most definitely be apart of that.
Speaking of bricking devices. One of Apple’s greatest shames was releasing Apple TV 4K, which lacks a USB port. This model could only be unbricked by Apple, until iOS 17 made it possible to do so via the iPhone recovery feature.
There are often arguments about what is "bricking" when these things happen, so here's my take (having dealt with embedded device ecosystems for a decade+): "Bricking" is when a device is put into a state that can only be recovered from by using specialized repair/recovery tools, opening up the case (for non user-serviceable devices), or software not legitimately available to the public. Apple Silicon devices are mostly "unbrickable" because you can always recover using DFU mode. In fact they are probably the most unbrickable consumer computing devices in existence, due to how thoroughly a DFU wipe restores everything (not just all software, but even device calibration and settings get downloaded from a server). DFU wipe is documented, relatively user-friendly, and requires only publicly available software and another Mac, which makes these unbootable states not a "brick". In contrast, most PCs are brickable: just wipe or corrupt the BIOS Flash. Most of the time this isn't super easy to do, but it's rarely fully protected and there have been many instances of something as simple as setting UEFI variables wrong bricking x86 machines. The exception here is x86 motherboards with a "BIOS FlashBack" type low-level recovery feature, which is as close as you get to DFU mode in the x86 world. Most Android devices are brickable too, and very easily at that. Just deleting/corrupting the wrong partition on disk will make your device unrecoverable. While in principle they have DFU-like recovery modes, the tools to use them are almost never made available to the public (you need vendor-specific tools, fastboot won't work) nor are they intended for use by end-users, which makes this qualify as a "brick". There is also no mechanism to recover calibration data like Apple has. There is, however, a tangential aspect: data loss. Any mention of bootability issues should qualify whether the fix makes you lose all your data or not. For example, on Apple Silicon, deleting the first partition on the disk is a very quick way to end up with an unbootable device where the fix requires a full wipe and losing all your data, even though it's not a "brick". For this reason, I would say Apple Silicon is much better than x86 at system recoverability, but is worse than x86 at data recoverability.
The average user is going to have a heck of a time fixing it. They may not have a spare Mac, or a friend with enough tech know-how to help them. It is effectively bricked since they'd have to go to an Apple Store.
reply