![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
hiring dark pattern
We're hiring, so I've had recent occasion to see a hiring "dark pattern". I don't know how widespread this is outside of the tech industry, but I see it a lot in tech and it needs to stop.
The pattern: asking for "number of years of experience in (insert tool, language, or skill here)".
Jobs are multi-faceted. I'm seeing people who don't know how to choose a number, and just as I see the ones that overshot, I know there must be ones who undershot and were filtered out. I saw a resume recently from someone with a broad role, who listed "N years experience" in something where N was the length of the job, even though the job involved many other things and wasn't primarily about that skill. That's "N years of experience" in the same way that I have "20 years of Java experience". Spoiler alert: I don't.
Recruiters and hiring managers put people in this position: we have this checklist, tell us how many years of each, and we need a number not an explanation. Maybe we're making you fill out a web form and you can't even add a comment or ask questions. In the absence of guidance about primary and secondary skills, people will apply different weighting factors. It's a mess.
I often don't know how to answer either. In the last four years I've gained four years of tech-writing experience, the focus of my job, and four years of git experience, meaning I have all the basics and can untangle a merge conflict (but I've never rebased successfully). Those "four"s don't mean the same thing; I don't spend all day using git. Tech writing is fundamental to my role and I'd have no qualms about fully claiming those four years, but for git I would want to say that I've used it as part of my job for four years. That's different. I don't have the same knowledge that an infrastructure person whose job revolves around maintaining git servers and stuff for the same amount of time has. "How many years of experience?" questions don't allow for that nuance.
People who are trying to be thoughtful and honest run the risk of getting filtered out, and people who count "everything" get filtered in. I wonder how the success rate (meaning "acceptable hire", since you'll never know if you got the "best hire") of this exercise compares to recruiters just not filtering on skill-specific numbers at all (just general experience) and having the hiring team evaluate more people. I'm fortunate enough to be sufficiently "long in the tooth" that I don't need to worry about this gatekeeping -- either you're looking for a top-notch tech writer with all that implies, or you aren't -- but this hurts early-career people where the difference between "2" and "4" can make or break a deal.
As for the Java: I spent years documenting and helping to design Java APIs, wrote some examples, but haven't written anything deep and complicated. Someone with a year or two of full-time actual Java development experience beats me. Would the recruiter be able to tell?
no subject
Yes -- but with a big caveat that learning new idioms is much harder than learning new syntax. Folks jumping over a paradigm shift (from imperative to OO, or OO to FP) often say, "Oh, I can pick up new languages easily", but frequently find that learning the new idiom is much harder than they expect. I've seen folks wash out of the industry entirely when hitting one of these walls.
I'm very sensitive to this: we mostly hire Java engineers, and I spend a lot of my time getting them up to speed on Scala. Learning the new syntax is easy -- learning how to program immutably is usually an order of magnitude harder, and grokking modern functional programming is a whole 'nother ballgame.
It is sometimes harder for experienced programmers to make these leaps than for someone who is coming in as a relatively new programmer, if they have difficulty unlearning their old habits. Varies wildly from person to person...
no subject
That's a very good point. Within "type", having some background helps you learn the new context. That's mostly what I've seen (for example, people moving between C++ and Java, which are both object-oriented), but for a jump to something with a very different model, that wouldn't help much -- and if you expect it to, I can see how that would make things worse.