One thing I find comical is the idea that young people have an easier time keeping their skills "up to date."
One of the truisms of computer science and computer industry is that the practice in industry reflects things that were current in computer science one or two decades ago. If a SmallTalk or Lisp developer fell into a coma 10 or 20 years ago, they are not going to be shocked by how much progress has been made while they were out of commission. They are going to be amazed that the median developer still does not have as productive environment as they did when they were last conscious.
Give them a couple days to get up to speed on the general idea behind HTML and web browsers, and a couple more days to get the specific details of whatever C derived syntax is being used, and they will be ready to be productive. If you are a new developer, everything you are learning is new. For an old developer, it's just a matter of learning the diffs.
I think it's a shame many new developers will never see a mainframe environment (I barely did)... There is a massive amount of things that are just "done right" (and plenty wrong) that are great things to learn from.
So even if the technology is "legacy" - there is a lot you can bring forward to almost any domain.
I went on a few interviews, and I didn't get either job. I passed a phone screening, long brutal technical quizzes, and a few hours with managers. These were for senior dev positions, but I suspect most of the candidates were younger, maybe late 20s early 30s.
I didn't feel any age-related discrimination at all, but I still felt something was wrong. I started asking myself, "why am I standing here, at a whiteboard, showing an interviewer how to recursively search a binary tree?" "Why am I creating the primal of the dual and proving that the min of one problem is the max of the other under optimal circumstances?" I solved the problems, but maybe they picked up on something from me that shows... maybe a slight irritation or exhaustion.
I realized that it's not ageism. I was irritated with myself. Sure, I "shouldn't" be doing this for the umpteenth time, but the shouldn't is directed at me, not them.
If you've been in the business for over a decade, yeah, maybe you "shouldn't" be taking technical quizzes, but that's because you "should" have a reputation to stand on, not because interviewers should see your grey hair and decide that it's a stand-in for testing your technical chops! (I got into programming late, so even though I'm 37, I've only been seriously programming for about 10 years).
I remember Joel Spolsky (a big proponent of having devs write code during interviews) still said (I'm paraphrasing here) "if you're an independent film maker and Uma Thurman is interested in your film, you don't ask her to audition, you try to sign her!"
The top celebrities in our world tend to be the leads on extremely successful open source projects. While very few devs can get this "celebrity" status, you can still a smaller useful network - and really, how many job offers do you really need?
Speaking at conferences, working on open source projects, working on side projects, writing interesting articles in a blog are all good ways to do this. On a much smaller level, just being very helpful and engaged in your job, and producing good software can help.
I'm on that smaller level, but I realized "why am I doing this?" I called up my network, discussed some jobs, and got a nice senior dev/architect position pretty quickly. No technical interview was needed, because these folks had already worked with me on code plenty of times.
It's not ageism to say that your career and approach to development needs to change as you get older. Another line I loved from a movie called "surfing for life" - "age is inevitable, it's the growth that's optional".
I'm also 37, and I haven't encountered ageism (yet). I might be lucky, however - I get most of my gigs through a tight network of acquaintances, and so I rarely have to interview. My experience is that so many places are so desperate for truly good help (where "good" also means you're capable of communicating well with other human beings), that age matters much less than it might otherwise.
Ageism exists and it gets worse as you get older. I think geebee did the right thing, but came to the wrong conclusion. If you are experienced and good, you are probably expensive. You can probably be replaced by 2 new grads, H1B's, or a whole offshore team. I was. Read the comments on stackoverflow and you will see such stupid comments as the one who said he didnt like older programmers because they talked about their kids, yeah must be old 30 somethings. Or the usual inane remarks that imply older programmers never made it beyond Cobol.
Experience does matter. LOC per year dont matter; it's writing the right lines, or choosing the right architecture that does matter.
geebee hit the interview nail right on the head. Most interviews are structured to weed out incompetent new grads, hence the programming tasks and the language lawyer questions. When I'm in an interview, I really dont want to waste my time describing when I would use an abstract class over an interface. Why waste time with programming problems with someone who has been doning it for 20-30 years. The successful interviews discuss how I would tackle the real problems that the company faces.
As someone who's conducted dozens of interviews over the last few years, I can tell you that there's no way to infer from someone's age or resume if they can code or not. Plenty of people with stellar resumes and 20 years' experience come in and absolutely bomb on relatively simple coding problems. Maybe they used to know how to code but have gotten rusty since they've been doing more management or hands-off architecture recently, but for whatever reason they can't solve problems that any recent grad ought to be able to solve. Some of those people can talk a good game when discussing higher-level stuff or when they're doing a lot of hand-waving, but they just can't translate it into code effectively. My point is not that "older" people can't code: when you do find someone with 20 years experience who can code well, they're generally incredibly valuable. Rather, it's that you always have to be skeptical and can't take someone's resume or stated experience and skills at face value. Those questions are there to filter out people that won't be successful in our company because their coding skills are below par, regardless of age, experience, or education.
If someone asks you to do something that seems "beneath" you or trivial, just do it as well and as quickly as you can so you can get it over with and talk about more interesting things, or use the problem itself as an excuse to start a conversation about something more interesting than the problem itself ("the interesting thing here, is that if you write it this way it's easier to test" or "if you used a language like X, you could write this more easily," or "realistically, I think this function would be more useful if you changed it to behave like this, so that it would then be useful for doing Y and Z as well as X.")
It's nothing personal, it's just the interviewer's job to be skeptical about your stated skills until you prove to him or her that they shouldn't be.
I think ageism sometimes shows in the assumption that the "rusty skills" phenomenon is so much more prevalent than the "untalented graduate" phenomenon. So, yes, I agree that interviewers need to be skeptical. But they need to be skeptical about their own preconceptions as well.
Part of the problem here has nothing to do with discrimination and everything to do with the market. If you can be replaced by two cheap, less-experienced developers, the market correctly determines that you should be replaced. Like comment #1 says, you need to not only keep your skills up to date, but also continually upgrade your value proposition by being selective about your roles.
Being able to hire 2 newbies for the price of one experienced developer doesn't imply that replacement makes sense. It could equally well imply that the experienced developer is a bargain.
There's legitimate worry about ageism: too often employers don't offer a non-management ladder. The answer for that is to work at a company that offers such a ladder (there are many) or work in a start-up (where they can't afford to have "pure managers").
There is also shops which are driven by buzzwords rather than actual technology, who are just looking for bunch of kids who match a keyword list. I wouldn't want to work there anyway (whether at my present age, or in ten-fifteen years).
There's also the illegitimate worry: "some 22 year-old will replace me"; this is of the same genre as "my job will get outsourced to India". The answer to that is don't do simple, trivial work. Be something besides a byte pusher (incidentally, great deal of "web development" is indeed simply pushing bytes). Anyone can make a CRUD app with PHP and MySQL: learn something which isn't immediately listed in the craigslist jobs section, perhaps? I'd argue that, for example, no place that is hiring Haskell developers or developers with understanding of machine learning practices age discrimination.
Quick response to 2nd place comment: if you're older and your skills profile is burdened with assembly language, we're always interested in talking to you. =)
Whistling past the graveyard.
Keeping your skills up is necessary, but insufficient.
Over 50? Welcome to the top of the layoff list.
The baby boomers are getting kicked out of the workforce.
There has long been worry about what will happen
when the boomers retire in large numbers.
Well, it may be happening early.
Good luck to us all.
What this tells me is that when you reach your (conventional) prime earning years, your "hard" skills focus should start tilting towards things that will help you entrepreneurially.
The reality is, once you hit 30, if there's a tangible "layoff list" anywhere you work, you have a serious career risk you should mitigate.
Developers shouldn't worry about something they can use. If you're young, people will naturally overestimate your ability to learn new things; if you're old, they will assume you already know older technologies pretty well ("If he's been doing this for twenty years, how could he not have encountered that at some point?")
There are "ageist" technology employers out there, especially on Wall Street where 35 is considered "old" (you're either MD-level or at the top of the RIF list), but my observation is that if you're good, you can always find someone who will hire you.
I think that a problem a lot of aging developers face is that many of them went into "programming" because, like law or medicine, it was a respectable career choice that provided a middle-class standard of living and a cozy work environment. This is fine, but if you're not willing to dedicate serious energy to keeping your skills up to date, you are going to be forced to contend either with an income plateau, or a move into management.
I think that at many employers experience can work against you especially if the manager isn't too technical. A 22-year-old will be like "I'm a net-generation Ruby rockstar and I'll build you a ninja terrorist website" whereas a 40-year-old will be more, umm, realistic.
I am curious as to why this comment is garnering so many upvotes.
Let me be clear; I do not think those traits are net positives overall. The fact that when we are young we are a bit too willing to defer to authority is an artefact of buggy monkeyware. Any Manager/CTO who hires youngsters because they are easy to browbeat and relatively cheap is on crack; it feels real good at first, but it destroys you sooner rather than later.
Most teams benefit from a diversity in age as well as in outlook. You need people who are experienced enough to be able to see through the bullshit, but you also need people who will stay up late hacking on a skunk works project because they are excited about the work.
I don't understand your point here. Holding the quality and priority of the work constant, the employee who is cheaper and easier to "browbeat" is in fact lower drag. The market is very rationally going to select for the lowest drag fit for any role.
It is my observation that toxic work environments are especially unproductive in software companies. Someone who hires a team with the idea of getting the cheapest and and most pliant workers is setting himself up to be forever surrounded by incompetence; real or perceived.
A sailboat with no friction (keel) can only run before the wind; it is wholly unable to sail against the wind.
One of the truisms of computer science and computer industry is that the practice in industry reflects things that were current in computer science one or two decades ago. If a SmallTalk or Lisp developer fell into a coma 10 or 20 years ago, they are not going to be shocked by how much progress has been made while they were out of commission. They are going to be amazed that the median developer still does not have as productive environment as they did when they were last conscious.
Give them a couple days to get up to speed on the general idea behind HTML and web browsers, and a couple more days to get the specific details of whatever C derived syntax is being used, and they will be ready to be productive. If you are a new developer, everything you are learning is new. For an old developer, it's just a matter of learning the diffs.