Oldies in Tech: Hiring and Getting Hired

"I'm in my 50's, I've been a successful programmer for 30 years, yet I can't find work." That was the opening sentence for a 2015 blog post I wrote two years before my "On Getting Old(er)" post went viral earlier this year. Note that but for a month of unemployment brought on by a ridiculous non-compete lawsuit, I’ve been gainfully employed as a coder since 1983. My blog posts have positioned me as a sort of spokesperson for Oldies. I spoke at QCon New York 2017 and InfoQ requested me to author several articles on this fresh topic of aging workers.

In this piece I will speak from my experience and heart on the subject of hiring and getting hired. I’m writing for two audiences: Oldies looking for work and Youngies doing the hiring.

Before I go on, understand that I’m unapologetic about my use of the terms Youngies and Oldies. Oldies may be politically incorrect but do you really want me to use: "Person of age" or "Person of experience"? Perhaps you’d the prefer mathematical definition of: An Oldie is someone who is 1.37 times your age and a Youngie is someone that is 0.63 times your age. For me a Youngie is a coder that is younger than my children (31-35.) Context and algorithms aside, when I use the terms Oldie and Youngie you'll have your own perspective.

Oldies Need Not Apply

Why aren't companies hiring oldies? I believe it comes down to the following perceptions:

• Oldies aren't up on tech and otherwise can't learn new tech
• They won't work extra hours
• They won’t fit in with younger devs
• Because of their many years of work, they expect a top salary
• They want your job
• Most have no public github presence, suggesting they lack valid experience

Life-long Learners

Reality, as it often is, differs from perception, Many oldies are lifelong learners that are current with technology. On the flip side, I’ve seen many cases where Youngies stopped learning a few years after college after they’ve obtained a competitive salary. As to extra hours, Oldies are often able to work extra hours as they no longer have kids at home. Note, however, that they have learned the truth that we all need 8 hours sleep to be effective and there needs to be a life/work balance.

Fitting In

As to fitting in with younger devs: company culture benefits from diversity. And what is a good company culture anyway? Is it going to sports bars and drinking beer late into the night. Perhaps that works for some companies but it excludes a wide range of quality coders. A good company culture is one that shares a zest for learning. One that coerces pairing and mentoring. Where staff embraces criticism and are adaptable to change. Where humour is appreciated and there are opportunities to express personal interests.

I’ve grown as a developer working with:

• An Indian build engineer that is happily married with the wife chosen for him by his family.
• A Colombian firmware wizard that is bringing up 2 children by herself
• A Jamaican Cobol/Java programmer who represented the US as a hurdler in the 84 Olympics

I’ve found that Youngie developers appreciate the perspectives of someone that knows current technology but also worked on mainframes. An open company culture allows me to learn about the lives of fellow employees and for them to learn odd things about me (like my 6 month tenure as a prison guard) and other devs.

Salary and Your Management Job

As to the Oldies salary expectations, know that, due to ageism in tech, they have been lowered. If the Oldie was really after the big salary, she’d be going for a C-level position. Understand that the Oldies don’t want your job. They’ve probably had management jobs in the past and they just don’t want that career path. The truth is: we Oldies just want to have fun coding.

That’s certainly not to say that the decades of experience working on teams does not make Oldies a great resource. Youngie managers should, discretely, ask sage Oldies:

• How they feel things are going
• Thoughts of how other devs are doing and how they might be helped
• Reactions to the new tech being promoted by the web and other devs

In my career I’ve been on many teams where the team lead (manager, supervisor, or what have you) didn’t see something that was obvious to me. Case in point, a few years ago I was on a big project for a Fortune 100. I was put on a small sub-team where my supervisor was an ultra-Youngie that had been with the company for several years. It was a Groovy-and-Grails project and I had to continually remind my supervisor that, unlike most of the other consultants recently brought on to the twenty-plus person team, I had 8 years of Groovy-and-Grails experience and was well published on the subject. He gave me the mundane task of migrating Java 1.4 code to Groovy (easy, but time-consuming.) Mid-Sprint we were given another developer. This dev was an Oldie (to the supervisor, not me) as he was in his forties. He had no Groovy-and-Grails experience but I found him to be as smart as a whip. The supervisor put him on a task that had nothing to do with our impending project delivery. I strongly suggested to the supervisor that he put the new guy on the migration of a particularly gnarly (am I too old to use the word gnarly?) chunk of code. The supervisor flatly ignored my suggestion and kept the new Oldie on non-critical work. When we moved into all-two-dozen-hands-on-deck integration testing, guess what section of code had issues? Yeah, the gnarly code. But, now here’s the thing… guess who fixed that complex code? The snubbed Oldie. My point: Don’t discount the coding skills of Oldies and seek-out their wisdom.

