Age Discrimination in Software Development

Is there age discrimination in software development?

I think the answer has to be "yes". As an old hand, I can tell you it gets harder to find each next job. Now, I don't think (most) managers look at a candidate and say, "Forget that guy, he's too old." It's more subtle than that. I'm not sure hiring managers are even aware that they're doing it. But man, it's out there.

To start out, let me say that I don't believe the world owes every old hand a living even if they haven't kept up to date with our fast-changing industry. If there is no longer much demand for Pascal programmers, well that's just the way the world is. But lets look at some facts.

• The great majority of practicing developers entered the field since 1995, when the software world began to really take off. That means that in 2012, the average developer has less than ten years' experience. These devs learned Java in school, and took their first jobs during the dot.com boom building web sites. Nothing wrong with that, except that the resumes of this cohort of devs all look pretty much the same. And they look different than the resumes of older devs who learned C in school and developed standalone windows apps. It is a truism that "we like to hire ourselves." The resumes of old hands just don't look like the resumes of younger devs doing the hiring.

• The current trend in interview techniques is a coding interview. Coding tests have to be short, artificial problems. They are in this way exactly like Computer Science homework problems. Coding tests emphasize book learning and mathematical aptitude over experience and intuition. Such interview techniques reward the recent graduate, and gratify the egos of new hires with insufficient experience to program intuitively. Old hands bring many skills to the job; design experience needed to distinguish true requirements from marketing obsessions, coding experience needed to estimate schedules, process experience needed to improve practice, interpersonal experience that brings awareness of destructive team and management behaviors, and a degree of maturity about the work environment. These skills are hard to recognize if you don't possess them. I find interviewers rarely ask questions about these skills.

• An experienced developer costs about twice what a new hire costs on an hourly basis. Good senior developers totally earn that pay through higher productivity and avoiding rookie mistakes. If the manager is not an experienced coder, they may not recognize that a senior person can really be that much more productive.

• Fast-growing employers with positions to fill typically have young teams, obsessed with the desires of the young. Indeed, the first time I began to think of myself as old was when I signed onto a startup during the dot-com boom. I was surrounded by twenty-somethings that all seemed to desire the same three things; to get rich, not by working hard over a lifetime, but by lucking into the right dot-com; to buy a big, fancy Lexus or Infinity car; which they believed they could employ to get sex with no commitment. I found these goals incomprehensibly naive. I just wasn't the same as they were. I interviewed with one company where everybody played in the same rock band. I might have done better at that interview had I played rhythm guitar. Silly me, I talked about programming. I had another interview with a hip young new-media company terminated after 45 minutes (and before any technical questions), presumably because I wasn't hip and young enough.

There's no fighting it. I just tailor my resume so it doesn't scream "Old Guy!" I have a web site and a blog and a Facebook page, because people search the web for your name, and if you aren't out there, you aren't hip. And I hope to get in for the interview before they figure out I'm an Old Hand. Then it's up to me.

A Taxonomy of Coding Interview Questions

As I noted previously, I think of myself as a talented developer, but I haven't done well at coding tests at recent job interviews. My ego demands I believe that doing well in coding interviews is a learnable skill. I have set out to master it.

I'm actually developing a methodology for passing coding interviews. The first step, as in all sciences, is taxonomy. Philosophers of old sought (magical) power over a problem by saying it's true name. Today we break the problem down into classes that share common properties we can exploit. To this end, I have encountered the following types of coding tests.

• Basic Skills Test: These questions are meant to test your familiarity with the basics of programming. Common problems in this class include reversing a string, tokenizing a string, and the recently popular fizzbuzz. I can't count the number of times I've coded atoi() or strtok() over 30 years of interviews.
  
  Unless you're a poser, these tests are supposed to be easy. The trick for senior devs is not to feel insulted that you are being asked to solve such a simple problem. When I was younger and less humble, I would bring a printed copy of atoi() with me to prove how smart I was. Nobody was impressed. They just asked a different question.
  
  I understand the need to test a candidate's ability to do basic coding. I might be a poser who cannot write any code at all. It's shocking but true that there exist people who make a living by fabricating resumes, then briefly take high-paying jobs as engineers, until somebody figures out they are frauds. However, when I get five basic-skills questions in a row at an interview, it definitely lowers my opinion of a prospective employer. Such an employer is looking for a code monkey, not a senior software engineer, or they'd ask some design or methodology questions.

