hiring dark pattern

[cellio]

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?

Comments

[dsrtao]

Years are a pretty terrible proxy, here.

Might as well ask for a self-assessment:

Required:

- Mastery of Java and JVM
- Proficiency in x86-64 assembly
- Familiarity with FPGA design

Preferred:

- Exposure to EDA tools, especially Verilog

Good thoughts.

[dsrtao]

Oh, two more things:

1. Women have a statistical tendency to look at requirements and treat them as absolute requirements, whereas men have a statistical tendency to look at them as aspirational.

2. The vast majority of recruiters cannot tell you the difference between Java and JavaScript, even if they are ostensibly hiring for one or the other. Don't allow yourself to be interviewed or blocked by someone who can't answer that question satisfactorily.

[metahacker]

Amen.

The fantasy of the "perfect hire" seems like some weird subset of Peter Principle thinking. In knowledge work, the illusion that workers are interchangeable cogs who are slotted into a particular role is even MORE ridiculous than in many other positions.

On my resume I chunked skills into "proficient", "rusty", and "getting there", which seemed to go over well with recruiters, although I'm not sure it was as useful for actual hiring managers / interview teams. The problem is that once you get to "proficient", the playing field changes dramatically, becoming huge and wide, and each skill has its own landscape. ("Knows what's available in the Java API" is one expert skill; "understands how and when the garbage collector fails" is an entirely different one. But that breakdown wouldn't make sense in, say, C++, or UX, or...)

Trying to be generous about it, I guess the thing is, writing job reqs is hard, and when you're hiring a lot, you start taking short cuts. (Or so I imagine. We're hiring a lot, but we hire based on velocity, not position, so the skills you *have* are less important. And tech moves fast enough that adaptability and learning speed trump lots of other stuff.)

I do wonder if the sudden increase in labor competition that we're seeing now will lead to better hiring practices, but somehow doubt it.

[mtbc]

It's also true that I'm typically looking to stay with an employer awhile (my previous for eight years) and it's not that hard to become productive from very little. E.g., I came to Java already having familiarity with languages ranging from C++ to Modula-3 (which Java 1.0 could have learned a lot from!), I came to Python already having languages from Perl 5 to Haskell (significant indent, list comprehensions, etc.), there isn't much that I can't pick up quickly. And, yeah, years are such a poor proxy for actual facility with the language. In a new environment, like when I landed on my first J2EE webapp with very little experience with RDBMS, Spring, Struts, jQuery, whatever, I was fixing bugs over my first weeks, and knew my way around all kinds of aspects of the legacy app after a year or so; my evaluations were always good even if I came in with little, just like I was quickly productive and well-regarded on a Lisp-based genomics knowledge base project, coming in with no Lisp or genomics background and having dropped biology at age fourteen. I'm not a genius, it's just that years of prior experience aren't much relevant if you remember exposure to related stuff and are willing to learn, e.g., I bought myself, Introduction to Molecular Biology among others.

[madfilkentist]

A couple of items from my own experience:

One job opening (a long time ago) required a number of years of experience with Java that was possible only if the candidate had access to pre-release versions.

A contract position which I wanted required a certain amount of experience with "Java Beans." Java Beans are nothing but objects that follow certain simple constraints for access and assignment. Take fifteen minutes to read the requirements, and you know how to do them. But a recruiter refused to recommend me for a position because I hadn't been doing it for a year.

[goljerp]

Oh, yeah. (Coming to this late). For me, it's Pearl. I don't know Pearl, but at my previous job, I was able to modify a Pearl script someone else (who'd since left) had written, and get it to do what we needed. Does that mean I "know" Pearl?
Or SQL. I work *with* SQL all the time; I feel confident doing queries, but if I need a complicated result in my code, my inclination is to do a (relatively) simple query and then do the complex stuff in my Java code. (And I'm not using "Oracle SQL" now, but I don't see how that would be any problem for me if I were to go someplace that uses Oracle - I make an effort to write agnostic SQL...)