Github Presence

It’s become a trend that some hiring companies expect coders to have public projects on Github. So they might easily look at your code, many employment advertisements ask for github profiles. But us Oldies entered the workforce before CVS and Subversion much less Git. We were busy building profitable applications and raising families when the Youngies were in school and had the time to contribute to opensource and otherwise make sample applications. Those of us that are on Git are most often in private repositories.

Hiring companies are missing out on a large segment of developers when they filter out applicants based on github presence. If they want to see code, they should ask for code samples. I actually have three or four large projects that I started and hosted on my github account but their intellectual property rights belong to the people that paid me to write those apps. My suggestion to interviewers is that they pair with applications in a screen session and do code walkthroughs on source that might not otherwise be available publicly.

The Cover Letter

Oldies

The cover letter is your opportunity to shine. But you have only one page and a couple of paragraphs. The first paragraph is vital yet must be both short and eloquent. This is your "me" opportunity. Say why you want to work for the hiring company and why you are sure you would be an asset to their team. Explain how you are looking forward to growing/learning at their company. Let them know, directly or indirectly, that you are an Oldie. You don’t want to go to an interview and be immediately passed over due to the wrinkles and white hair (which, by the way, is a badge of your wealth of experience.)

Don’t drone on about your decades of experience, it’s already in your resume. It is obvious and with either be ignored or implicitly appreciated. Instead emanate your zest for learning and your desire to continue your track record of success. In short, don’t talk about your past, talk about your future.

I’ve sent out many cover letters. Too often I used the shotgun approach and hastily sent out carelessly written letters. As a result, my overall response rate has been very low. But here’s the thing: every time, let me say that again, every time, that I made the effort to write an eloquent cover letter, I got a response. Lesson learned -- put time into that cover letter.

Youngies

Yougies… please, please, don’t bring in an Oldie for an interview if you are pretty sure you won’t hire them. Don’t waste their or your time. It is very demoralizing (and sometimes career destroying) to be ignored due to ageism in an interview. Let go of your misconceptions of Oldies and, if the cover letter intrigues you and the resume is strong, bring them in for a legitimate interview.

The Resume

Oldies

First, understand that resumes aren’t used to select employees; they are used to filter out candidates. No one gets hired because of their resume.

Provide detail for years that are directly relevant for the job. For instance, I have depth in my resume for work I did essential post Web 2.0. I certainly cover stuff I did prior to that period but I have it in there to show that I have lots of IT experience and a track record of success.

Don’t list jobs so much as tasks, projects, and ROI. If you spent years working for one company, you probably had many positions. If you truly had only one position one then provide detail for the multiple projects and tasks for which you were successful.

Explain how the company benefited from your work -- from a non-technical perspective. Write as if you are speaking with the CEO not a CTO. Here are a few examples from my resume:

• Built a retail web site for a wholesale supplier that generated 1 million in revenues in its first year
• Designed and coded a patented "Learning Parser" that pulled product names and prices from web sites
• Rescued a dying start-up app built by contractors using three years and $1,000,000 to make an unmarketable mess

Don’t go on about titles and promotions. Titles are moot. I believe most fancy titles were invented by companies merely a way to coerce Human Resources to give increases to good coders. I clearly recall (one day in the last century) coding in my Circuit City cubicle and a visitor asked me what my title was. I didn’t know. Didn’t care. Said as much. The visitor looked out the window and said "But you have a windowed cubicle, so you must at least be a Senior Blah Blah Blah." Whatever, I just wanted to get back to coding C++. I used to tell people my title was "Coder" but now that I’m an advocate for Oldies, I give the tongue-in-cheek title of "Senior Coder." My point: Show accomplishments in your resume not job titles.

Interviews

Youngies (On Interviewing an Oldie)

