Messy Job Descriptions

  • Comments posted to this topic are about the item Messy Job Descriptions

  • The rule of thumb here is simple.

    a responsible person would not apply for a position with a long list of random requirements. Because he/she does not possess the required skills and he/she is, well, responsible.

    On another hand, a cowboy would not hesitate, it’s what they do - claym to be what they are not.

    You won’t end up with no applications if your list of requirements is too long. It’s just all the applications you’re getting will be from cowboy developers.

    _____________
    Code for TallyGenerator

  • I like Sergiy 's response - nice and witty - but not necessarily true in my experience. I would definitely tend to the "responsible person" end of the spectrum but, perhaps, I am blocking-off opportunities I should take?

    I have a friend who readily admits that she just says that she knows everything in the skills list - whether she does or not. She figures that she can pick it up quickly enough and can always do some homework while she is waiting to take up the position (if she gets it.) So far her strategy has proven 100% correct and she has been a success in her jobs. (It helps to be exceptionally clever of course.)

    The problem I have with this strategy is that I do not like lying. However, whenever I have been in a role and been dropped in the deep-end to work with a new application/technology, I have always succeeded in a relatively short time, so that is my sales-pitch in this situation.

    As a footnote, when I worked in R&D, there was no point in listing a set of specific requirements as some of them nobody (or very few) had done yet. So it was just assessing intelligence, learning ability and judging from knowledge of related expertise.

     

  • There are several jobs I didn't apply for because I didn't have all the job description asked for. It was here on SQL Server Central where I read it was a good idea to apply if I had 70% of the skills listed. I've tried to follow that advise. It does seem like I at least get contacted more often for an interview. But there are a few companies who wouldn't contact me when I only satisfied 70% of the listed skills.

    Rod

  • In many cases, the "DBA" may in actuality be a jack of all data related trades - expected not only to keep the databases running but also create all the databases, write most of the SQL, do reporting, and maybe even manage the network. But before searching to fill a position, the organization needs to first define what that position is, so they don't turn off perfectly good candidates.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • There's a tendency for the % missing skills to be off-putting at a lower figure for women than it is for men.

     

    We spent a lot of time focussing on the language used and focussing more on what we actually needed and frankly we got a more varied and better set of candidates.

     

    I've done a number of mentoring sessions for The Princes Trust and one of the things I tell the participants is that if you are invited for an interview a very busy person thinks you are worth the time. You are already well ahead so shoulders back, head held high

  • I'll stand by what I wrote. Job descriptions are messy, and many companies ask for lots of things they might need, or might rarely need.

    This isn't the cowboy, but rather the smart or savvy person that realizes how the description is built. Apply when you hit 50% of the requirements. The worst case is they say that your 50% isn't good enough in an interview.

    As for defining the job, jobs change. Tech changes, we alter what we do too often to try and define this too tightly. We learned this in software years ago that a waterfall, get all requirements and then build it, doesn't work. The same thing with jobs.

  • Steve, if you learned that getting all requirements upfront does not work - why do you stand by this approach in jobs?

    _____________
    Code for TallyGenerator

  • But of course, the other side of this is the resume that is loaded with search words and claims of ability that MAY be a bit overstated.  And the challenge for interviewer is to be able to identify the real ability.

    I guess it is all a part of the game these days.   I think one way to handle this is to have the interviewee talk to other other staff members who might be better able to delve into the detail more than a single interviewing manager.

    As a personal note, I always thought it best to not make any excessive claims.  Better to have a new boss pleasantly surprised than severely disappointed.  Best answer is 'I don't know a lot about that, but I will know more by the time I begin work'.

    I made one very bad hire as a manager, and unfortunately had to let the person go because he was just not a good fit for our needs.  He was just out of school and had no prior experience.  I always did and still do feel bad about that situation, but it had to be done.   Another candidate that I did  hire seemed to have good potential, but on his first day at work, he went to lunch and did not return because he got a better offer.  In effect, he let me go.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • Sergiy wrote:

    Steve, if you learned that getting all requirements upfront does not work - why do you stand by this approach in jobs?

    You're misunderstanding me.  Getting all the requirements and tailoring them to exactly describe the job is exactly what doesn't work.

    Getting lots of wishes and possibilities, and very loosely describing what you might want the person to do is what I think happens, and what's best.

  • skeleton567 wrote:

    But of course, the other side of this is the resume that is loaded with search words and claims of ability that MAY be a bit overstated.

    ...

    I guess it is all a part of the game these days.   I think one way to handle this is to have the interviewee talk to other staff members who might be better able to delve into the detail more than a single interviewing manager.

    As a personal note, I always thought it best to not make any excessive claims.  Better to have a new boss pleasantly surprised than severely disappointed.  Best answer is 'I don't know a lot about that, but I will know more by the time I begin work'.

    ...

    It is a game, but it's always been a game. So often we have very inconsistent and varied hiring practices, even from one person to the next. Many companies have tried to make it a science, with a specific set of questions and protocols to be followed. Not sure they end up with better choices.

    I always want to meet multiple people when I interview, and I do ask about that, mostly to better understand what it's like to work there. If they only want to interview me with one person, I find that a red flag. However, most of my recent interviews, always involve multiple people.

  • Steve Jones - SSC Editor wrote:

    Sergiy wrote:

    Steve, if you learned that getting all requirements upfront does not work - why do you stand by this approach in jobs?

    You're misunderstanding me.  Getting all the requirements and tailoring them to exactly describe the job is exactly what doesn't work.

    Getting lots of wishes and possibilities, and very loosely describing what you might want the person to do is what I think happens, and what's best.

    you see how easily your words could be understood not as you intended.

    If you think about it, my interpretation is pretty legit.

    To me, "loosely describing what you might want" is exact opposite to "Getting lots of wishes and possibilities", especially when they put in form of very specific skills and experiences.

    If you want somebody to "develop and modify data transformation interfaces between systems" then you should put it like that, not just request "5+ years hands on experience with SSIS". It's not quite the same, right?

    _____________
    Code for TallyGenerator

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply