Don’t judge a book by its cover. Don’t judge an applicant by their headshot.
Drag this to your bookmarks bar to remove applicant avatars from Workable.
No Avatars on Workable
The most important components of UpBuild’s experience are the relationships we foster between team members and with clients, the quality of our work, and the results we’re able to help our clients achieve. Just as there’s nothing to support the belief that someone with an incredible headshot can do all that, there’s no reason to believe that someone lacking one can’t.
Workable, while super useful for us, brings in headshots…sometimes. Sometimes there’s just a grey placeholder. Sometimes, I’m not sure where the headshot even comes from. I’m wary of how “seeing” a given person might subconsciously influence my feelings on a candidate. Something as simple as color in an image, photo resolution, or the lack of one entirely could skew things unfairly. Who knows!? I don’t. That’s why it concerns me.
Why Hire Blind?
I spend the vast majority of my work time as the CEO of UpBuild behind my computer screen(s), reading words that others have typed into theirs. don’t share physical space with them. I don’t see their faces most of the time (though I do enjoy and recommend, once someone’s been hired, that they have an avatar/profile photo). Yet, I know when they’re firing on all cylinders. It’s easy to tell when they’re not.
It’s all illustrated in the quality of their written communication. It’s in whether or not I can see their care, curiosity, and passion in a Slack thread or the empathy that comes through in an email to a client. It’s in the meticulous attention to detail and the small touches in a formal deliverable.
That’s why I prefer to do — for lack of a better term — blind hiring. As I’ve written before, I don’t speak with potential team members using audio or video until the final stage of the interview process. I’ll interview them over instant messaging and email first to eliminate any subconscious bias and factor out things that aren’t truly important.
During this latest hiring push, I wanted to take the idea a bit further because something was bugging me: candidate photos in Workable.
Version One
Looking at the DOM for the Applicants screen in Workable, it’s pretty clear that there’s n class that’s a common thread among applicant avatars/photos, “avatar-img”.
jQuery is available in the logged-in Workable site, so that makes this really easy. Open console. Type out….
jQuery(".avatar-img").hide()
Great! But I don’t want to type that out every time I’m on this page or copy and paste it from somewhere. I can make it a bookmarklet in Chrome and just click on it each time I log into Workable.
javascript:(function(){ jQuery(".avatar-img").hide() })()
But what’s unfortunate is that the Lazy Loading that shows more candidates causes new people to show up with un-hidden headshots. Whoops. I can hit the bookmarklet again, but that’s no fun.
Version Two
I need a second version of this. One that can account for the Lazy Loading.
Well, I discovered that Workable will load about (exactly?) 100 applicants at a time. I guess it’s a pretty nice problem to have over 100 applicants for an open role.
Ruth has clearly been filtering some folks out and so now we happily have only 99 in our “Qualified” list. Honestly, the Lazy Loading issue is such an edge case that I no longer feel it’s worth spending time on.
Takeaway: Know when to abandon continued work on a project when it’s not going to produce further value.
Message to Self: Stop working on this. You are developing features no one asked for.
Ha ha. I got a bit too far down the rabbit hole of:
- trying to survey all includes images on a page under a certain size
- logging their classes in an array
- counting the instances of each class
- figuring out what the most used class on the page was to suss out the class name of the most common image was, i.e., avatars.
All in an attempt to have this bookmarklet not rely on my hardcoding the class name. Great idea, but one that’s completely unnecessary to execute at this point.
Takeaway: Don’t spend time building a system to account for a problem that doesn’t currently exist.
Discussions