I have a theory that many Youngies don't want to supervise Oldies and may not be comfortable interviewing them. But you have this intriguing cover letter from an Oldie that has a decent resume. Remember that your job is to hire smart people with a zest to learn and a drive for excellence. Bring that Oldie in.

I have a confession to make. I’m an Oldie that is is prejudiced against Oldies. That’s because, for a decade, I crisscrossed the country delivering Java seminars to mainframers and I’ve worked in dozens of companies staffed with Oldies. Many of these folks have let their technical skills atrophy. Their worth to the companies they work for is in their knowledge of the company’s systems more so than their programming skills. But it takes just a moment to discover if an Oldie is in top form. Start the interview by asking them the following:

• What they've learned lately and what technologies they think are hot
• What are their strategies for continuous learning
• What have they failed at a what they learned from those failures

The Oldies’ answers to those questions will quickly let you know if the applicant has a bright young mind. You may discover that they are a life-long learner with a drive for success and potentially a big asset to your team.

I’ve found a disturbing number of Youngies brag about cool technologies they used on failing projects (they leave the failing part out.) Personally, I’m getting tired of re-engineering applications to refactor the use of NoSQL back into Postgres or MySQL and consolidating Microservice architectures from a dozen to one or two applications. If an interviewee states that they are using hot technologies (like NoSQL or Microservices) ask them why they were picked and how well they worked out.

An interviewing technique I’ve used for years is that I try to learn something from the candidate. I don’t ask canned questions. If I can’t learn something new from a candidate, there’s something wrong. Everyone should bring a fresh perspective to the team. I keep switching topics (such as languages, frameworks, and design patterns) until I start learning. Case in point: A year ago I was interviewing a lady for a position that would have entailed either Ruby and Rails or Python and Django development. This gal had mostly .Net and PHP experience but no Ruby or Python. I asked her about the .Net applications before honing in on PHP. The last time I worked with PHP, it was mostly with version 4 and version 5 was just released. So, in the interview, I bled from her knowledge on new PHP semantics and advantages and issues with upgrading. I learned a lot so I voted thumbs up.

Oldies (On Being Interviewed by a Youngie)

I started the Youngie section with my theory about their reticence to interview (much less hire) Oldies. I also have a theory about Oldies. I think many of us Oldies don’t know how to present ourselves in an interview.

First, it may have been a decade since you were last interviewed. At that point you very well may been offered that job because you yourself were young and fresh out of university. But you’ve now been working for years. You know you are good. You know your experience would be an asset to the hiring company. Leave your arrogance related to your decades of experience at the door. Instead show confidence in what you want to accomplish. Show confidence in your development approaches, excitement about your more recently acquired technical knowledge, and your adaptability. Help them understand why you believe you will be successful at their company. When I’m being interviewed, I like tell the interviewer that I’m excited to learn the technologies for which they advertised but I might not have much experience with. It’s important that they see your drive to adapt and learn.

A word of caution: don’t take control of the interview. Us Oldies are comfortable taking control of a room full of people much less a one-on-one interview. It is a very powerful skill and asset. But they are the manager, let them control the interview. If you take control, it suggests to the Youngie that you want their job and will otherwise usurp their authority.

You may be asked some of the many canned computer science questions often asked in interviews. Most are on techniques you (or the interviewer) will probably never use. Quick story: I do not have a Computer Science degree. Yet I was a Systems Programmer for 5 years at the company that wrote the first non-IBM C compiler available for the AS/400. One of my first tasks was to write a performance tuner for the AS/400. That tool required some complex statistical analysis algorithms. I asked each of the company’s half-dozen developers with comp/sci master's degrees details on the algorithms. None remembered details but all responded by handing me a book. That’s the thing, you need to be able to find the right algorithm and then have the ability to implement it rather than having rote memory of the implementation. I code that product in low-level C using sorts, linked-lists, data structures, and otherwise lots of complex code. That performance tool (ASNA’s Activ8) made millions of dollars. But today I’d have issues giving rote answers to Comp/Sci interview questions given by Youngies that probably never used those techniques.

Regardless, you may be asked Comp/Sci questions. To prepare for them, I suggest you read "The Imposter’s Handbook" by Rob Connery. Rob says of his book: "Don’t have a CS degree? Neither do I! That’s why I wrote this book: to fill the gaps in my career. The result? 700+ pages of essentials skills and ideas every developer should know."

