You can't find tech staff – wah, wah, wah. Start with your ridiculous job spec

Re: Bucolic programming

Many years ago BT wanted to hire software folks, but found it (unsurprisingly) hard to attact them to the delights of Ipswich (this was in the days when everything shut at 5pm, and a deep pan at Pizza Hut was the highlight of a night out).

Instead of trying to attract the talent to HQ, they took the jobs to the talent, opening software centres in Newcastle, Belfast and London. It worked, they got many high-quality engineers and although they have since screwed up by outsourcing everything to India it showed that the principle is sound.

Re: Bucolic programming

Interesting you should mention Bradford. We're a tech firm based on it's outskirts and we're certainly not alone in this region. And yeah, we struggle to recruit good engineers too.

Then you get the idiots who say "must have 10 years experience in docker"

And then HR slap on their standard requirement that anyone programming in a particular language must have X years previous experience in that language.

Even when the language was created less than X years ago.

And back when you could still specify age in job adverts I remember seeing one requiring a degree, X years experience, and < Y years old. Working it out there was a window of about one year of age where someone could just possibly satisfy all three requirements.

It's even better in the public sector. In order to hit a roughly competitive pay grade (the public sector tends to pay a bit less, but to get it in the same ballpark) HR will hack technical job descriptions to make them look like management posts.

Memorably, I once reviewed a job description for an NHS organisation that was colour-coded. Blue text was stuff the hiring manager could edit. Red was inviolate and MUST NOT BE CHANGED etc.

The blue text ended up being a few paragraphs at the bottom of the second page. All the other required skills were "leading and collaborating" and suchlike. I felt quite sorry for any potential candidates trying to understand what the actual job was.

After they add a whole bunch of acronyms they heard once while watching Silicon Valley, the number of people with those skills drops to just about zero.

Alternatively, the specs are real, but the *ONLY* person remotely qualified for the job is the person who just left it.

Re: Don't worry your PHB's

There are plenty of 'under the radar' jobs that involve reviewing and fixing the execrable muck churned out by the Indian code-shops everyone's outsourced to. Look for anything mentioning Quality Assurance, mentoring or Partnerships: 95% chance this is what the job will be about. Slightly soul-destroying work, but it puts food on the table, and you can keep your dev skills up and current by simply throwing away the crap from India and writing it yourself. Friends of mine are making very good second careers doing this, and as long as a monthly salary/daily rate is all the credit and recognition you seek, you'll do ok.

A/C for obvious reasons. But good luck getting 'off the bench'.

Re: Don't worry your PHB's

"Mine went this time last year."

This is the time to g freelance. You can then charge an appropriate fee for sorting out the problems they brought on themselves. For IR35 reasons, of course, it might be better to sort out problems that other people brought on themselves in like manner.

Re: Not knowing how to look can make it hard to find

That's certainly not true of everywhere. A lot of what gets written about recruiting software engineers implies the employer is awash with candidates and it's a case of whittling the list down to the number of vacancies.

In my experience that's often not the case, at least in the regions we work in. Our interviews are very real-world, and of course still many people don't make the grade.

Re: Not knowing how to look can make it hard to find

Typical recruitment process is that companies employ an agency. The agency find that the client is not very good at specifying what they want, so the agency says "What about skills X, Y, or Z?", and the client goes "Yes, all of them!". Then they move on to qualifications, and the client is still clueless. Agency says "Well, do you want a CompSci degree?" "Yes, Yes, of course yes!". "Do you want to restrict that to upper tier universities?" "Of course". And any degree, or cut off at a 2:1 minimum?" "Oooh, yes,2:1 and above". So although they only needed somebody good at X & Y, they've ruled out the 40-60% of people who haven't been to university, they've ruled out the 90%+ that didn't graduate in CompSci, then they've ruled half of that tiny group out on the basis of grade, and they've put in an overlay of "skills in Z" which isn't really important here.

Now, what's going on here is that the recruitment agency are trying to create a person spec because they'll only get paid when somebody is hired through them, or (for other contracts) when they put forward candidates meeting the spec. From ther point of view, they want a simple shape sorter that is easy to operate, screens out the people the client doesn't want, and bingo, its payday. Unfortunately, given the way companies tend to unwittingly gold plate the specification, this means they narrow down the pool of candidates to a miniscule subset, and then try and recruit people who can do the job so easily that they already have all the skills, stand to learn nothing new, and there's no reason why they should apply for such a Grounghog Day job. Recruiting managers rarely say "All I want is a good, experienced developer with skills in X, able to understand Y, couldn't give a toss about the academic education, but needs to fit into our corporate environment, and has suitable prior experience."

The vast majority of managers complaining about skills shortages are talking out of their arses, and their companies can't find skills purely because they rule so much of it out on spurious grounds.

Re: Depends What You're Looking For

"There are a surprising number of developers who can't code. "

Make that "astonishing". I tend to get the reputation of "The Guy" because I use modularity, structure, patterns etc. and don't just cut and paste example code. Of course if feels like climbing Everest in your underwear sometimes but results are gotten and they tend to be good. Not so with the C&P brigade or the "screw the design spec, I need this piece so I'm going to grab it even if I introduce pathological dependencies in the process" people.

Unfortunately the people who preside over chaos are the least well equipped to understand who can be expected to clear it up rather than make it worse. I did a major cleanup of a process once and got the cycle time down from weeks to hours. What got me noticed? Presenting the output in HTML instead of bog roll text.