Slashdot Mirror
Ask Slashdot: Will Older Programmers Always Have a Harder Time Getting a Job?
Theseuss writes "Given the strong youth culture associated with the modern day Silicon Valley startup scene, many times it falls to the 40-year-old programmer to prove that he can still use the newest up-and-coming technology. Yet the rate at which the tech sector is growing suggests that in 20 years there will be a an order of magnitude more 'old-hat' programmers in the industry. As such, do you think the cultural bias towards young programmers will change in the near future?"
False premise. Assumes a bias without providing evidence.
I personally believe that the experience older programmers provide over younger counterparts makes them a desirable hiring option. The catch is that the price has to be right. Some of the older developers demand two to three times the salary of younger programmers. When you do that, you have to ask yourself if you deliver quantity and/or quality two to three times greater than those younger programmers. If you honestly believe you do, then your next task is to prove that to prospective employers, but it's going to be a tough sell. It can take close to a year for someone to realize that they hired a fraud, so you're a more expensive gamble to that employer than a younger employee.
There are certainly older programmers who can produce much better software at faster rates than their younger counterparts, but it is difficult to prove and requires the employer to take a greater risk in hiring you.
Finally, is it me or was there no article at all? Seriously, Slashdot - WTF?
Honestly, any programmer that is worth his or her salt is going to be employed no matter what their age. There are plenty of schools and non-profits looking for help. Of course they may not pay as much as the corporate office, but you'll be working. I also think you should start looking to strike out on your own as a contractor or freelancer soon after 45. I say this as a 52 year old who is exploring other options now. I'm writing some mobile apps for a local school district as part of my community service and I know from speaking with the administrator that I've got at least one way to earn should my company decide to push me out the door with my gold watch.
The "real company" I work for (which makes boring-as-shit medical billing software) is in Atlanta, and the programmers seem to be pretty evenly distributed in age from 20s to 50s. I'm sure similar companies exist in every decently-sized US city except maybe for the Bay Area and Manhattan.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
ADP, Kronos, SAP, IBM, Boeing, Northrop Grumman, etc. They hire legions of programmers and they prefer older types that arent going to jump ship at some chance to work for the next Twitter
As someone who gives CS interview problems, I have to disagree with your assessment. The problems aren't designed to prove that you can implement a bubble sort. It's meant to be representative of the sort of typical hard problem you'll be faced with writing software. The reason why we choose CS problems is because they are properly bounded, they have a finite number of correct answers, and if you get off course while working them out on the board, we can better help you to get back on course. Furthermore, there are decades of research that have gone into these problems, so a naive board implementation leads to all sorts of prompts for interesting questions.
Most of my evaluation has nothing to do with whether you get the right answer or the wrong answer. It has to do with how you arrive at the answer, and how you respond to constructive criticism, or in a pair programming environment. I couldn't care less if you can write a bubble sort coming in; if you solve the problem quickly, I'll just substitute a different one that you can't solve quickly. It's the process by which you arrive at an answer that interests me, and CS problems are, by far, the easiest way to uncover this.
But I've been on 3 interviews so far where showing your work merited a "sorry, that's not fast enough" with nary a discussion on thought process, coding style, etc. I even explained my thinking with the dataset and worst cases.
It'd be one thing if it was used as a way to glean a thought process, but when the bottom line is merely O(n) vs. O(log n), you're not looking for candidates who can find a way through a problem. You're using specific knowledge as a sieve. And that's where the age bias comes in. The experienced programmer knows that the answer is rarely X or Y, it...depends. And sometimes that "depends" and the design around it is the key to scaling later or blowing your leg off. I'm not saying every experience programmer knows it, but the young ones rarely do. But they're sure up on their mergesort implementation.
I've yet to have someone give the version of that test where the hard coded array or hash is the solution, because that's what you get to from experience: knowing when to be fancy and when to be specific. The academic solution seems to be built in from the start. And that favors the recent grad, period.
Today, the digital world is young and new
The managers are young, the employees are young, the customers are young
Once upon a time, the railroad was the hot new tech, then radio was, then tv..etc
Someday, software will be as mature, professional and boring as ball-bearing engineering
I suspect that ball-bearing engineers suffer no age discrimination
BTW..I am a 60 year old programmer who is turning away work. I work in the totally non-sexy world of embedded systems and industrial equipment
Indeed. Unfortunately that results in bloated, insecure, unreliable and unmaintainable software as well, that very soon gets hugely more expensive than any real or perceived gain from hiring "cheap" developers.
For the current generation in 20 years, I have little hope though. They are mostly incompetent and paying more for them does not make the least bit of sense except for the few that are actually good at what they do.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It's all related to the most profitable configuration for the company.
The problem is, "profitable" usually actually means "what will get me (high-level exec) the most profit in the least time?" Often followed by "before I bail the ship I just helped sink."
Shore that up with bean-counter metrics, projections that fail to properly account for costs (especially intangible ones) and you can easily justify "saving" money by preferring the inexperienced. The only reason why anything has any quality anymore is that advanced manufacturing techniques and materials allows relatively incompetent and de-motivated employees to turn out items that exceed what was possible 50 years ago when low price and cheap junk were more obviously related. Software, however, isn't something that benefits much from microprocessor-controlled fabrication equipment, which is why cheap software is still cheap junk.
The old-time model of a corporation was based on the idea of a more or less permanent core population of differing levels of skill and experience. Since the 1980s the model has changed to the conceit that everyone is an interchangeable cog purchased at commodity prices, used up, and then discarded at will. Except senior management (who are obviously unique, indispensable and irreplaceable, thus mandating extreme compensation).