One last point about interviews. If you haven’t been interviewed lately, practice. Get a tech friend (preferably a Youngie) to interview you.

The Coding Test

Oldies

Your cover letter and resume got you into an interview. The interview went well but, look out, know that there may be a coding test. I hate the prospect of a coding test. I resent it. After all, I’ve been at this coding thing for over 30 years. If you figure I averaged at least 50K a year, I’ve made over 1.5 million dollars coding. And this Youngie wants to test me? Step back. Think about it. They need someone that can code, not just someone that interviews well and might have just been good at keeping applications running. Hiring the wrong person is extremely expensive. Understand that Youngies being interviewed will be asked to do the same tests. Do the same due diligence as those other candidates. Actually, you might have to step it up a bit as Youngies have more recent experience with timed coding tests. Here are two common testing strategies:

• In-Interview coding with an editor or on a white board
• Audition or Take-Home project

If you are like me, you are a confident programmer but you get performance anxiety when you have to code while being watched by Youngies. To prepare for In-Interview coding, practise some timed tests. There are a number of sites that have various levels of coding tests including:

• EXERCISM
• CodeKata
• Codility for Programmers
• HackerRank

Also, keep in mind that In-Interview coding is not like a college test, it’s coding with others. Request feedback, ask questions and keep it conversational and say what you are thinking. "Phone a friend" and ask Google. Essentially, use the same techniques most developers use on a daily basis to get things done.

An Audition project will be an real world task that the hiring company actually needs to be done. Often you will be compensated for the time you spend on this coding task. A Take-Home project, on the other hand, is a contrived project for which you typically are not paid. One thing I dislike about the Take-Home project is that I’ve most often been fully employed while looking for work so I resent the time I must spend on a task for which I might not get an offer. I also fret over how much time I should spend on it.

But, if you put the Take-Home task in your Github as a public project, you’ll want to go the extra nine yards as other hiring companies may look at it. Be honest with how much time it took. And make modifications after you get a review. If you don’t get a feedback on your implementation, insist on it. You took the time to write that code so they should explain what you did well and what did not pass their snuff.

When you do an Audition or Take Home project, be sure to run it through a lint tool. You don’t want good code to be passed over because it didn’t follow commonly followed formatting (which some reviews may see as sloppiness.)

Youngies

Please inform Oldies that the coding part of the interview should be collaborative. Explain to them that it’s more important to see how they think and their approach to coding. Consider an Audition project and pay them for it. Jeff Atwood said in How to Hire a Programmer:

"If you want to determine beyond the shadow of a doubt if someone's going to be a great hire, give them an audition project. I'm not talking about a generic, abstract programming problem, I'm talking about a real world, honest-to-God unit of work that you need done right now today on your actual product. Something you would give to a current employee, if they weren't all busy, y'know, doing other stuff. This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement.

I’m not all that big on the benefits of reviewing candidates based on how well they code during an interview. I’d prefer a pair-review of candidates code. If they don’t have an open-source project, they probably have access to code they wrote. I also would suggest that you base hiring decisions more on answers to design questions than in-interview coding.

Hire and Be Hired Smart

Youngies, don’t miss out on the talent and experience of Oldies. Look at their careers from their perspective and improve your team by bringing on a sage developer that is a lifelong learner with a drive for excellence.

Oldies, write your cover letter and interview with a youthful mind. Focus on your future career and not your past. Talk about, not what you did, but what you want to do. Show your exuberance to work with Youngies that challenge you. Do your due diligence and prepare for the various styles of interviews.

About the Author

Don Denoncourt is a developer for simplethread.com. He has been coding since before Windows and Linux, much less the Internet. In the early nineties, Don moved from RPG and Cobol to C and C++. He adopted Java before it was real: 1996. After coding his way through the proliferation of Java frameworks (including Struts, Spring, and EJB) Don pined for the Convention-over-Configuration framework of Ruby and Rails. Don did Groovy and Grails before finally moving to Rails in 2011. Don enjoys writing and has published a couple of books and hundreds of technical articles. Don has been working from home since last century. When Don is not working, he loves spending time with his 3 grandchildren. To keep his mind young, Don reads and listens to novels in Italian. And, to keep his body young, Don is an avid off-road and street unicyclist.