After ~five years. We should be able to change jobs occasionally and not have to hold on to our current one for dear life. Sounds like once you hit fifty you'll never be hired again, so must do anything to avoid a layoff.
The problem is that people start a career as a J2EE programmer in their 20s and expect to coast and never update/learn new skills. This will serve you fine for a decade or two, but if you're in your mid 40s and you're only comfortable with technology from the late 90s, your job prospects will be limited.
In order to have a long career in tech, you need to constantly be learning new technologies, frameworks, and languages. If you don't, you can coast for a while, but don't act all surprised at 50 when you get laid off and can't find any work. Would you honestly expect to be able to find work as a VAX/VMS engineer now if that was what you started working with right out of college and never learned UNIX, Linux, or Wintel?
Ageism isn't the only problem though, just as big is that no one will allow you to learn on the job. With the explosion of tech stacks it should be a requirement, but the opposite is true. Tech interviews under the gun are another.
But then there's all the other times when they look at you as if you were a speaking monkey...
Come to any of a dozen cities that have a decent tech representation and you won't need a year to get an offer. And I'm not talking about SF or NY, you can go to places like Denver, Salt Lake City, Austin, or Boise.
But on the other hand, I saw all these people whose only skills were COBOL and RPG3, and even back then those technologies were obsolete. They'd been getting large salaries from IBM primarily on the basis of their domain knowledge, and when IBM stopped caring about those lines, the knowledge became worthless.
Seeing what this did to people that I had been working with, and friendly with, really made a big impression on me. I promised I wouldn't let myself get into that same technical debt - but these day's that's easier said than done.
They found Perl a challenge at first :-)
This is a _HUGE_ loss to a company when a company loses someone with domain knowledge. Putting people into the "Are they good at skill X? Where X is the specific thing their title says they do." box and then hiring and firing based solely upon X is foolish to the extreme. If someone is mediocre at X but understands the business domain that they are working in they are worth the same as someone who is highly talented at X but doesn't know the domain. And while people can "learn the domain" most people don't actually want to. They'll learn it until they have passing knowledge but won't actually ever take the time to really understand it.
One of the pains in staying up to date in tech is that learning Perl then java then javascript then python and whatever comes next and the corresponding frameworks seems like a big hamster wheel. You pretty much are doing the same thing you're just learning new ways to do it -not necessarily better.
It seems like you're writing the same term paper over and over again. After a while, it loses its luster.
If I could do it again I would choose a career where gaining knowledge adds to your mastery. In info. tech, it's a lateral move and you have to keep learning or you sink.
I've also got 25+ years of contacts. I have to think that talented older developers who struggle with employment must have been antisocial in their careers. I cringed when the guy in TFA apparently threw a sandwich at a fast food worker - maybe there are some deeper personality issues at play besides just being old. It's no less sad, of course.
Re the article, I suspect a baseline anger built up over being unemployed so long. That can lead to small injustices being blown out of proportion. Similar has happened to me in different areas over the years so can relate.
When you find clients by word of mouth they rarely even ask for your CV - it's just "can you do this?".
Once I did well with the first generic question, do not filter in application code, do it in database. (Thought that was 10x more important than any library question.) Next question how to access a field with F(). Needed to look at stack overflow, did within a few mins. No offer.
Also, they will ask questions across multiple fields which can't all be studied for. One Java Spring shop asked exclusively database questions after I spent weeks brushing up on Java Spring. Could only answer 90% of the questions, not bad considering. Even had a friend on the inside. No offer.
Think about all the pass/fail exams at University with two surprise questions from any technical field. Oh yeah, doesn't exist because it would be absurd.
It's endemic, bad interviews and coderpad.io. If you've got a network you can skip most of it, perhaps why many have not realized how bad it is from the outside.
The one thing he always did was disqualify any candidate that could not answer the basic questions about our in-house stack. If you did not know at least the basics, my boss moved on to the next candidate.
Fair or unfair it did not matter. He had enough experience to know that it takes time for people to learn a new framework and language plus our in-house procedures. It was always more productive to grab someone with experience.
I suspect most employers think the same way.
At one time, employers would take a chance and time to bring someone up to speed since it was harder to find the right person. The developer pool has expanded so much that now it's easier to find someone with experience.
But now I actually like to play with my kid and travel when I'm not at work, and it's painfully obvious when people say "hey try a bit of Rust or Go or whatever" they don't mean on work hours.
This is a bit problematic, too, because I use Node all day long and I suspect it will not be a technology with a long future.
It's part of a software engineer's job to evaluate technologies and no one so far has chided me for doing so. Only the most cynically bad kind of manager would try, and some of those can be convinced otherwise when the utility explained.
You hit the nail on the head here.