I’m going to disagree with some of the other posters here.
Because, while it’s true that there’s ageism, and it’s true that a resume without experience is going to look bad, I’d still say it’s an easier industry to get a foot in the door – even later in life – than other industries.
Because a lot of importance is put on demonstrated ability.
Yes, there are plenty of jobs where a company is looking to invest in training someone up over the long term, and ageism is of course a factor for those jobs.
But, arguably more often, there’s just a desperate need for someone who can do X, right now, and the guy or gal who knows this language or API the best will get the role.
So, for example, if you can somehow train yourself up to be an expert on a system, you can call yourself an expert on your CV. You can list projects that you’ve implemented (if those projects were just made at home, that’s even better because you can include a link to download the projects and source code on the CV). And at interview you will be tested on your knowledge, and if you answer those questions like a boss, you’re in.
Yes, the critical thing is “somehow”. It’s one of those things where you need hard work, some aptitude, and time to do all this. It’s not easy. But the door is not closed, is all I’m saying.
I’ve been involved in interviewing at several IT companies, and on several occasions we hired the “outsider” with little or no experience of working in the industry.
In my experience, ageism doesn’t really apply to contract work. When we just needed someone who had skill X, we’d hire a contractor. No one really cares how old your contractor is if they can do the job.
Full-time, permanent employment is another matter. It costs a company a lot of money to hire an engineer - often just about the equivalent of a year’s pay. Companies don’t like to expend that kind of time and money on someone they know is just a few years from retirement, and who may not be good for team cohesion on a team mostly comprised of 20-and 30-somethings.
I read a statistic a few years ago that said of all the people who graduate and become working programmers, about half leave the field by age 30 (either moving into management or sales, or leaving the industry entirely). Of the remainder, half are gone by age 40, and half of that remainder by age 50. It’s rare to find a peron still working as a programmer at age 60.
Part of that is the high burnout rate and need to stay current, and part is ageism. Some of that ageism is justified, and some isn’t.
I think that a LOT of it is the staying current rat-race. I mean, I graduated from college in 1996, and came out having learned C and C++, along with a bit of Ada, LISP, FORTRAN and a fair bit of SQL.
Since then, I probably would have had to retrain myself several times, or have had myself relegated into a pigeonhole of working in some obsolete/obscure language along the way. That gets expensive and/or exhausting to basically start over every so often and have to compete with twenty-somethings to do that stuff. Meanwhile, a say… civil engineer is going to be doing basically the same stuff he was doing 23 years ago- maybe there are materials changes, or regulatory changes, but the actual practice of engineering isn’t much different, and it’s not like they’re going to have had to reinvent themselves twice or three times just to stay relevant.
I’m personally a firm believer in the concept that (to paraphrase Heinlein in “Starship Troopers”) “there are no dangerous weapons, only dangerous men”, meaning that the language isn’t really the important thing, but rather the thought process and ability to decompose problems and the planning aspect of how to string together modules to solve a problem. The actual programming language is a lot more trivial by comparison. But recruiters and a lot of technical hiring people don’t see it that way.
I’d agree with this, and I’d agree with Sam_Stone’s assertion that your resume, etc. matter a lot less when you are applying for a position as a contractor. I’ve worked support or IT for more than 20 years at this point. I’ve been in bizarre situations. At one point through a game of “who’s too lazy to look for a better job?” I ended up being both the CTO of a web hosting company and also the only guy available to take support calls for a few hours each weekday*. I was a full time employee there, so, being a contractor is normal by comparison.
My current company tends to hire in exactly the same mercenary method that I would in this particular IT world where there are plenty of folks who have good credentials and can bullshit their way through an interview, but they don’t have what it takes to actually do the job, whatever that is in that particular job. Just about everyone is hired on a contract. If you can hack it, your contract is either renewed or you’re made a full time employee. If not, well, you can always apply again after your contract expires. If you weren’t fired and your contract wasn’t renewed, you’re still eligible to be re-hired if you interview well. In my company, some people who can’t hack it technically but can either just put up with the demanding idiot customers or are actual geniuses who can develop a rapport with the madmen become dedicated support for them, and their job is to basically marshal the correct support groups to help their customers.
I’m senior enough there that they ask me to be in interviews to ask questions. In those, resourcefulness and knowing when to admit you don’t know the answer go a long way. I’ve happily recommended people to be hired because they readily admitted they didn’t know the answer, but they presented a plausible method of finding out how to answer the question. Seriously, if you’re planning on working IT/support, general problem solving skills and an instinct for detecting when you could be leading yourself wrong go a long way.
If you show you can educate yourself, that is always a good point. The technologies change constantly. While I was a Unix admin, the language in fashion was Perl. PHP eventually took web development by storm, but Python is the language my current house is steeped in, so I learned each of them in turn. However, you don’t really have to be able to program to be a dandy IT/Support worker. It can’t hurt, though.
So, do I think you can get an IT job at 58 with your current experience? Hmm, that depends. If you can show you have a proficiency in the skills you present on your resume during an interview, then perhaps. You’re probably going to have to take a terrible front line job at first. $50K is probably not on the menu for the first job. But if you’re willing to leverage everything you have into searching for a new job as often as you can, that could be had after a few years. When I was soup to nuts for the web hosting company, I wasn’t making $50K, but everyone who had the sense to jump ship elsewhere was generally working for double my salary. When I left that for a support job at a large company, I did the same.
*One of my favorite exchanges on a support call (paraphrased, I didn’t actually take notes):
Customer: Can we escalate this issue? I think you’re wrong.
Me: Umm, no. We can’t.
Customer: We cant?!?! Why not?
Me: Well, I’m the CTO, and the only place to escalate it to is the CEO. He’s not technical, and he’s just going to ask me what I think.
Customer: Oh.
Yes, I’d just like to emphasize this too, as I also was involved in interviewing.
When we interviewed people, the questions were usually written by several different people, covering different areas of speciality.
Why?
Because we wouldn’t just recruit one developer at a time. We were interviewing for several teams and projects at the same time. Even if team A and B both need someone to develop software in Java, Team A might want someone with more algorithmic / scientific development experience, and Team B’s requirement might be more on the UI side.
So kicking ass at one section of questions, and admitting you don’t know much in the other, is still a damn good interview.
Meanwhile if you try to BS your way through the part you don’t know, you’ll be found out, and may even be embarrassed during the interview.
Finally; one interview I sat for, I was given a programming task to do, and told it was “open book” i.e. you could use google.
I completed the task fine, utilizing a little googling, and got offered the job.
Later I was asked to conduct some interviews, and initially I gave candidates the same task that I had been given. I was astonished by how reluctant candidates were to just look stuff up; I would be telling people repeatedly that they could just google the method name or whatever, but they wouldn’t do it. I eventually gave up on that style of test, as almost no-one succeeded.
So remember: real programmers rely on google, books and/or intellisense day-to-day, and if a task is “open book”, then use these resources.