• Data Structures Test: These questions are designed to gauge the depth of your familiarity with well-known data structures. Code I've been asked to write recently includes inorder binary tree traversal (recursive and iterative), heap insert, and breadth-first tree traversal. A lot of non-coding questions also test how comprehensive your data structure knowledge is.
  
  Most data structure questions are not too hard if, indeed, you went to college and paid attention in Algorithms & Data Structures class. These questions pose a problem for the self-taught, no matter how gifted they are on workaday coding tasks.
  
  If you're applying for a senior position, the questions will be more challenging, and may involve obscure data structure tricks. Maybe these trick questions are supposed to be lateral-thinking tests; the coding test descendents of those "Why are manhole covers round?" tests for which Microsoft was once famous. My experience is if you don't know the trick, you will be frustrated and out of time before the interviewer offers a key hint.
  
  For instance, heap insert is simple enough to code, if you happen to know the trick of implementing the heap in an array so that there are formulas to compute the index of the parent and children of any node. You may have seen heap insert described briefly, using a tree diagram to show the state of the heap. This memory takes you down the wrong path. Try to work it out from first principles using the heap property and a linked tree-node data structure with no parent link (like I did, ouch), and you're toast; it's too hard to do in one interview session.
  
  Another question I was asked recently was “find the inorder successor of a node iteratively”, which can be coded in a few minutes if nodes have an extra link to the parent node. For senior developers, the more comfortable you are with tree data structures, the less likely it is that you will consider this unusual extra pointer.
  

• Algorithm Test: The basic questions in this category include all manner of “iterate over an array where the entries have global property X” questions.
  
  The algorithm test is the most challenging class of questions for me, because these problems require the most concentration, and some original thought, not just recall. Standing at the whiteboard, solving an unfamiliar problem, trying to talk about what I'm thinking, while the interviewer watches the clock, is not my preferred way to concentrate.
  
  In applying for senior positions, I have been given problems of significant complexity; finding the longest palindrome, two-dimensional divide and conquer, dynamic programming chores that look like they should have a simple inductive recurrence relation but don't. indeed, I have been asked questions so difficult that the interviewer did not actually understand the problem or its solution, and offered incorrect hints. I gotta say, they could as well have not wasted their time and mine by inviting me to such an interview. It's outrageous.
  

Is Something Wrong With Coding Tests?

I'm looking for work as a senior software developer these days, so I'm doing a lot of coding interviews. I am uncomfortable with coding interviews. They're stressful; get the optimal answer, quickly, to a problem often selected to be difficult or unfamiliar. They're adversarial; you are a poser unless you prove yourself worthy. They're artificial; produce correct code, but on a whiteboard, from top to bottom, without being able to go back and add a few lines, in less than 20 minutes.

But what makes me most uncomfortable about coding interviews is that I don't see a connection to a developer's day-to-day practice. I have to develop an unfamiliar algorithm only a couple of times a year. I implement a standard data structure almost never (with the exception of linked lists). My day-to-day practice consists of decomposing hard problems into many generally-easy-to-code steps. In fact, the coding chores I perform are usually so familiar to my mind that I do them by reflex, spending most of my attention on how the piece I'm writing nibbles away at a big, hard problem. When I come to a tough bit of coding, I slow down, analyze the heck out of it, test it, and make a deliberate end of it. Concentrating on the code is a distraction that keeps me from concentrating on the problem I'm solving.

But coding tests aren't big. You can't nibble at them. They're all hard part, compressed, like evil haiku. You can't work deliberately; there's an interviewer behind you with a stopwatch. Coding tests are in fact just like CS homework assignments, where you must solve a riddle on paper and then write 10 lines of code. They reward the new grad, who has recent practice with homework problems, and no reflexes for coding. They play to the vanity of the recent hire, very impressed with their own training; unaware of how much they don't know.

When you apply for a senior position, interviewers ramp up the difficulty of the coding challenges. Instead of problems from an undergrad data structures class, they pose supposedly unfamiliar problems. These problems generally have a simple, inefficient solution, and perhaps one or more faster solutions that involve dynamic programming. The bar is higher for senior applicants than for new grads. This would be sensible if solving this kind of problem was something we all did every day so that experience made us better at it. The fact that we don't do CS homework problems in the working world makes this kind of interview a subtle form of age discrimination.

