Job market for a 30+ person learning to code?
Hi there,
I was wondering if anyone has any experience in the job market after learning to code later in life. I'm 37 years old and I have about 4 semesters (probably a year and a half) worth of coding classes with a focus on Java and Android. I think that at the pace that I'm going I will be able to claim some level of expertise by the time I'm 39 or so, but my fear is being to old to be employable.
What's your take?
74 comments
[ 2.5 ms ] story [ 130 ms ] threadYou are in a difficult spot. It is not so much that younger developers are better, but developers that start young shows that they have passion, and are not simply chasing a paycheck. You need to prove that you are not only a competent developer but also that you are passionate about the field. Start reading ... A LOT.
When people say they would rather hire junior programmers it is because of their drive to learn new stuff and their use of the most modern techniques, not their age.
Java is a great basis to work off, and I bet you'll get a fine job with it, but also consider learning a more dynamic language like Python, perhaps learn it at codecadamy.
I don't personally have any experience with being 37 and looking for a job, but I don't see a reason why someone should turn a fine developer down because of his age.
Also, 37 is not very old at all..
1. They are cheaper
2. They are more likely to have less focus on work-life balance (i.e., willing to work crazy hours)
3. They can be more easily molded to a company's development philosophies or culture
First off, remember that it's not legal for a US employer to ask your age. They can only ask if you're over 18. Of course, if you want to be sly about it, you'll need to craft your resume carefully (putting the year you graduated from high-school or college can tip off). Also, your looks may or may not belie your age (I have no gray hair and can look late-20s if I shave my beard).
Also, I think the biggest (perceived) issues are that either (a) employers don't want to hire older developers because their experience demands higher pay or (b) they want younger developers who can work insane hours. I must say, I don't know if these are generally true (they aren't when I hire people).
But for you, (a) shouldn't be an issue. You're a new developer so you probably are fine with a entry-level salary.
It's probably best to avoid companies that think about hiring in the way that they'd think about selecting frat pledges, in favor of companies that think about hiring in terms of increasing their capacity to get work done. But if you really wanted to get a job at the former kind of company, my advice is (1) try to build a rapport with your interviewers somehow, so that they look up to you and think you're cool, rather than pity you for being old and wanting to be let into their treehouse, (2) contextualize yourself as having gotten really excited about programming all of a sudden, after a few decades of kicking ass in other fields, and then having made a lot of progress in programming very quickly. That's something that anyone can respect.
Just to clarify on the legal distinction: They can ask, and you can answer or not. What's illegal is making an employment decision based on age. Of course, the most foolproof way to prove to a belligerent labor attorney that age did not drive an employment decision is to never possess the age information in the first place. So nobody asks, and any company big enough to have an HR department internally forbids it from asking about age or any other protected factor like national origin and religion. But it's not illegal simply to ask.
Also, the Age Discrimination in Employment Act only protects workers over 40. 37 is actually fair game for discrimination.
Citation for both of the above: http://www.eeoc.gov/facts/age.html
Several years ago things like lambda functions, scope and closures were weird and hard to comprehend for me. It took time, but after all you can become fluent.
As I see now, it doesn't take as much brilliant mind as it takes just "flight log hours" to handle complex problems. A guy who won a national programming olympiad (Russia) told me he won by "outsitting" the others, ie. he took more time to prepare and knew more cases. Although it was a disappointment for him (that problems became all the same and boring), it's a nice surprise for us: we (not-CS-graduates) can eventually cover the "flight hours" gap.
Most coding jobs, especially for junior devs, are going to want code-samples - that's where you have a chance to shine. Contribute to an open-source project or create something you can share (even if it's a 'how to get started with X' kind of project, it lets you demonstrate your coding/documentation approach).
If you get good, your skills will speak for themselves. And besides, discrimination based on age is illegal in many countries.
This logic doesn't apply to someone just starting out at age 37. Here there's a really easy explanation for why you're mediocre: you just started out. And I find myself viewing someone who, say, just got out of the military at 35 and is now trying to get a job as a programmer at 37 very differently than someone who has been writing CRUD-screen apps for 15 years.
I wonder if the reason why programming tends to be more ageist than many other professions is because learning new things is really a core part of the profession. An accountant can take their core skills and jump into any job, because the rules are basically the same everywhere. A Ruby-on-Rails dev can take their skills, but they will have to learn a good deal about the existing codebase to be productive regardless of whether it's using the same framework. So someone who shows they haven't learned anything new in 10 years is toxic in the software industry.
People like myself who have been programming or working on computer tech stuff almost their whole life would have learned how to consume and adapt new technologies simply as a way of life. I think the whole ageist concept is out of date already and will just continue to deprecate even more as people who grew up with changing technology and embraced it will become the majority in the field.
In the real world, your age is a handicap, no matter what people say. Look for differentiators. A great one is the ability to point to something reasonably complicated that you built from scratch and shipped. Very few programmers can do that, and the ones that can are a class above in the eyes of many employers.
One thing you have going for you is actual life experience that a fresh college grad can't possibly have. I'd try to figure out a way to emphasize that in the interview process. Certainly it's a better strategy than trying to hide your age.
I earnestly recommend going WAY, WAY past whatever you're learning in class, and becoming a subject matter expert in whatever you like working on most. If it's Java, read the entire JVM spec, for instance. Many employers will test primarily for raw problem-solving ability and general CS knowledge in interviews, but I find that intimate, detailed knowledge of one or two areas can also be a powerful differentiator.
Of course, make sure you can actually code. The only way to do that is to code a lot. Remember it's possible to know a lot, and even be able to explain a lot of technological concepts, and still not be able to code worth a damn. Don't be that guy. If you ship something substantial, you're going to have no choice but to do a good deal of coding, and enough server admin / networking / etc work to get an idea of how everything fits together, and a taste of the sorts of compromises one makes in actually getting something out the door.
I suffer from a different, though similar, disadvantage in the interview process: being black (and dressing, acting, talking like it unabashedly). I've learned to live with reduced initial expectations over the course of my educational and professional career (not interested in a debate on this; I have dozens of unambiguous life experiences to confirm). The upside is that people are primed to be surprised by what you can do. Try to view that as an advantage.
If you want to be a real hacker, though, (Why else would you be here?) you need to be a little crazy, and obsess over the deep details of your specialty.
The former is good. But in case of the latter, I wouldn't want to touch your code with a ten foot pole. (Even complicated Haskell type trickery, or, say, mathematical optimization algorithms shouldn't take longer than a few weeks to explain.)
I guess, the original ten years was hyperbole?
How long did it take you to become an expert in mathematical optimization, for example? I doubt very much that that's something you picked up in a few weeks.
But here's where my contention lies: Making those choices is hard. But you should be able to explain the logic behind them (or how you came up with a solution) in a few weeks.
To give an analogy: The first task is like acquiring a map of a territory. That needs painstaking surveying of the whole area. The second is describing a path you took through that territory. You needed the whole map to choose the right path, but describing the path should be faster than acquiring (or describing) the whole map.
Or you could go that way, and do it as the parent says, and end up like me, somewhat dazed and confused a decade later.
Just because you invented radio does not mean the programming you put on it is the best. Realize that programming(computer) is a skill that most can achieve only through rigorous grind.
There, I saved a few years of frustration to you. Knowledge is power. Amen.
Then again, this is HACKER news and what I've described is pretty damn close to the core hacker ethic.
The two languages I call myself an expert at are Python and Javascript, I can say confidently that I wouldn't call myself an expert at the former without a damn good understanding of the entire language, data model, standard lib, and standard CPython implemention, nor the other without at least a decent grasp of the ECMA-262 spec, the knowledge of which comes into play more often than one who hasn't read it might guess.
Your chess analogy doesn't really make any sense, sorry. A better one is to understand how a car is built before you drive it. I think that might just make for better drivers.
Hopefully, the OP and those reading the discussion take away that you shouldn't stop at proficiency. Strive to know your stuff down to the bits. Don't become complacent; as I've read elsewhere here, Feel the incline, and walk uphill.
Yep, I agree. That is a better analogy. If you know how to build a car, you will be an expert at building cars, not driving them. I mean, how many of the better racing drivers are builders themselves?
If you always have to think about the how, the expression and the art suffers. Always. Human brain does not think in abstract logic, no matter how much you convince yourselves otherwise(may be except for some). It is always better at thinking intuitively.
Now, if you disagree, I would encourage you to keep posting. I like to discuss this. Not just to challenge you, but would like to know about the mistakes in my thinking.
I do not think that phrase means what you think it means, given the rest of your post.
Honestly, building something tangible skips through a lot of the other pieces.
You're 37 now, you definitely dont want to be in a cube farm with a bunch of other resentful folks who write code for a fortune 500 company. I'm sure you have some domain knowledge around something else. Perhaps you were a flooring installer prior to code. Maybe you were a plumber, who knows. Take that skill and think about what software could have helped you during those times. Look for competitors, evaluate the market and then once you find that idea in that proper niche market. Go for it.
Another book to listen to: Start Small, Stay Small
Good luck!
I'm well aware of the concept of sitting down with a piece of paper and a pen and trying to come up with ideas for projects. Unfortunately I'm struggling with the right balance of "reading to learn" and "doing to learn". I know that doing things, implementing ideas, etc., is probably the most productive and beneficial thing I can do for myself, but I get into this "I most read about this and that" loop that is not efficient.
The little amount of time I've spent trying to come up with projects have been unsuccessful but only because I do not spend considerable amount of time brainstorming. Your advice on how to approach this is excellent. As I wrote in my updated YC profile, I think we need more music apps for Android, but real music apps, not toys, so this is something I should put my attention on.
http://www.slideshare.net/Alex.Osterwalder/successful-entrep...
there are a ton of resources on Stanford's Entrepreneurship Corner:
http://ecorner.stanford.edu/
and Steve Blank's blog:
http://steveblank.com/tools-and-blogs-for-entrepreneurs/
Steve Blank wrote a book called Four Steps to Epiphany which is really good and advocates his "Customer Development" strategy:
http://www.stanford.edu/group/e145/cgi-bin/winter/drupal/upl...
You'll see a common theme on most of those sites, which is basically to listen to the customer, "get out of the building" and validate your idea early (thus, the MVP)
If you need some inspiration for brainstorming and protoyping, Stanford has some advice on their Design School site
http://www.gsb.stanford.edu/exed/dtbc/
and some material is available here:
http://dschool.stanford.edu/wp-content/uploads/2011/03/Bootc...
look up "pretotyping", and the book Pretotype IT, it will inspire you:
https://docs.google.com/file/d/0B0QztbuDlKs_ZTk2M2RhZWItYzk3...
i recommend to stop seeing age as an obstacle, see it as an asset - what did you work before? see your new programing experience in context of your previous work experience.
note: i'm 35, i love starting over
I currently work for a non-profit as a "database administrator" which actually translates to MS Access manager, and I do other things like update their website, edit, write, etc. I've been able to use a lot of the skills I learned from my MySQL classes with Access, and web development from doings lots of Google searches about PHP, CSS, etc.
Another thought: younger engineers are sometimes preferred simply because they're teeming with naive energy. When I think of hiring someone who I know will spend majority of their time grinding down a mountain of technical debt who do I look for? A naive 20-something college drop-out who will work themselves to the bone for 80k, beer and foosball? Or a 40 year old pro who's been through a successful acquisition, has enough money to not have to work and will figure out in about 2 days how lame the founders are for letting the technical debt grow into such a monstrosity?
If you don't, then you may be wasting your time.
If you're not sure, keep going until you are.
a lot of employers are going to also ask: what do you do to keep up with the changes in technology?
also, learn SQL. it's easy, and necessary. pick a database, install it, become somewhat familiar with it.
First, the cultural fit. If the company is all mid 20-somethings, would you fit in with the team. ?
Secondly, are you really set in your wise regarding your code and almost as important, what SDLC you're comfortable with (because we aren't using waterfall here!)
So I wouldn't ever not hire someone just for being old, but those are two concerns that I'd have with any candidate and they're a little more of an issue with older developers.
That said, regardless of your age, what is going to get your a job is networking. Start getting involved in the community now. Take on freelancing projects. Attend meetups. Get to know people.
Most of my team is in their 40s and I don't think they would have any trouble hiring an older person as long as they had talent. Honestly, you might be a better hire because you're less likely to leave the company in a couple years than a 21 year old that's still trying to figure out what to do with their life.
Even 20 years ago, Microsoft, et. al. focused on hiring kids right out of college... they're young, easy to mold, cheap, etc.
I won't say the job market is closed to you, but I think that the best power you always have comes form making something yourself. IF you have trouble getting a job in this field, building your own startup -- and I mean, a real business that sells someting to people, SaaS, or whatever business model works for you- something like patio11 -- would be making your own job.
These days we don't need the capital concentration that companies represent, you no longer need to do time as an employee. You can make your own job.
They may have, mistakenly, undervalued your experience but that's a bad leadership decision, not discrimination.