Why recruiters are looking beyond IT's traditional talent pool Simon Zhang is a former brain surgeon, but that’s literally the last thing you’ll find on his LinkedIn profile. Until March, Zhang was LinkedIn's director of business analytics, having worked his way up through a variety of positions in data science and business analytics since joining the careers social network in 2010. But …
"I've got various skills and experiences that can make me more effective at my job than pure IT training due to the people we work with."
Thats nice. Except I'm not sure how being able to grout a wall is going to help you analyse why a particular network card in a blade rack is suddenly dropping every 3rd packet from address 1.2.3.4 at 2am or decide whether an in-memory B+ tree or a hash map would be a better choice for a warehouse data retrieval system.
Or by IT did you mean "I can find the control panel in Windows"?
"Or by IT did you mean "I can find the control panel in Windows"?"
Let me award Boltar the "Breathtakingly Patronising, Arrogant Tw@t of the Week" award. Hopefully he'll be proud that he's earned this title already and it is not even mid-day on Tuesday.
Do you look down on people who clean toilets and maintain road safety fences as well?
"Let me award Boltar the "Breathtakingly Patronising, Arrogant Tw@t of the Week""
Awww, poor baby, never mind, I'm sure someone will be along to pick up your toys scattered around the pram.
Guess what - I'm sick of people treating IT and coding like its some kind of idiot fest that requires no proper training just because when they were 12 they managed to write a 1 line program to print "HELLO WORLD" on their Sinclair Spectrum or knocked up a web page in 1995 for their cat and now think they could write the avionics for an Airbus in their spare time.
"Do you look down on people who clean toilets and maintain road safety fences as well?"
Well in your world someone so aquainted with bacteria when cleaning toilets should immediately be promoted to the job of senior microbiologist at the WHO, right?
@ boltar
Maybe knowing how a builder thinks means he's better placed to write software that other builders find intuitive, or which performs functions that clients in the construction industry want more efficiently. Learning to code isn't tough, but understanding the job you're writing software for is.
Anyone who's ever implemented specialist software for an industry can tell you that skilled computer science grads can write truly awful software, simply because they're often writing for a job they don't have any knowledge of - they have no idea how, for example, a house is built, so they write the software to the spec and not to the job it's meant to perform. The standard excuse for this is that the customer didn't specify properly, and while that's usually true, it still means that the guy with prior experience in that industry who can write the software that does what the client wants is a better choice than the comp-sci code-whizz with zero experience outside programming.
"Learning to code isn't tough,"
Well actually to code properly in a proper language (ie not HTML) developing proper algorithms *IS* tough. Unfortunately too many people like you - aided and abetted by organisations like the BBC - are of the opinion that any idiot can code therefor "I can do it to". Well any idiot can slap some cement on a brick and build a wall but I wouldn't get them to build a suspension bridge for me.
"understanding the job you're writing software for is."
Depends on the job. Rocket guidance systems or financial trading - sure. Buildling accounts, not so much.
"prior experience in that industry who can write the software that does what the client wants is a better choice than the comp-sci code-whizz with zero experience outside programming."
If the software doesn't work or performs poorly because of the lack of experience of the developer then I doubt the customer is going to be too thrilled either. Any good developer can turn his hand to any task given a decent spec, but good luck getting Mr Builder to write a decent bit of code with no training regardless of how much he might know of the arena its meant for. Also theres a reason most serious software houses and other companies that do in house coding have Business Analyists as well as coders.
Writing code isn't the only job in a technology business.
What about project management and budget control? How about communicating with others and understanding customer requirements? Successful builders have to be able to do these and the skills translate to other types of project.
What Britt actually wrote was "I'm a builder who now trains and supports software", so how would your amazing coding ability help with training and support?
@boltar
Any good developer can turn his hand to any task given a decent spec
So you are saying that your employer is going to carry several million indemnity insurance just to cover your cock ups. You obviously know nothing about industrial control software and the equipment it is running.
We have the job of writing the specifications for such software and include with the detailed specifications full operating instructions, photographs and diagrams as well as being on the end of the phone line to answer questions and still the developers that have never been out on the production floor get it wrong by missing some essential sequence of operation.
The usual attitude of the developers when questioned about their cock up is that they thought it was 'near enough'. Near enough when applied to a £5m machine is not good enough especially if it means that machine will have to be replaced.
Those developers that have a background in industry are way better than those that don't. Machine tools are very unforgiving.
Also theres a reason most serious software houses and other companies that do in house coding have Business Analyists as well as coders.
A Business Analyst might be necessary in developing financial services software but is useless for industrial control software.
"We have the job of writing the specifications ... detailed specifications full operating instructions, photographs and diagrams ... and still the developers ... get it wrong by missing some essential sequence of operation."
That would be some essential sequence that you missed out of the specifications then.
I'm a programmer and I'm sick of being blamed for other people's cockups. If you wanted the red knob turned after the blue valve was shut you should've said so, we're not mind readers.
@Lallabalalla
We do give them all that information and, when it is critical, the timing of each operation.
In one case we even went as far as filming the operation on a slightly older machine - the operating sequence was exactly the same and the only difference was newer components, stepper motors, enhanced sensors etc.
I am not trying to get a dig in at all developers, they do their best, but a lot of them quote to do the development without knowing what is entailed. Industrial machine tool control is somewhat of a specialist field that developers without some specialist knowledge should be very wary of.
A lot of programmers suffer from the delusion that, given the perfect spec, they would write the perfect code. Not so.
There is no such thing as a perfect spec (except the one written after the prog has been completed and tested). The coder who doesn't inquire into the usage of his code is as much to blame for cockups as the analyst who forgot to mention the blue valve (because he thought it was bleedin' obvious).
A Business Analyst might be necessary in developing financial services software but is useless for industrial control software.
Hey! We BAs can also do health care, testing services, and retail software, as well. Give us some credit.
Having worked in my college summers in manufacturing and a brother who is a EE/Comp.Eng and works on control panels for a variety of applications, I have no desire to ever step into a role that requires me to do that kind of work for industrial machines. Something about hearing my brother recount a project he was handed where he was asked to maintain and enhance thousands or millions of lines of undocumented spaghetti code in machine language gives me nightmares.
"The usual attitude of the developers when questioned about their cock up is that they thought it was 'near enough'. "
Perhaps you should hire proper developers instead of some BOGOF team you found in Bangalore. I know a developer who worked in industrial control and before that the nuclear industry and he was often at his desk until after midnight testing when a release was coming up.
Anyway, if development is apparently so simple why not show them how it should be code and write the code yourself? I mean how hard can be, right?
"A Business Analyst might be necessary in developing financial services software but is useless for industrial control software."
So industrial control isn't a business then?
Boltar, I never said, and I hope I never implied, it was simple - it isn't and never will be.
The developer you know sounds as if he is dedicated to his work and as such should be earning big money for what he does. The last team we employed for one of our clients walked away with just over £1m for 9 months work and we will employ them again when we need their expertise
Selling industrial control systems is a business. Just read what Eric has to say in the comment just above yours.
@Naselus
I couldn't agree more. Having seen a full production line come to a grinding halt because the programmer didn't know that you only switch off the lubrication pumps AFTER everything has stopped moving, even in an emergency shutdown situation - for him emergency shutdown was just cut all power. That little SNAFU cost several million before that line was up and running again.
Now, every bit of software that is intended to go into that plant comes to us first for inspection and testing and there had better not be any binary blobs that we can't get into - if there are then it is rejected at the developers expense - they don't get paid since the requirements are in the contract.
If the requirements had been in the contract he would have known not to shut down the pumps until everything had stopped. Too many domain experts think that too much is obvious. I spend a substantial amount of time asking the domain experts to clarify their requirements so that they say what they really mean. It helps that I started by getting a physics degree, then hardware design, then embedded controller design and programming so I understand a lot of the physics, electronics, mathematics, or chemistry behind what my clients want and can read between the lines well enough to see that a lot of lines are missing; but many of my CS educated colleagues simply have to take the domain expert's word as the whole truth and nothing but the truth.
Maybe knowing how a builder thinks means he's better placed to write software that other builders find intuitive, or which performs functions that clients in the construction industry want more efficiently. Learning to code isn't tough, but understanding the job you're writing software for is.
I can see plenty of other cases - the poster here a few days ago that observed on needing data centre racking that calling in the joiners to build racks into the room would be cheaper and more elegant than buying and adapting around whatever massproducedracksareus.com happen to be flogging. Or the IT guys in a hospital I was visiting a few months ago routing cat6 through a wall. I could see the problem straight away, so it was no surprise to see the following day the cable had been ripped out and a couple of other guys discussing how to repair the damage. All because the IT whizzes had decided that the notices literally every ten feet along the wall (Fire wall - do not penetrate) didn't apply to them.
Both cases are on the fringes of IT - they won't be covered in an IT course but IT professionals still consider them fair game for an amateurish stab at them. Sometimes it works, sometimes it doesn't. Yes, the builder is a fairly extreme example but there are plenty of more direct examples - maths, electrical engineering, physics (cough), management, marketing, domain specific knowledge for the application at hand. The broader the skills base the more likely it is someone will spot pitfalls before they arise just as I've lost count of the times I've heard IT pros talk of the "resistance" of data cabling, as if resistance is in any way a meaningful metric for data cabling.
You can dismiss all that expertise before the altar of dedicated IT skills but it is an incredibly foolish attitude. And don't complain a week on Thursday that they are all career politicians with no knowledge of the real world, because it is exactly what you are demanding here.
This post has been deleted by its author
The last guy I worked with had an IT degree and was not shy in telling everyone about it. Gave him a small project to work on.(rework a stored procedure and view). Long story short after three weeks he finally admits that the reason it isn't finished is because he did not know SQL. The guy had a degree in Information and database management!
So, yes, I will take the Builder, or the electrician or guy/girl off the street rather than the likes of him, or YOU for that fact, because Id rather a honest hard worker than a pretentious twat like yourself. .
"Long story short after three weeks he finally admits that the reason it isn't finished is because he did not know SQL. The guy had a degree in Information and database management!"
Perhaps you should have asked if he knew SQL in the interview and given him a test. You only have yourself to blame.
"So, yes, I will take the Builder, or the electrician or guy/girl off the street rather than the likes of him, or YOU for that fact, because Id rather a honest hard worker than a pretentious twat like yourself. ."
Thats fine, because I wouldn't work for someone as amateur hour as yourself who doesn't even find out whether the person he's employing has the relevant skills first.
No surprise that you didn't spot the irony in your comment - you want an honest hard worker (which this guy apparently was since he tried for 3 weeks to do the task) - yet you apparently sniff disdainfully at appropriate IT skills which if this guy had had he would have completed the task in no time.
I would imagine your projects are complete and utter chaos.
"Well actually to code properly in a proper language (ie not HTML) developing proper algorithms *IS* tough."
No it isn't. It's a complete myth that coding is tough. It's often badly taught, some languages are not conducive to neatness (and so to visibly logical structure), and maintaining a fifty year old system that has been patched/updated/partially rewritten constantly can be a little challenging, but even if coding was as simple as speaking what the requirements, it would still be bug-ridden spagetti.
Requirements that don't contradict each other, the remains of the previous system they're being layered into, the capacity of the hardware/network (physical), protocols/through put limits (transmission) etc. etc. that's quite hard. To get it to do what the customer wants, that's harder still. Then to either translate that into code or to explain to someone else what you want the code to do... that's the really tricky bit.
Mind you, I've never had any IT training beyond a three month OTJ course 25 years ago... so perhaps I'm writing shite most of the time... ;-)
I agree the need for story telling, or putting a narrative on what a solution or technology can do is important.
I would council that this is just one skill amongst many that an IT professional needs. An appreciation for the technology and engineering is also key.
For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. - Richard Feynman
"I agree the need for story telling, or putting a narrative on what a solution or technology can do is important."
Great , except REAL data science involves hard statistical maths - something this fluffy puff piece conveniently ignores. Being able to waffle might work front of house in marketing but its no fecking use when you're trying to analyse a couple of terabytes of data for anomalies.
Well, the trick really is to combine them. As you point out, storytelling which isn't backed up by solid analysis is likely to be waffle (hence probably misleading), but then a solid analysis which everyone (else) finds impossible to understand is not going to help progress either.
Think of it less as a story, and more about being able to deliver an analogy that translates the technical into something less technical. I have worked with plenty who have way more IT qualifications than I, but who would be awful describing something needed to a non technically minded person.
A programmer I know who has worked with compilers for MS, started of as a civ engineer, then did something to do with eco tourism before moving into programming.
These are different things.
If you look at mathematics papers, for example, they will do things like state a theorem, then give a proof - no story or analogy required. Physics papers - theoretical ones - might well start with a premise, the basic model (e.g. Maxwell's equations) and then proceed through a derivation with rearrangements and approximations along the way as motivated by the authors and their aims. You can consider this the "story" of why the result (e.g. on ultrafast optical pulse propagation) is valid and/or useful. In contrast, an "analogy" of something as specific as a scientific paper is simplified (almost) beyond recognition and might involve talking about tennis balls instead of protons, or the like.
It may be the "storytelling" in the article referred to analogies - indeed I rather suspect it did. But here is also the possibility of having a true technical narrative which /doesn't/ compromise in the way that analogy does.
I have to agree with you, analogy probably isn't the correct word and what you describe is a better description, that and being able to translate the effects into something useful for non technical people or see the use in a technology that can be applied to a business or design, is a definite skill set that is sometimes lacking among the tech crowd.
"REAL data science involves hard statistical maths - something this fluffy puff piece conveniently ignores."
RTFA: "Before LinkedIn, Zhang worked at eBay and PetCo, was an intern for SAP and developed a background in CRM. He learned on the job: he spent weeks on raw data entry then turned to CRM systems management work and learned statistics at the library at weekends."
I agree the need for story telling, or putting a narrative on what a solution or technology can do is important.
How about this story: LinkedIn keeps violating privacy and forging emails from my friends, pretending that they want me to join them on LinkedIn. So, I start with a negative opinion of LinkedIn.
Then, every time ZipRecruiter sends me a link to a job opening at LinkedIn, it takes me to Experteer, where a stern-faced man scolds me for not paying Experteer for the privilege of applying to these companies. At this point, I can believe LinkedIn has a skills shortage.
That is not an easy question. A lot of medical research, including drug development, has been based on methodologies which would make a statistician weep, if he or she wasn't being paid to get the results their master wants.
Recent cases have included anti-tumour drugs touted as being wonderful, when NICE has done careful analysis and discovered that the benefit, if any, is minimal. Examples abound of negative experimental results being discarded and other forms of cherry picking. Perhaps the best known of all is Wakefield's "research" on a link between triple vaccination and autism, based on a tiny sample of already autistic children.
So the short answer is that while more brain surgeons might improve the outcomes for individual patients in certain cases, more data scientists looking at medical research might result in huge cost savings and better patient outcomes over a wide range of conditions.
Yes, I realise that having spent years on data analysis and not being a brain surgeon might skew my judgement.
IT professionals will never be respected while the profession is still the wild-west and recruitment agencies are the Marshalls!
I once thought that you could get in anyone and teach them to code. I may have been correct, but now I only employ Chartered Engineers as they know why you design and code in certain ways and have proved themselves good enough to get the peer reviewed qualification.
Would you get your accounts done by anyone other than a Chartered Accountant or your house designed by anyone other than a Chartered Architect? So why would you employ anyone other than a Chartered Engineer?
Is it getting warm around here? I see flames!
Plenty of houses are designed by architectural technicians rather than architects. Small companies do not, on the whole, get chartered accountants to do their accounts, though they may be audited by one.
If the work you are doing is of such a scale and complexity that you need CEngs (in which discipline?) then fair enough, but an awful lot of what passes for code nowadays doesn't need that level of training, and some of the most tricky and advanced stuff really needs mathematicians and physicists, not engineers.
If you see flames, it's because you have made an ill considered post. Perhaps you work in the field of robotics or SCADA, and you have made the mistake of generalising it to a whole industry.
(This isn't sour grapes - I am a Cambridge graduate with postgraduate qualifications in software. But I also happen to know people working on fairly leading edge stuff who don't fit your CEng template)
In anything that I recruit for Chartership in any Tech discipline would count against you. Particularly if everything on your CV is BCS based. Whilst there have been some exceptions the bulk of "BCS-lifers" I have met have been dogmatic, inflexible and utterly unable to relate theirs skills to the actual Business need in short mostly Twonks. No-one ever seems to tell them when its appropriate to switch off the BCS borg programming and talk to a stakeholder like a human being.
Given 2 equal candidates one being a full paid up member of the BCS and one not, I'll take the one not every time.
No-one ever seems to tell them when its appropriate to switch off the BCS borg programming and talk to a stakeholder like a human being.
And this, folks, is why I and other BAs have jobs. Too many business folks got tired of dealing with developers and software architects who talked way above and then down to the managers, directors, and executives.
I'm a closet techie myself, but I got a liberal arts degree in the early part of this century, worked in retail, customer service, helpdesk, and finally, analyst. My skill-set is wide but not deep, and a newly minted CS major could probably put together a small database with stored procedures and automated reporting in the time it takes me to get Visual Studio up and running. But I can relate to, understand, and if necessary, cajole and forcibly extract from, the business folks who make the money that pays for the IT department's salary. After that, I can understand what the needs are yet have enough knowledge about the underlying infrastructure to know how to translate, represent, and direct.
I envision a day where my role disappears in a cloud of smoke as either business users have to become savvy enough to at least communicate effectively to developers or there are developers who've ascended to levels in a business where they have to learn how to speak to others without falling back on system diagrams or flowcharts representing behind-the-scenes processes, ETLs, algorithms, etc.
But until that day comes, I'll continue to rake in the sweet, sweet cash.
Have you seen the overgrown lego blocks that pass for modern architecture? The stuff produced before the modern "architect" appeared is what is bought at a premium and visited for holidays in attractive surroundings.
A lot of software is the same. People think that the kind of intellect that likes analysing hardware or configuring a card is the same as that needed to think abstractly, understand the requirements and environment of end users and maintainers and think openly, logically and unrestrainedly. For that, in my experience, informatics and numeracy graduates seem to be peculiarly unsuited. Anthropologists, classics graduates, biologists, quantum chemists and those with a broad experience outside computing seem to be very well suited. Strangely, real hardware engineers (old school) are also rather good in some fields. Trained software engineers have clever solutions to the problem that is not the one to hand.
In the 1960s the UK computer industry had no IT graduates to recruit. So they took all-comers - from "A" Level to PhD in all subjects.
In many cases the most innovative were bright people who had chosen not to go to university or dropped out of their university course. Everything was still potentially pioneering - and new approaches happened naturally.
Then Computer Science degrees started to become the entry criteria. This new breed entered the industry with some fixed knowledge that was often out of date. They usually did things the way they were taught - they were rarely innovators. IT is about drawing the threads together from many sources - it is best served by an innate ability to see both the wider picture and the in-depth detail.
In 1933 an army officer said this:-
"I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief."
Apply this to IT. When IT was new and productive things were required, companies recruited a lot of productive clever and dillegent people to create things that worked and write standards.
Hiring the minority of clever and dillegent people is expensive however, since these sort of people are quite highly sought after since there is a very finite supply of them. The solution as always is to give the stupid and lazy standards and tools which lets them get jobs done to an adequate standard (as defined by the business). This has been done, but the stupid and lazy need managing by people who can redefine the standards they to when it is required.
Clever and dillegent people (or clever and lazy people) are required for certain jobs, and as finding and hiring the people in the industry with the right attributes and the right skill sets is prohibitively expensive people with the right attributes are therefore being imported from other industries because they can pick up the skills pretty quickly. They don't need to know existing standards, because one of the main reasons they are being imported is to write new standards for trained monkeys to work to.
ITIL and similar standards are not designed to help make clever and dillegent people more productive, they are designed to allow the stupid and lazy to do something useful.
Anon because the stupid and lazy might not like this post much.
I am quite lazy... and hate to consider myself clever, though I've fooled enough people to get where I am today. The lazy is mostly because I don't want to do anything more than necessary to get the job done and happily delegate to others who can do it more quickly than I.
Kidding aside, I was a friggin' psychology major who liked statistics and figuring out how groups interacted and collided (none of that abnormal psych, please). Little did I know that when married with my DIY attitude towards my computer and a possibly unhealthy compulsion to learn a little bit about everything, I would be someone who could BS my way through a room while I frantically used my down time to actually learn the stuff I pretended I knew something about.
I hate being in the dark about something, and that was recently reinforced when I moved to a new company in a new field to continue on as a BA, and I knew nothing about how anything worked, either operationally or technologically. Drove me absolutely mad. But I was able to flub my way though and my deep-seated obsession with learning new things brings me to a point 6 months later where I no longer pretend I know things, I actually do. My PM might not like the way I do things (not enough documented milestones and project plans), but it seems my developers, Product Owner, stakeholders, and SQA folks take the time to point out how much better things are with me around. I love it and hate it, all at the same time... mostly because in addition to my inability to not want to learn, it's hard for me to fathom why others don't take the time to understand things.
So yeah, I'm tooting my own horn... but at the same time, I expect others to do the same and am constantly disappointed when they don't.
"In the 1960s the UK computer industry had no IT graduates to recruit. So they took all-comers - from "A" Level to PhD in all subjects."
And not necessarily the '60s either. In the mid-'80s my team at one point consisted of a botanist, a geologist, a zoologist and a CS graduate who I think would have preferred to have been an astronomer.
change until IT companies hammer into the recruitment agencies that the job spec is guidelines and if a person is close enough, then they'll want to interview
Until then we're stuck with "software engineer needed: must have 2 yrs of Java and 2 yrs of C#" when C# has only been out 6 months
Recruiters will recruit anybody for anything - the wildness of the mismatch is of no concern to them so long as you last long enough for them to get paid.
There are a very few who take great pains to place the right person in the right position because they know the true value of reputation and repeat business. Like excellent IFA's and honest politicians they are few and far between but they do exist.
My godson had a 2.1 in Computer Systems plus he had won a Microsoft Student award. The latter wasn't a tick box on big companies' online recruiting forms. He was automatically rejected because his GCSEs didn't add up to the threshold UCAS points.
Then he had a call from an agent for a big name IT company who were far more selective about how many IT graduates they recruited. They had actually looked at his CV thoroughly and wanted him - the job interview was merely for confirmation. When it came to the salary offer they far exceeded his expectations.
Another godson with a 2.1 in Economics was rejected at the telephone interview stage for a major IT company. The telephone interviewer had such a strong Indian accent that he had to keep asking her to repeat herself. He was then happily recruited for a major City accounting company - and is now a Chartered Accountant.
I remember myself being refused an internal transfer to the Systems Programming Division of our IT company as I didn't have a degree. Two years later they tried to headhunt me because I was being so successful in diagnosing and fixing their O/S bugs for another department.
...as they’re skill sets that can be easily transferred to an IT environment"
Exactly this.
People with these qualifications will do well in all IT roles - Support, Analytics, Design and Development.
The skill sets required by these subjects demonstrate a high level of technical competency, the ability to learn new complex concepts, using a logical and analytic approach - all of these are required in IT.
My BSc in Physics (with a side-order of electronics) was never going to lead me into scientific research, but has allowed me to follow my passion for trouble-shooting in several IT roles from engineering to management.
I thought IT pimps would be more interested in their own comission first!
My own musings on the subject seem to be that if an indivdual is interested enough in an IT area and has some experience then they'll probably be OK. They'll probably be more useful than people who have got/drifted into IT for other reasons, usually because of it's "where it's at/the future" or it may be more luctrative than something else.
QUOTE: In a nutshell, the tick list for successful candidates combines a logical and mathematical mind with an ability to solve problems and a good understanding of business needs. “They may not be coders, but the sorts of people who can translate user requirements in a way that a customer understands and a developer can work with,”
In other words, we need engineers.
I spent a year an a half as a recruiter, long before I got into IT properly.
It was a windy road though, having previously had a brief gig as a site engineer (civils), then a year serving pints down the local boozer, going via 10 years with BT (shifting routers and leased lines), then a brief stint at Sound Engineering college before learning (just about) to programme, which has kept me occupied for the last 30 months.
Still trying to figure out what I want to be when I grow up.
IT really doesn't need a computer type of degree. One needs analysis, problem solving, and above all communication skills. Programming can be taught. The school taught programmers and IT types I've met are, shall we say, bizarre. Yes they can code or do the things that can be done by rote. If there's something outside the box, they are lost. I have nothing against schooling but more against the academic mediocrity. The best IT types are not professors. The old saying about "those who can't do, teach" is pretty true.
On the other side, if they've had a well-rounded education, they seem to do better than those that follow a strict IT curriculum. There are so many levels in IT that to establish one criteria for all jobs is a fallacy. Some need vision, others need a bit of creative grunt work. For what LinkedIn needed, a brain surgeon was perfect. Any other job in the company, he might have fallen flat on his face.
The hiring system was never designed. It is patch on patch on patch going back to when the Scots started building steam engines. There has NEVER been a rewrite!
Some functional autistics can find work (but are probably still misunderstood by the HR patch on patch on patch on ...) and some can't. More or less by definition, we are out of the box. Nearly all of the time, there is no way for an autistic who happens to be orthogonal to the hiring process to apply for a job. To use the system everyone uses, is a waste of time, regardless of how well they could do the job. Because of HOW they are out of the box.
I've only ever run across one company which hires engineers (out of Los Alamos I believe) which has a link on the careers page: I need some other way to apply. Name escapes me at the moment.
Most of their jobs relate to "national security", and being Canadian I don't qualify.
... that's the main requirements for CITP, or other chartered qualifications. It is peer reviewed, based on what you have provably achieved - not what your original qualification was in (although that sometimes gets you a pass on some of the exams).
Whenever we have 'snap exams' at work the CITP's always come out at the top as they diligently and continuously learn as part of the maintenance of their status (Continuous Professional Development).
Has having a long string of post-nominal ever helped me get past the recruitment agents - no, because I don't have a degree and that's usually first on their tick-list.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