I think of myself as a talented developer, but I haven't shown well on coding tests. That makes me wonder. Are there senior applicants who do really well at coding tests? When companies hire these applicants, do they demolish deadlines and eat hard problems for breakfast, leaving a trail of shredded feature story cards? Or is passing the coding test a mental trick? I've met one guy in my career (hi ~toma) who was a lightning-fast coder. He produced five times as many lines of code as any other member of our ten-person team, and the code he produced was reasonable, if not special. Other than that, I've worked with folks who wrote bad code quickly, folks who wrote decent code at a deliberate pace, and a small number of complete morons. Why haven't I met more devs who could solve any problem brilliantly in 20 minutes?

Can I study for coding tests? Can I acquire skills that make me more capable of solving such puzzles? (The answer is yes). 

An even more interesting question is this. If I learn to be good at coding tests, will I become faster than a speeding bullet? Will it inform my day-to-day practice of programming? Stay tuned.

Starting Salaries: Red Hot. Old-Hands Salaries: Not So Much

Ed Lazowska, CS Professor at the University of Washington, claims starting salaries for new CS grads are red hot. In another recent article, the Wall Street Journal claims starting salaries are so high that startups can't compete. The claims are that top new grads are getting offers over $100k plus signing bonuses from very profitable social networking companies.

Even if this is only half true, and starting salaries are really "way down" in the $80k range, it means something disturbing. It means that the salary premium for experience, which stood at about 2.5x starting salaries when I started working, is continuing to drop. It has reached about 1.5x in 2011 if these sources can be believed. In this way, programming is becomming like nursing; great pay fresh out of college, but not much headroom. Ten years on, there doesn't seem to be much reward for staying in the field.

Interestingly, both software development and nursing are claimed by employers to have a serious shortage of experienced workers.

Another thing that might be happening is that the industry is stratifying into hot, high-paying jobs that demand insane hours from superstar developers, and a long tail offering rather less spectacular wages for geeks without super-powers, and finally an army of code monkeys churning out add/change/delete screens and login pages for third-world wages, often in third world countries.

Part of the problem is certainly that a great many people entered software development in the late '90's. These people are only arriving at the 10-year level of experience now, and cannot perceive the additional skills old hands possess, because inexperienced people don't have these skills. Part is that APIs and hot programming languages change so fast that 10-year-old skills are no longer in fashion, and not every senior developer bothers to keep up-to-date.

None of this is good news for anyone interested in a career in Computer Science. Employers wonder why they can't find enough experienced people. They wonder why people with a choice tend to leave the field. Maybe there's a reason. Duh!

Welcome to the Old Hands Blog

My name is Kurt Guntheroth. I have been a software engineer since, well, lets just say that clock rates were lower back then. You could count the pins on your processor. You could hear the individual bits go out on the modem. If you wanted a PC, you soldered it together. I am what you might call an Old Hand.

For years I've been thinking what I'd write if I wrote a book about software development. I know a little something about programming, about the process of developing code, about managing geeky people, about being a member of a development team, and about being an employee of a for-profit corporation. I wrote a couple of articles in print journals, but then the internet killed print (RIP C++ Users Journal, Dr Dobbs, and the rest). I've been a commenter on other people's blogs. Now it's my turn.

An Old Hand helps the new guys "learn the ropes". Anyone know what that expression means any more? It comes from the days of wooden sailing ships, when the running rigging came down in a complex but well-ordered profusion of identical-looking ropes, and your mates depended on you to know which lines were tacks and which were sheets, and so forth. Guys found themselves on a ship at sea sometimes because they drank too much at the wrong bar. The old hands taught them which ropes were which, so nobody got killed.

I have no pretension to have things of universal value to say. I will write things down that seem to me to be useful to know but not frequently heard. The cool thing about the web is that it knows what is useful. If my voice appears in that list, then I'm successful.

I'm not a high-powered over-achiever, microsoft millionaire, or IBM vice president. I'm a working engineer. I like building beautiful things that nobody else can see. Good thing too, 'cause that's what it means to be a software developer most of the time.

I'm new to social media. When my wife, who is also an Old Hand, hears I have a blog, she'll probably faint dead away. I'm not sure I'll mention it to her. I once argued that social media was all self-promotion. Then someone patiently explained to me why that wasn't (necessarily) true. It's something the new guys have to teach us Old Hands.

Thanks for listening.