[sf-lug] Job descriptions/requisitions requirements, "years experience", etc.

[Michael Paoli]

Job descriptions/requisitions requirements, "years experience", etc.

Some random hopefully useful comments :-) - mostly on
writing/specifying job descriptions/requisitions, etc. used to attempt
to recruit candidates, fill open positions, etc. (and to a lesser
extent on reading them and such).

"years experience" - I generally advocate folks don't include - or at
least don't include "excessive" requirements in terms of time (year(s))
of experience in/with <whatever>.  There are a few reasons I generally
take such a position - the first being a quite practical one.  In many
cases, someone with e.g. 2 or fewer years of experience will be more
competent at something than someone with 5 or more years experience -
and yes, even when working on that same <whatever> - surprising, but
true (at least often enough, anyway - and wouldn't one prefer to hire
the person who grows their skill set / competency at 2.5 or more times
the rate of some other candidate that meets "requirements"?).  Not every
one picks up stuff at the same rate, retains it as well (or not), some
folks may be highly self-motivated to master stuff and do so
exceedingly well, other folks ... well, don't particularly care or
otherwise don't manage to master it or get particularly close - even
with substantially more time (or they might mostly be growing in other
areas/directions).  Sometimes also depends upon resources (e.g.
training and relevant materials) that are/aren't available/accessible
to someone ... or if they have the time to use such
materials/resources.  I tend to favor an approach where such
descriptions/requisitions - especially for "requirements" - are written
much more in terms of levels of skill/competency/familiarity - e.g.
what can they do, how well and quickly, and how well do they know it
... and not in terms of how many years it's been within a few feet of
their potential grasping.  E.g. for systems administrator positions,
when I've written such descriptions, I've often written them in terms
of relevant skill levels (and typically referencing SAGE Levels in job
descriptions: http://www.sage.org/field/jobs-descriptions.html as more
likely to be understood among systems administrators than some random
made-up-on-the-fly set of descriptions/levels or the descriptions of
some not especially huge hiring entity (e.g. something less than, say,
the US Federal Government, or a highly populous US state).) Some
example bits of text I'd used (from a slightly mangled copy I found
that's still on The Internet): "good/strong hands-on hardware technical
(Solaris 8 SPARC, Hewlett-Packard x86 Red Hat AS 3.0), strong in those
operating systems and Perl, and preferably also HP-UX 11.11, SuSE 8.1,
shell scripting, SAGE Level III[3]/IV[4], etc." "strong on Solaris 8
SPARC and Hewlett-Packard x86 Red Hat AS 3.0 (both local to that site),
Perl, at least proficient in scripting one or more Bourne-like shells
(Bourne/Korn/POSIX/bash)." "Expecting and desire a typical compliment
of SAGE Level III[3]/IV[4] skills/experience." And another practical
matter - if one writes as "required", <N> years <foo> experience, any
candidate with less than <N> years <foo> experience may consider
themselves unqualified and not send in their resume, inquire, or apply -
even if they might be the best of the applicants that might otherwise
have applied.  Also, in some settings, HR (or similar area/department)
will filter resumes/applications/applicants before they get to hiring
manager, etc. - and if they don't strictly meet something specified as
required, HR will place them into the "not qualified" bucket, and never
pass them along to hiring manager, etc.

"required"/requirements - one thing I learned along the way from some
HR training - in job posting/requisition, never state as required
something that isn't an absolute hard requirement for the position -
i.e. if you might actually possibly hire someone for that position that
failed to precisely meet as much as one thing on the description that
was stated as "required", then one has a problem.  Of course one can
state as much as one wants as "strongly desired", "desired",
"preferred", "also beneficial", etc.  As I understand it, at least some
of the reasons behind never putting as "required" something that isn't
absolutely required, mostly has to do with lawyers and all that goop.
Namely, if one hires anyone that didn't meet every item that was stated
as "required", well, then any and all persons that also don't meet
what's stated as "required" may decide to sue, claiming that they were
discriminated against ('you hired person X even though they didn't meet
requirements - well I also didn't meet requirements, so you must've
discriminated against me on some other (potentially protected) grounds,
so I'm gonna sue you!') (or maybe on 'false advertisement' ('I didn't
apply because I didn't meet requirement(s), yet you hired someone who
didn't meet requirement(s) yet you advertised those as being required,
therefore I'm gonna sue you!') grounds, or who knows, ... anyway,
lawyers, and entanglements better avoided).

And ... reading all those descriptions/"requirements" :-)  Not every
job posting/requisition written is written as it theoretically should
be in those regards - so ... often useful to read/take the
"requirements" with a grain of salt, perhaps also try to "reverse
engineer" what the hiring manager is likely actually looking for and
likely to consider or seriously consider - and if one may in fact
rather to quite well fit the bill, generally won't hurt too much to
apply (and never know - one may end up getting the job offer - or maybe
that leads to a job offer of another position of interest).  Applying
for something where one doesn't meet every stated "requirement"?  Don't
deceive or hide the fact(s) - be upfront about it - but coach it in a
positive way (e.g. perhaps in cover letter: <glowing stuff about well
meeting most everything in description> ... 'Though I don't yet have
precisely <requirement>, I do have <damn near requirement>, and am the
extreme go-to expert in <requirement area> at <my big company>. I've
also written most of <my big company>'s documentation and training
materials on <requirement area>, and have been the lead trainer and
instruction developer at <my big company> on <requirement area> for the
last <rather long time>.  You might perhaps also know of my book <book>
on <requirement area> that's sold over <big number> copies in
<impressive number of> languages.')

Other random bits: Too many candidates not qualified or sufficiently
qualified?  There are other ways to filter or reduce the number of
undesired resumes/applications submitted.  One shouldn't overstate
requirements to attempt to do that.  If and to the extent one is going
to list "required" stuff - think long and hard about those - e.g.
what's absolute bare minimum that one would possibly hire into the
position - that would be at/around the "required" criteria.  Feel free
to go (reasonably?) hog wild on the "strongly desired" and "strong
preference for" through "nice to also have" bits one includes in
description.  Writing good/excellent job postings/requisitions isn't
especially easy - but taking the time to do it very well can have major
long-term benefits (and avoid significant pains).  As one excellent
manager I had put it (paraphrasing): 'Hiring good people is (a) most
important responsibility of manager - after that things almost run
themselves.'  I'd argue that writing good/excellent job
posting/requisition is a quite significant part of that.

Also, many bits of this may be rather specific to US law - some of these
considerations may not be applicable or as applicable in other
countries.  Our lawyers may be much more numerous and litigious than
yours.  ;-)