Skills pay the bills.
Many of the over-40 crowd I've worked with just plain don't want to learn anything new. They have settled, and are passive in their learning. This is the #1 reason they won't be relevant.
Many of the over-40 crowd I've worked with just plain don't want to learn anything new. They have settled, and are passive in their learning. This is the #1 reason they won't be relevant.
This is almost analogous to complaining about construction being ageist against older people who don't keep in shape. Yeah guess what, you need to in order to do the work.
You and I know that picking up a new language or framework isn't hard, and getting up to speed in the libs is just a case of some time and google. Recruiters, especially agencies and HR still don't grok this. I rarely had problems if I got past those to the techies or founders.
What I've experienced is that many of the tech managers either 1) couldn't hack it to begin with, so they pivoted (this pivot may have been in college, or in the workforce), or 2) haven't stayed relevant themselves.
I know understanding CS fundamentals and employer expectations about this are a lightning rod here, so I don't want to apply a value judgement on that here. However, what's the equivalent to the board or bar exams in our field (that lets us compare ourselves to those fields)?
We don't have the equivalent in software, and we also seem to have a recurring discussion about effective ways to filter people during an interview process. I've certainly had mixed results in my limited sample set when considering past experience to actual performance of hires.
Is there a good way to translate the value of someone's experience?
EDIT: For that matter, I guess I should wonder how folks translate the value of people in those other fields effectively (or if they do at all).
Honestly -- more people work in the 9-5 environment than the Sillicon-Valley brouhaha. You just hear about the brouhaha more because it's a much sexier thing to market.
1> Wrong, because "something new" is often ill-defined and often not _really_ new. For example, in the area of 'DevOps' (itself ill-defined) there are numerous tools and frameworks. But what you really need to deliver as a Sysadmin/SRE/Devops person, is a strong understanding of exactly _3_ skills: Operating Systems, Networking & Programming.
Because people & companies do not understand this, we end up in situations where they reject a candidate because they don't know Ansible, but the candidate knows a lot about Python, Linux, SSH and so on (ie things that Ansible is actually built on).
Many folks don't need to learn "new" things to stay relevant.
2> Right, because its not easy to actually gauge a candidate and determine that a person will _learn_ and deliver on Ansible simply because they have such good Python, Linux & OS skills. They don't even know that if the candidate doesn't know Ansible, I need to quiz them in other ways. That is often because the interviewer is not up to the par either.
This wrongly places the burden on the candidate to reply that "I'm an expert in Ansible", and "learn" something they don't really need to.
Coupled with the fact that many candidates themselves flat out lie and are incompetent etc.. you get the market situation for 'aged' people today.
When you end up with more commitments and some kids home isn't quite as conducive for learning, and spare time is often a distant memory.
I concede there is a (often reasonable in my view) reluctance to rush to learn the 249th new framework that is the future. Especially when it does all the same things as the 134th just with utterly different semantics and libraries. It'll be dead in 4 months and the 250th will be the new hotness.