Slashdot Mirror
Ask Slashdot: Re-Entering the Job Market As a Software Engineer?
First time accepted submitter martypantsROK writes "It's been over 15 years since my main job was a software engineer. Since then I have held positions as a Sales Engineer, then spent a few years actually doing sales as a sales rep (and found I hated it) and then got into teaching. I am still a teacher but I want to really get back into writing code for a living. In the past couple of years I've done a great deal of Javascript, PHP, Ajax, and Java, including some Android apps. So here's the question: How likely would I be to actually get a job writing code? Is continual experience in the field a must, or can a job candidate demonstrate enough current relevance and experience (minus an actual job) with a multi-year hiatus from software development jobs? I'll add, if you haven't already done the math, that I'm over 50 years old."
My university employer tends to hire older people for development (especially DBAs). They often do a lot of interfacing with external vendors in terms of customizing canned solutions... with sales experience, they might see that as a bonus. Try them.
By some friends' words, you'll have a much tougher time in the private sector.
you should continue teaching and sell your apps on the side. It isn't worth the headache of getting back into a field dominated by a bunch of 20 somethings who think they know everything there is to know about writing "good" software.
At 34 I've re-entered the job market myself after giving my own business a shot and I landed a job as CTO of a start-up game company. We're developing a couple of games now (one while will be in beta tomorrow) and when I look for programmers, I could care less about a space in employment as long as they can demonstrate the skills needed for the job.
I'm 63, I still love to code and am quite good at it, and I just got hired away from my current company at a significant pay increase. If coding is stressful, then you're probably not cut out for it or you're doing it wrong. Coding should be fun.
write some open source wares that do something useful. nothing like a project on the top of your resume. worked for me....
Which, at his age, he should be an expert at. I am 40 and accidentally landed a job doing COBOL development. It pays much much more, is more challenging (the earliest comments in my code base are from the 1970's) and you will ALWAYS have a job. COBOL programs are never finished, usually because they are constantly adapting to changing business rules and business relationships. It is almost impossible to realistically migrate to a new system, so its just perpetual coding. I love it, brings me back to my childhood when code was complex, languages were primitive, and you could still get great results.
I was in IT for 24 years, starting in 1985; worked for a lot of large companies and was highly sought after. Following a typical vector, asm, C, C++, VB. .NET, T-SQL, PL/SQL, JSP; managed some sizeable projects for many years, never stopped coding. Actually I think I'm an excellent coder. Reliable. Then, job was outsourced in mid-2009 and I, stupidly, partly because I had hardly ever looked for work (always came to me), just took some time off; first big vaca in decades. Error! Well, that was it. Lots of bites on Monster, etc., but between not currently employed and as soon as they did some math, no call backs. Oh yeah, one, I was yelled at. I'm > 60. So, now I have to change my field to paralegal. Hopefully, that will be a bit better; who knows. All I can say is, give a job hunt a whirl but after 6+ months of rejections, start rethinking. Grim news. (and of course 50 is not >60; >60 is the kiss of death, at least for me.
The best DBA I know was a fellow from Florida named Keith Grey who STARTED his tech career when he was in his fourties. He learned a little database and supported it for a small company, learned Oracle, enhanced the prototypes I'd written for them using Oracle a year earlier, and just kept going from there.
He's now one of the most experienced and skilled DBAs I know, riding herd over a clustered Oracle RAC installation with multiple data warehouses hanging from the main systems.
In other words, it's never too late to start a new career, much less resume an old one. The question is whether you have the skills, the dedication, and the willingness to learn it'll take to succeed. Personally, I'd much rather recommend someone with the "right attitude" and a background in business for a tech job than any of the impatient, inexperienced hot-shot kids whose resumes crossed my table over the past few years.
I do not fail; I succeed at finding out what does not work.
HR will never pass your résumé up to the person who can actually appreciate your experience and knowledge.
Any shop that has let HR insert themselves into the hiring process like that is pretty much doomed. Avoid at all costs.
Well, when the company gets beyond about 50 employees, that "Just happens". It sucks big time; but every Head Hunter I have spoken with has lamented the "Checklist" type of HR résumé-culling.
It's almost enough to make you want to stuff your résumé full of impossible experience, like many of the résumés of particularly Chinese "engineers", where it seems like the vast majority will list 30 years-worth of experience on every high-level engineering project in China they can find a reference to on the internet, and then being of an age where they would have started to work 10 years before they were born, knowing full well that there is absolutely no way to verify any of their claims. I don't want to sound racist (I most assuredly am not!); but I have seen some pretty laughable engineering-candidate résumés come across my desk, and it seems like Chinese engineering candidates seem particularly inclined to "pad" their experience (and I would suspect their schooling in some cases, too).
So, you might give that a shot, just to get past the HR gatekeeper. Then, when you get to actually talk with the person who will be your new boss, be prepared to SHOW them what you can do, and get off the subject of specifics in your résumé.
I aced an embedded developer interview a few years ago by taking out a sample of a particularly compact and component-dense product I designed the hardware and software for, and tossing it on my (future boss') desk, and saying, literally "Any Questions?"
The moral of the story is, if you can get past the HR droids, you can usually demonstrate that you have the skills. It's just getting to that point that is soooooo difficult!
These days... I'm a 36 year old guy with 20 years C++ programming experience in senior level positions, and I started programming BASIC on a Commodore PET when I was 6 years old. What I have learned since which makes a huge difference between the guy who is an awesome C++ coder and the guy who is an awesome C++ coder with 10 years experience is how natural the structure of code develops itself when you're writing it. I am just about finished with a module I'm working on for a fairly complex protocol implementation which now weighs in at 50,000 lines of code (much of it comments and white space). Everything was "designed" and is there is extensive error checking and logging.
I won't say a young guy wouldn't have the skills to do this. What I will say however is that after 10 years, you'll have spent a great deal of time pissed about how other people write code. You'll eventually learn to fix instead of rewrite. And when you write new code, you'll set a standard for the other developers to live up to. I used to say that the way you could judge a new programmer best is to see how long it takes before he's been working on nearly a million lines of legacy code written by 50 people over 10 years and say "We need to rewrite this"... which almost certainly is true... but not practical. Then how bright he/she really is is measured based on how long the developer takes to recognize that the code can never be rewritten in whole... and instead finds a way to adapt where necessary and clean up what they can when they feel it's useful.
Sadly, I have been through many projects so far where we've spent ages and even massive numbers of hours trying to decided whether or not to switch to a string class. And then arguing over how to handle unicode. Some will say "There needs to be an 8-bit class and a 16-bit class, sub-classed from a common class", others will say "The string class should use a void * internally and store the string data as 8-bit unless there are unicode characters in it. At which time it should be 16-bit", then guys like me will say "I don't care how the class stores the data internally as long as it has calls to receive it as either unicode or Latin-1.". Of course, while everyone else is arguing, then I or another will simply sit down and write the class and say "Done... here it is... use it. If you want it done 'better' then fix it. But this is the interface".
There are billions of lines of code based on code written during times when systems were more limited. A developer with more experience will have been in the industry long enough that they will understand why certain choices were made the way they were and then, change what should be changed or understand why some things were done the way they were. I still intentionally code some things the old fashioned ways to make it perform better. There's really no reason that code designed to pack bits into a stream should be heavily object oriented. A flat design is nicer for that.
So... There is a benefit to programmers that are "A Bit Old School".
But... I will say this... the 27 year old guy who sits to the right of me... even though his coding style is not quite refined and sometimes he introduces structural complexity beyond reason to make sure "He uses the right pattern". He gets the job done as well. Sadly, documentation is an after thought for him, but there's no reason if he and I were to apply for the same job somewhere else that they should pay more for me than for him.