Report: Ageism in the Tech Industry(blog.indeed.com)
blog.indeed.com
Report: Ageism in the Tech Industry
http://blog.indeed.com/2017/10/19/tech-ageism-report/
87 comments
> This is one of the many pernicious effects of the Standard Developer Interview™. Despite the fact that older developers may have years of proven experience at other companies, pretty much every interview goes in assuming the interviewee is no better qualified than a random person picked off of the street.
Many people who interview feel like random people off the street. You really can't tell if the resume's completely bullshit until you ask them to sit down and implement fizz-buzz.
> Focusing so heavily on computer science trivia questions favor those who recently went to college, since those tidbits are so rarely needed at the drop of a hat in industry those neurons wither away with more time away from academia. Older developers know you can just look it up.
Is this still a common practice? Neither Facebook, Google, nor Amazon trains its interviewers to ask bullshit trivia questions to non-intern candidates (I don't know if they train them to ask, or not ask those questions to intern candidates.) I mean, it's entirely possible that particular interviewers at those companies do, but I have skimmed through many, many interview transcripts. None of them focused on bullshit trivia.
(Unless you feel that 'Is it possible to have a memory leak in a language like Java or C#?' is bullshit trivia. I've had people who have spent five years programming in those languages answer, with full conviction, 'No'. After some more prodding, they sometimes say yes, if there was a bug in the garbage collector.)
At this point, this feels like a meme that has been ten years out of date (Because all it takes is one person having a bad interview experience to revive it.)
Many people who interview feel like random people off the street. You really can't tell if the resume's completely bullshit until you ask them to sit down and implement fizz-buzz.
> Focusing so heavily on computer science trivia questions favor those who recently went to college, since those tidbits are so rarely needed at the drop of a hat in industry those neurons wither away with more time away from academia. Older developers know you can just look it up.
Is this still a common practice? Neither Facebook, Google, nor Amazon trains its interviewers to ask bullshit trivia questions to non-intern candidates (I don't know if they train them to ask, or not ask those questions to intern candidates.) I mean, it's entirely possible that particular interviewers at those companies do, but I have skimmed through many, many interview transcripts. None of them focused on bullshit trivia.
(Unless you feel that 'Is it possible to have a memory leak in a language like Java or C#?' is bullshit trivia. I've had people who have spent five years programming in those languages answer, with full conviction, 'No'. After some more prodding, they sometimes say yes, if there was a bug in the garbage collector.)
At this point, this feels like a meme that has been ten years out of date (Because all it takes is one person having a bad interview experience to revive it.)
It’s not a meme. I just interviewed at FB (3 onsites) and the one interview that sunk me was a CS-algo question. I’ve never had to do that my entire career and I even though I got the answer in the end, I was told afterwards that my answer was too slow. The other tech interviews focused on real web dev experience I destroyed. Still got rejected even though I answered every question correctly, just not fast (or optimal?) enough. The recruiter said I was a “great culture fit” afterwards so that wasn’t the issue. You wouldn’t consider the question “trivia” because it was something you might do once or twice in an entire web dev career. But it’s still a question that will favor new grads who have been trained to pattern match algos and share questions amongst each other.
So even if there’s not explicit bias against older devs there is implicit bias by favoring quick whiteboard speed (memorization/practice) over the practiced thoughtfulness of older devs. And a one-off interview focused heavily on algos can sink anyone. It only takes one.
This isn’t limited to FB. The $Elite companies I got offers from are the ones where I lucked through that one tricky interview by knowing it offhand.
I worry as I get older, even as I become a stronger developer, I will become less and less able to marathon through these interviews. No wonder so many older devs switch to management.
So even if there’s not explicit bias against older devs there is implicit bias by favoring quick whiteboard speed (memorization/practice) over the practiced thoughtfulness of older devs. And a one-off interview focused heavily on algos can sink anyone. It only takes one.
This isn’t limited to FB. The $Elite companies I got offers from are the ones where I lucked through that one tricky interview by knowing it offhand.
I worry as I get older, even as I become a stronger developer, I will become less and less able to marathon through these interviews. No wonder so many older devs switch to management.
I have no issue with the DS/A questions myself, but their use use and arbitrary nature of acceptance as right or wrong coupled with the ability of the interviewer's own bias to take it in whichever direction they desire is full of land mines. And I had never thought of ease with which the process could be undermined even if it where to be improved.
There's a world of difference between remember some bullshit trivia about how to do fast matrix multiplication, that requires some esoteric algorithmic or mathematical trick, and 'implement a data structure that does X'.
Yet, when blasting interviews, I have found that people tend to conflate the two.
I agree that 60 minutes on a whiteboard or a laptop is not the best way to ask someone to solve a coding problem. Homework is worse, though. Maybe 90 minutes is a better time slot.
Yet, when blasting interviews, I have found that people tend to conflate the two.
I agree that 60 minutes on a whiteboard or a laptop is not the best way to ask someone to solve a coding problem. Homework is worse, though. Maybe 90 minutes is a better time slot.
There’s a middle ground between those two which usually ends up being the one tricky question—there’s only one right answer and the task is something non-straightforward. I find junior devs to be far more likely to ask this type of question.
How is homework worse? Homework simulates an actual job assignment. There's no better way to gauge a candidate's ability. You still couple with onsite after, of course.
It's an asymmetrical waste of time. The company invests nothing into it, the candidate invests 8-16 hours into it. This creates incentive to interview too many people, causing candidates to have to interview at too many places, wasting even more of their time.
At least in-person, both parties invest about as much time into the interview.
At least in-person, both parties invest about as much time into the interview.
I interviewed somewhere recently, it went well, we talked about current technology, talked about the projects I'm working on now, and then they sent me an email asking me to do a project that would take me two days. I have a two year old and a job I'm perfectly happy with right now, I'm not going to spend my precious weekend hours writing code for free (unless maybe it was open source or something like that).
Are y'all trying to say that an 8-16 hour homework assignment is too much to bear for a new job? You're happy in your current job...great. But 8 hours for a $10-$30K salary bump? I mean, worth it from a pure monetary standpoint, even if it takes several attempts to attain one of those jobs.
The article is about age discrimination and my comment pointed out that older developers may value their “off time” more, which biases take home tests against those older devs.
Valuing your off time is great when you've got a steady job that you're happy with. If you're looking for a new job, because you're unemployed or because you're unhappy with your current job, you have to invest your off time into that. Just like, in college I had to invest my off time into studying so I could get good grades...Older folks that have kids and stuff may have less off time, sure, but that's the way things go.
So you’re admitting that older people are disadvantaged by these types of assignments that are not actually selective for coding capability, but throwing up your hands and saying that’s just the way life is?
Yeah, I mean, folks with kids are at a professional disadvantage to folks without kids...that's pretty well established. Kids bring all sorts of other great benefits to life. But extra time is not one of them. And folks who choose to spend their off time doing other activities rather than leveling up their skills or applying to better jobs are going to remain that way.
I've found that companies that are serious about this will offer some form of compensation (gift card, etc)
They shouldn't have to compensate you for a trivial exercise to prove your ability. This isn't production-code type of problem, these are usually toy problems just designed to show you can code and you care about quality.
Something that takes more than a couple hours is no longer trivial.
Once, after submitting take home assignment, my application was rejected because the project didn't comply exactly with their requirements. The project they paid for exactly zero. That was truly infuriating experience.
I've done it in the past where there's a prescreen phone interview, a homework assignment, then a non-coding exercise interview and it works pretty well.
Ignore it at your own peril. I've hit it head to the point of self testing its existence. I was floored by the situations, comments and outright unprofessional treatment I've received while interviewing with the top companies, Amazon and Apple among them. And they are not alone. Smaller companies can be much worse.
Not that I disagree with all of your points, but I can't say I've seen any evidence that there is such a thing as Standard Developer Interview™. Over the past month, I've been interviewing with 8 different companies, 3 of which are in the game development industry. They have all had substantially different approaches to their recruitment process and interviewing.
I've identified some common elements, but each of the companies mixed and matched them in different ways and degrees. The techniques used were:
- timed online test (e.g. HackerRank or Codility), reviewed later by the team
- online, real-time coding during the phone screen (e.g. HackerRank or CollabEdit)
- take-home project with a deadline (usually up to 2 weeks), reviewed later by the team
- phone, video-conference or on-site discussion about employment history and experience
- phone, video-conference or on-site discussion about technical problems
- on-site whiteboard coding
- on-site coding on company-provided box
- on-site coding on candidate's own box
- coffee-shop conversation about behavioral topics
The topics for technical discussions were:
- algorithms, data structures and complexity (big-O notation, trees, hash tables, lists, circular buffers, breadth-first and depth-first traversal, binary search, recursion)
- scalability (caching, load-balancing, sharding)
- concurrency (locks, conditional variables, contention, memory fences)
- mathematics (vectors and matrices, linear algebra, computational geometry, combinatorics and probability)
- low-level concepts (manual memory management, cache locality, specifics of garbage collection, VMTs in C++)
- object-oriented design (inheritance, polymorphism, fragile base class, composition over inheritance)
- API design (specifying constraints, changing API based on requirement changes, paging results, increasing or decreasing operation granularity)
Now, I know that this is just 8 companies. I know that this is a drop in the ocean. I know that the plural of "anecdote" is not "data". But over and over again, I've seen the same claim on HN: our industry focuses too much on computer science "trivia" questions. For an audience that usually requires quality, sourced data to support arguments, we seem to be awfully quick to draw generalized conclusions about this specific topic.
I've identified some common elements, but each of the companies mixed and matched them in different ways and degrees. The techniques used were:
- timed online test (e.g. HackerRank or Codility), reviewed later by the team
- online, real-time coding during the phone screen (e.g. HackerRank or CollabEdit)
- take-home project with a deadline (usually up to 2 weeks), reviewed later by the team
- phone, video-conference or on-site discussion about employment history and experience
- phone, video-conference or on-site discussion about technical problems
- on-site whiteboard coding
- on-site coding on company-provided box
- on-site coding on candidate's own box
- coffee-shop conversation about behavioral topics
The topics for technical discussions were:
- algorithms, data structures and complexity (big-O notation, trees, hash tables, lists, circular buffers, breadth-first and depth-first traversal, binary search, recursion)
- scalability (caching, load-balancing, sharding)
- concurrency (locks, conditional variables, contention, memory fences)
- mathematics (vectors and matrices, linear algebra, computational geometry, combinatorics and probability)
- low-level concepts (manual memory management, cache locality, specifics of garbage collection, VMTs in C++)
- object-oriented design (inheritance, polymorphism, fragile base class, composition over inheritance)
- API design (specifying constraints, changing API based on requirement changes, paging results, increasing or decreasing operation granularity)
Now, I know that this is just 8 companies. I know that this is a drop in the ocean. I know that the plural of "anecdote" is not "data". But over and over again, I've seen the same claim on HN: our industry focuses too much on computer science "trivia" questions. For an audience that usually requires quality, sourced data to support arguments, we seem to be awfully quick to draw generalized conclusions about this specific topic.
My proven experience only counts if you trust the people I proved it to. If my references are your drinking buddies, sure, you can probably skip the interview, but when it's a stranger I could have coached an actor for all you know.
What is the end game in this hypothetical fraud situation?
- Fraudster gets hired and cannot do the job. They get let go.
- Fraudster gets hired and can do the job. No harm.
- Fraudster gets hired and can kind of do the job. They get placed on a performance improvement plan, and you train them until they either can or cannot do the job.
Think of this from the perspective of both parties. I think the risk of this type of bad actor is wildly overstated.
- Fraudster gets hired and cannot do the job. They get let go.
- Fraudster gets hired and can do the job. No harm.
- Fraudster gets hired and can kind of do the job. They get placed on a performance improvement plan, and you train them until they either can or cannot do the job.
Think of this from the perspective of both parties. I think the risk of this type of bad actor is wildly overstated.
In scenario 1, fraudster is also getting paid, ties up members of your team attempting to train them, and your timeline of getting an actual hire is pushed out until the company figures out they messed up. Seems worth the effort to prevent.
Some effort? Sure. Raking prospects over coals in discriminatory interviews that don’t actually test for coding ability? Nah. Bad hires are bad, not disastrous and the response in the industry is wildly out of proportion.
-Fraudster gets hired and starts committing code. There is some disagreement as to whether the fraudster is a fraudster or not, but the non-technical boss sure loves him and they often go to lunch together. More code committed. Then he starts making major design decisions.
Sounds to me like an issue with the boss, not the hire alone. Why torture applicants?
Good candidates don't think of writing code as torture. Talking about code is a necessity but not the best demonstration of skill.
I never said that writing code is torture. CS trivia, whiteboard coding, unpaid homework assignments, and "hacker" online tests all have nothing to do with the job itself. Talking about code is the best way to demonstrate skill in a limited amount of time, such as an interview. I gain much more information about a person talking with them about development than I would through any of the above methods.
From my experience working with web businesses age is irrelevant to hiring, but it strongly influences office culture. As a side note I am a front-end developer which tends to skew extremely young, but I have been doing it for 20 years. I don't consider myself either a baby-boomer or a millennial.
In offices of extremely young teams without a lot of mentorship the big focus is on abstractions and frameworks. The primary technology is JavaScript. I get the feeling of people wanting to move really fast and build cool things, but with huge limitations around their understanding of the technology.
In offices of much older developers the focus is more heavily directed towards code design and architecture. Contrasting to the previous group the older folks feel more confident they can build just about anything and don't mind jumping into the technologies directly, however their focus tends to be more narrow as though there are a set fixed few ways of doing things. This group generally tends to treat web technologies with an utter disregard and prefers to isolate themselves in Java.
Actual fullstack people are rare to either demographic but tend to have a wider understanding of how things work outside their comfort zone.
In offices of extremely young teams without a lot of mentorship the big focus is on abstractions and frameworks. The primary technology is JavaScript. I get the feeling of people wanting to move really fast and build cool things, but with huge limitations around their understanding of the technology.
In offices of much older developers the focus is more heavily directed towards code design and architecture. Contrasting to the previous group the older folks feel more confident they can build just about anything and don't mind jumping into the technologies directly, however their focus tends to be more narrow as though there are a set fixed few ways of doing things. This group generally tends to treat web technologies with an utter disregard and prefers to isolate themselves in Java.
Actual fullstack people are rare to either demographic but tend to have a wider understanding of how things work outside their comfort zone.
I agree, what I see in the midwest is that experienced, senior developers are in hot demand. The only companies that skew young are the Big Dumb Corps with horrible cultures (overtime, low pay, atrocious legacy code). There are a lot of second or third tier universities graduating cs (or whatever) majors who don't go to silicon valley. One company here, in particular, vacuums these people up. Senior developers won't put up with that. Me and a lot of my peers have done stints there, and consider ever going back to be a last resort. Hence this particular company pays outlandish prices for contractors, even flying people in from out of state, weekly.
Is it Epic Systems? It sounds like Epic Systems.
I did a stint there, and going back isn't even a last resort. I'd rather move to Elbonia and sell stolen credit card numbers.
I did a stint there, and going back isn't even a last resort. I'd rather move to Elbonia and sell stolen credit card numbers.
Close, cerner.
I imagine GEMS and McKesson and Eclipsys and Meditech and Siemens are all so similar that you need to look at your employee ID to remember who you're working for.
Let this be a lesson for all those looking to disrupt a big, heavily entrenched industry with lots of loose money sloshing around in it.
But be warned: it's more difficult than it looks.
Let this be a lesson for all those looking to disrupt a big, heavily entrenched industry with lots of loose money sloshing around in it.
But be warned: it's more difficult than it looks.
> This group generally tends to treat web technologies with an utter disregard and prefers to isolate themselves in Java.
I hear you. I dislike Javascript too (though not as intensely as some folks), but if it's the language of the platform you're targeting (web browsers), just suck it up and use it.
I was once forced to use GWT by a mindless engineering manager who thought standardizing all development on a single language would somehow reduce maintenance costs. It definitely did not :(
I hear you. I dislike Javascript too (though not as intensely as some folks), but if it's the language of the platform you're targeting (web browsers), just suck it up and use it.
I was once forced to use GWT by a mindless engineering manager who thought standardizing all development on a single language would somehow reduce maintenance costs. It definitely did not :(
Yeah, my personal thoughts on this are somewhat similar. As a JavaScript developer I prefer to do what I can in JavaScript as compared to Java, but that doesn't make Java bad. Java is actually better as a web middle tier for managing sessions and all the other OWASP goodness precisely because it is a completely separate technology. But at the same time if the end product is something that appears in a web browser you have to concede to some mastery of those skills for the sake of product quality. Putting everything into Java (or JavaScript) for the sake of comfort is so very bad.
> In fact, 29% of our survey respondents say the average employee age at their company is between 31 and 35. Millennials, yes—albeit at the older end of that demographic. A further 17% say that their company’s average is between 20 and 30.
> By contrast, 3 in 10 (27%) respondents say that the average age of employees at their company is 36-40 years old, making them members of the younger end of Generation X. The over 40s (Gen X and Boomers alike) have to share the remaining 26%.
That's 56% of tech employees between 31 and 40. Xennials FTW!
> By contrast, 3 in 10 (27%) respondents say that the average age of employees at their company is 36-40 years old, making them members of the younger end of Generation X. The over 40s (Gen X and Boomers alike) have to share the remaining 26%.
That's 56% of tech employees between 31 and 40. Xennials FTW!
I watched a talk by Bob Martin in which he claimed that the number software engineers in the world doubles every 5 years. For a huge majority of those new engineers, it's their first careers. Thus, almost half of the world's software engineers should be between the ages of 22-27. So, tech companies are dominated by the young not because they hate old people, but because there are so many young people with technical skills and that number is growing rapidly.
Doesn't he claim a lot of things? I mind me of his "unit tests and self-discipline are all you ever need" philosophy toward software reliability, as recently discussed here on HN.
I'd like to see his data on that. I find it difficult to believe that there are twice as many programmers now than there were in 2012. At least, not in the United States.
throwanem and jordanb: The growth rate numbers are from the US Bureau of Labor Statistics.
I am 45 years old, and work for a very large consultancy (I won't name them here, but you can figure it out if you're curious). I don't actually work as a consultant, but rather on a product.
One of the things I like about working here is that when I go to company events, like the internal conference that I'm at this week, I see people at all age levels. Plenty of young people, but also plenty of people my age or older. And the people older than me aren't coasting until retirement - they're mentoring, leading new initiatives, working on exciting projects. It gives me hope that I'll be able to work on interesting things until I'm ready to retire.
All this to say, there are plenty of companies that value age and experience, but you might have to look outside of the startup scene.
One of the things I like about working here is that when I go to company events, like the internal conference that I'm at this week, I see people at all age levels. Plenty of young people, but also plenty of people my age or older. And the people older than me aren't coasting until retirement - they're mentoring, leading new initiatives, working on exciting projects. It gives me hope that I'll be able to work on interesting things until I'm ready to retire.
All this to say, there are plenty of companies that value age and experience, but you might have to look outside of the startup scene.
Then come over to EU. Here not only one have to be young but as well cheap. 100k USD? Forget about it max we can do is 30-40k USD. Apart few exceptions in Germany haven't seen a developer above 40 years old, rarely have seen one above 35.
I always get skeptical when people discuss raw numbers instead of purchasing power. Even within US, 100k USD is not very meaningful unless you specify the state.
Come to Dublin. Where I work, we'd love to hire more experienced people. I'd say around 15% of my colleagues are >40, with 3 or 4 > 50.
I don't think it is at all unusual to get paid significantly more than €40k..
I don't think it is at all unusual to get paid significantly more than €40k..
> I don't think it is at all unusual to get paid significantly more than €40k..
It's neither in Germany. I have no idea where op gets their information. Sure, compared to the US pay in Germany is lower, but 40k is not even remotely on the high end for a developer.
It's neither in Germany. I have no idea where op gets their information. Sure, compared to the US pay in Germany is lower, but 40k is not even remotely on the high end for a developer.
I meant developing EU countries, in developed ones it's more like 60-80k USD, but only in those with healthy economies like DE, NL, IE, etc.
There is one major thing which turns me down about Ireland - I'd have to rent a place to live.
Why do you think that is? (both the depressed salaries and only younger devs)?
On a side note: make your way to SF. As a software engineer, you will feel like a king and there's a meetup for every niche topic you can think of..
On a side note: make your way to SF. As a software engineer, you will feel like a king and there's a meetup for every niche topic you can think of..
Developing countries (PL, CZ, RO) - dominance of low cost and outsourcing centers. Developed countries - software and internet are perceived as some quirks and working on them professionally as undemanding "sitting by the computer", in Germany they value obedience and compliance the most and perceive these professions as bricklaying even (tons and tons of brain numbing corporate Java projects).
That's perhaps in Poland, the Baltics and the former Soviet Block. France, Germany, Norway, etc will promptly put 100+K€ on the table for an experienced consultant in some niche.
Yeah, I don't get it.
I think it boils down to one thing: How enthusiastic an old engineer is about technology in general and whether they are proactive on keeping themselves up to date on the latest things (vs reactively learning something when a project requires it).
I worked at a startup for the last 4.5 years which had a lot of older (40-50 yr) people (the founders were in their late 40s). I also interviewed a lot of older people (both with positive and negative feedback). What I noticed is two clear groups:
One set of older devs have been in the tech industry just because they needed a job and have somehow kept up with the technologies in a reactive manner. This set of people have mentality of "this is how we used to do this back in 19xx/20xx". It doesn't always work out.
The other set of people are genuinely interested in technology and proactively seek new things, present papers, blog about stuff, and are always on the look out for the next improvement and the next thing. This set of people tend to learn from their own experiences and improve on things while providing guidance to devs in their 20s/early 30s. This set of people never have trouble finding jobs.
The bottom line is that the tech industry requires you to do continuous learning and be enthusiastic about stuff. If you can't do that you'll have trouble finding jobs when you're older.
Edit: I’m seeing the same pattern at my current job even though the percentage of older devs is lower here.
I worked at a startup for the last 4.5 years which had a lot of older (40-50 yr) people (the founders were in their late 40s). I also interviewed a lot of older people (both with positive and negative feedback). What I noticed is two clear groups:
One set of older devs have been in the tech industry just because they needed a job and have somehow kept up with the technologies in a reactive manner. This set of people have mentality of "this is how we used to do this back in 19xx/20xx". It doesn't always work out.
The other set of people are genuinely interested in technology and proactively seek new things, present papers, blog about stuff, and are always on the look out for the next improvement and the next thing. This set of people tend to learn from their own experiences and improve on things while providing guidance to devs in their 20s/early 30s. This set of people never have trouble finding jobs.
The bottom line is that the tech industry requires you to do continuous learning and be enthusiastic about stuff. If you can't do that you'll have trouble finding jobs when you're older.
Edit: I’m seeing the same pattern at my current job even though the percentage of older devs is lower here.
Who would you expect developers to be speakers and presenters? Those are two almost separate tracks - the people who speak at the conferences and present and the people who spend most of the time doing things. Knowing how to look cool and knowing what the audience like is entirely different skill then being senior developer. One requires social charisma, the other much less so. Some level of social skills is important at senior level (how to deal with juniors without being jerk, how to deal with customers etc), but that is still different social skill then presenting and speaking.
Majority of developers I know, regardless of age, don't like writing in general. Few do and it is great when they do, but most avoid it unless related to job - and it has nothing to do with love of technology.
I dont know why is are some people so obsessed about apparent feelings instead of skill and contributions (both technical and organizational). It is as if projecting various seemingly cool proxies for "passion" and "enthusiasm" was more important then being engineer that takes the job seriously.
Majority of developers I know, regardless of age, don't like writing in general. Few do and it is great when they do, but most avoid it unless related to job - and it has nothing to do with love of technology.
I dont know why is are some people so obsessed about apparent feelings instead of skill and contributions (both technical and organizational). It is as if projecting various seemingly cool proxies for "passion" and "enthusiasm" was more important then being engineer that takes the job seriously.
I think you and I are doing completely different types of software development or live in very different bubbles.
> Those are two almost separate tracks No they are not. If you come up with some innovation/improvement in your field you should present it to a broader audience. It's not like these seminars and meetups have non-technical audience. So you don't need Elon Musk level of charisma. It's just sharing knowledge.
> Majority of developers I know, regardless of age, don't like writing in general
Not true for me. Most good developers I know like to share their knowledge and opinions via different channels.
> Few do and it is great when they do
WTF! why is not documenting stuff acceptable where you work? what happens when the component needs updates/fixes long after the developer has left? At least document enough stuff so that somebody else can be brought up to speed quickly. Maintainability is a key requirement in modern software.
> skill and contributions
If you're doing the same thing your skill doesn't really improve much after 3-4 years. Most best practices are documented or are otherwise passed down from senior engineers to junior engineers. So it's not like somebody with 20 years experience will write better code than somebody with 5 years experience.
As an anecdotal evidence, I started out fresh out of college 8 years back, did J2EE and some frontend (pre-HTML5).. after 3 years I realized that I knew pretty much known everything about enterprise J2EE patterns and practices as any other person. So I moved into big data (hadoop, MR, etc.), learned stuff, mentored people, etc. Last year I realized that big data field is big enough with enough documentation and established practices that you can train a developer in 2 years to do what I was doing. So I moved into machine learning. I hope to ride this wave for the next 5-6 years until it becomes apparent that any college graduate can be trained to do my work with a couple of years of mentoring.
> Those are two almost separate tracks No they are not. If you come up with some innovation/improvement in your field you should present it to a broader audience. It's not like these seminars and meetups have non-technical audience. So you don't need Elon Musk level of charisma. It's just sharing knowledge.
> Majority of developers I know, regardless of age, don't like writing in general
Not true for me. Most good developers I know like to share their knowledge and opinions via different channels.
> Few do and it is great when they do
WTF! why is not documenting stuff acceptable where you work? what happens when the component needs updates/fixes long after the developer has left? At least document enough stuff so that somebody else can be brought up to speed quickly. Maintainability is a key requirement in modern software.
> skill and contributions
If you're doing the same thing your skill doesn't really improve much after 3-4 years. Most best practices are documented or are otherwise passed down from senior engineers to junior engineers. So it's not like somebody with 20 years experience will write better code than somebody with 5 years experience.
As an anecdotal evidence, I started out fresh out of college 8 years back, did J2EE and some frontend (pre-HTML5).. after 3 years I realized that I knew pretty much known everything about enterprise J2EE patterns and practices as any other person. So I moved into big data (hadoop, MR, etc.), learned stuff, mentored people, etc. Last year I realized that big data field is big enough with enough documentation and established practices that you can train a developer in 2 years to do what I was doing. So I moved into machine learning. I hope to ride this wave for the next 5-6 years until it becomes apparent that any college graduate can be trained to do my work with a couple of years of mentoring.
> Not true for me. Most good developers I know like to share their knowledge and opinions via different channels.
You measure extroversion there. Good introverted developers exist too - in fact developers be more introverted then general population (there are stats on that). So do very good shy or humble developers. While real developers are on average nowhere near the nerd stereotype with social anxiety, plenty good developers are a bit like that (They dont talk much unless they know you a bit).
> WTF! why is not documenting stuff acceptable where you work?
What does that have to do with blogging? I said they dont like writing. I did not said they don't write documentation or comments when needed. How did you managed to twist "not liking to write" in context of blogs to "maintainable software"?
For that matter, real documentation, the one that is targeted at users, is written by technical writers mostly. Developers job is to explain it to writer - it is mostly that docs are more then full time jobs and good technical writer are really better at explaining stuff.
>
How did you managed to twist "measure skills and contributions instead of projecting cool" to "doing the same thing dozens years"? Seriously.
The worst developer out there is is the one that does not do tasks that he does not like. You seem to treat it like the norm and assume that if someone does not visibly loudly jump up and down then he is going to slack it or something.
I don't think it is possible to know everything there is to know about application servers in three years. There are many positions that require neither breadth nor depth and that is fine. If you are in position to mentor people just a year after you entered the field, then the field is too easy and new. I mean, of course any good college graduate can do big data or artificial intelligence. Why would not they? They are best equipped to do math heavy things and they are already adults. Ability to confidently bullshit after 3 months of learning is not the only way how to be a good developer.
You measure extroversion there. Good introverted developers exist too - in fact developers be more introverted then general population (there are stats on that). So do very good shy or humble developers. While real developers are on average nowhere near the nerd stereotype with social anxiety, plenty good developers are a bit like that (They dont talk much unless they know you a bit).
> WTF! why is not documenting stuff acceptable where you work?
What does that have to do with blogging? I said they dont like writing. I did not said they don't write documentation or comments when needed. How did you managed to twist "not liking to write" in context of blogs to "maintainable software"?
For that matter, real documentation, the one that is targeted at users, is written by technical writers mostly. Developers job is to explain it to writer - it is mostly that docs are more then full time jobs and good technical writer are really better at explaining stuff.
>
How did you managed to twist "measure skills and contributions instead of projecting cool" to "doing the same thing dozens years"? Seriously.
The worst developer out there is is the one that does not do tasks that he does not like. You seem to treat it like the norm and assume that if someone does not visibly loudly jump up and down then he is going to slack it or something.
I don't think it is possible to know everything there is to know about application servers in three years. There are many positions that require neither breadth nor depth and that is fine. If you are in position to mentor people just a year after you entered the field, then the field is too easy and new. I mean, of course any good college graduate can do big data or artificial intelligence. Why would not they? They are best equipped to do math heavy things and they are already adults. Ability to confidently bullshit after 3 months of learning is not the only way how to be a good developer.
And yet there is no reason to bracket that trait with age. There are plenty of people fresh out of school who don't learn anything unless they are told to.
I always hear of this mythical tech geezer who has been doing things the same way for 30 years and stuck in their ways. I don't think I've ever met one.
I always hear of this mythical tech geezer who has been doing things the same way for 30 years and stuck in their ways. I don't think I've ever met one.
If people have to "present papers" and "blog about stuff" just to keep a steady paycheck, it's a sign the industry is broken.
The industry itself is only a few decades old.. it'll take some time before it stabilizes to a point where you can largely do the same thing your entire career.
Also everybody doesn't have to present papers, or speak in seminars, etc. but most older developers who are sought after usually do.
Also everybody doesn't have to present papers, or speak in seminars, etc. but most older developers who are sought after usually do.
Because the person who writes a lot of blog posts is the person who spends a lot of time marketing themselves but not actually getting shit done. If you think a blog post is proof of knowledge, well wow, you'd be shocked at what academia's peer review process is.
Why is that? Given two candidates, one is actively up on current technology and the other isn't, it can be argued the first one has an edge.
I've noticed this as well. The number of people in tech who very clearly have no interest outside of their paycheck is disheartening. Can they do they job? Usually. Will they ever update their skills or keep up with the general direction of the industry? Almost never.
Ageism is the one -ism everybody suffers from.
It doesn't matter how privileged you are. You might think "hey, I'm a straight cis white male, I'll never have to worry about discrimination!". And then 20 years later, you're middle-aged. Hello age discrimination!
It doesn't matter how privileged you are. You might think "hey, I'm a straight cis white male, I'll never have to worry about discrimination!". And then 20 years later, you're middle-aged. Hello age discrimination!
Dumb argument - straight cis white males are agrubly the ones who have to worry about discrimination the most.
Why do you think we're seeing articles about ageism in tech? It's because people do care about it. Look at all the ethical issues that don't get much attention - H1Bs and social stratification in India for example.
Why do you think we're seeing articles about ageism in tech? It's because people do care about it. Look at all the ethical issues that don't get much attention - H1Bs and social stratification in India for example.
I've been rejected from a job before (where I knew someone working there) and was told they had to go with a "diversity hire" since they lost their only female engineer earlier that year. The comments implying I have it easy just because of my gender and skin color are ridiculous and only serve to further divide, not to mention incredibly insulting to the groups mentioned.
>Removing terms like “recent graduate” and “digital native” could help encourage older professionals to apply for these positions.
Or, "you'll join a young team of developers ...", a type of phrasing that makes it very clear who will be a "culture fit" and who probably won't.
Recently I came across a job ad from a SV startup company that contained the text "We are looking to hire talented young developers for backend development" . The message doesn't get much clearer than that.
Or, "you'll join a young team of developers ...", a type of phrasing that makes it very clear who will be a "culture fit" and who probably won't.
Recently I came across a job ad from a SV startup company that contained the text "We are looking to hire talented young developers for backend development" . The message doesn't get much clearer than that.
I think framing things as some sort of discrimination, "ageism" in this case, constantly works to avoid actually approaching the question of why things are the way they are by instead simply blaming prejudice or other unreasonable issues. So for instance a few random issues, or perceived issues:
- Older workers are genuinely more well qualified and are going to demand a substantially higher salary than younger workers.
- Younger workers are less likely to have family and other outside commitments that may take priority over work related issues.
- Younger workers may still see things like web technologies becoming obsoleted every few years as an exciting and invigorating thing, anxious to learn the next big thing (that will then be obsolete 3 years later).
- Pair the above two to yield the fact that younger workers may be more inclined to spend their own time pursuing interests that could improve their perceived value as an employee.
- Older workers have a better understanding of employee-employer relationships and may be less inclined to accept unreasonable 'friendly nudges' that can encourage younger workers to "give 110%" [without corresponding compensation]
- Older workers are going to have a better idea of what they're worth than younger workers who will, almost invariably, dramatically lowball their worth. This gets back to point #1, but also arises in things like contract negotiations.
"Ageism" suggests people are discriminating against individuals because of their age. Choosing to hire people who have certain characteristics, even when those characteristics are less prevalent in older individuals, is in no way discriminatory. And in framing it as ageism we ignore why people may prefer younger workers and the discussion of whether these reason are legitimate.
I half wish we had a way to completely remove any identity related characteristic from the hiring process and end once and for all any allegations of discrimination. Full on voice scrambling, audio only discussion, and VR in lieu of on-site interviews. Only downside would be a necessary restriction on certain topics that could implicitly reveal identifying information. It'd be like the dating shows of the 90s. After you'd made an offer that was accepted, the block would turn and you'd finally get meet your new employee.
- Older workers are genuinely more well qualified and are going to demand a substantially higher salary than younger workers.
- Younger workers are less likely to have family and other outside commitments that may take priority over work related issues.
- Younger workers may still see things like web technologies becoming obsoleted every few years as an exciting and invigorating thing, anxious to learn the next big thing (that will then be obsolete 3 years later).
- Pair the above two to yield the fact that younger workers may be more inclined to spend their own time pursuing interests that could improve their perceived value as an employee.
- Older workers have a better understanding of employee-employer relationships and may be less inclined to accept unreasonable 'friendly nudges' that can encourage younger workers to "give 110%" [without corresponding compensation]
- Older workers are going to have a better idea of what they're worth than younger workers who will, almost invariably, dramatically lowball their worth. This gets back to point #1, but also arises in things like contract negotiations.
"Ageism" suggests people are discriminating against individuals because of their age. Choosing to hire people who have certain characteristics, even when those characteristics are less prevalent in older individuals, is in no way discriminatory. And in framing it as ageism we ignore why people may prefer younger workers and the discussion of whether these reason are legitimate.
I half wish we had a way to completely remove any identity related characteristic from the hiring process and end once and for all any allegations of discrimination. Full on voice scrambling, audio only discussion, and VR in lieu of on-site interviews. Only downside would be a necessary restriction on certain topics that could implicitly reveal identifying information. It'd be like the dating shows of the 90s. After you'd made an offer that was accepted, the block would turn and you'd finally get meet your new employee.
This for me was the most thought provoking comment on this entire thread. It tends to be the case that when accusations of prejudice are lightly thrown around, slowing down, thinking reasonably, and giving our fellow humans a cursory benefit of the doubt casts a totally different light on the issue. That said:
> I half wish we had a way to completely remove any identity related characteristic from the hiring process and end once and for all any allegations of discrimination. Full on voice scrambling, audio only discussion, and VR in lieu of on-site interviews.
I feel like I could figure out their age and race just from vernacular. Plus that would be ridiculous. I don't want to hire someone who I don't want around the office.
> I half wish we had a way to completely remove any identity related characteristic from the hiring process and end once and for all any allegations of discrimination. Full on voice scrambling, audio only discussion, and VR in lieu of on-site interviews.
I feel like I could figure out their age and race just from vernacular. Plus that would be ridiculous. I don't want to hire someone who I don't want around the office.
There are 2 kinds of old people:
1. Old battle hardened veterans who can just jump in and clean the floor. The desire more battles and will confront problems head on
2. Folks who are in the industry for a long time and are productive as a consequence of experience and not because they desire to be there
There are folks intersecting the two sets above. But more often than not, folks in 2 are folks with families, mortgages and other commitments making them risk/battle averse. That kills their hireability.
The reasonably confident, smart old folks are the ones who just walk into companies and bash the young interviewers right away (I experienced this as the young interviewer myself).
Young engineers fit the above categories too but they get the benefit of doubt and get hired for potential. Older folks don't seem to have that luxury.
1. Old battle hardened veterans who can just jump in and clean the floor. The desire more battles and will confront problems head on
2. Folks who are in the industry for a long time and are productive as a consequence of experience and not because they desire to be there
There are folks intersecting the two sets above. But more often than not, folks in 2 are folks with families, mortgages and other commitments making them risk/battle averse. That kills their hireability.
The reasonably confident, smart old folks are the ones who just walk into companies and bash the young interviewers right away (I experienced this as the young interviewer myself).
Young engineers fit the above categories too but they get the benefit of doubt and get hired for potential. Older folks don't seem to have that luxury.
Respectfully there is also another group:
3. Folks who have been in the industry for a while, are very comfortable with the tools they've used previously, are not always open to embracing new tech, and have compensation expectations a little higher than the market value of what they're offering.
I'm not denying ageism exists, but I think it's disingenuous to suggest people in our industry are immune to becoming complacent over time. I think the primary problem might just be that our industry is more punishing for people who do.
I also think people are pointing at the young-skewing culture in tech and looking at it as the cause of the problem, when it's possible it's a symptom.
I don't know how any of that can be measured, but I think it's something we have to keep in mind in this discussion about apparent ageism.
3. Folks who have been in the industry for a while, are very comfortable with the tools they've used previously, are not always open to embracing new tech, and have compensation expectations a little higher than the market value of what they're offering.
I'm not denying ageism exists, but I think it's disingenuous to suggest people in our industry are immune to becoming complacent over time. I think the primary problem might just be that our industry is more punishing for people who do.
I also think people are pointing at the young-skewing culture in tech and looking at it as the cause of the problem, when it's possible it's a symptom.
I don't know how any of that can be measured, but I think it's something we have to keep in mind in this discussion about apparent ageism.
3. Folks who understand business, and know a crappy deal or a hopeless cause when we see one. I believe this is the majority of the so called "risk averse."
I'm 53, and consider myself to be in the first and third categories: I'm certainly willing to jump in and produce, and I'm not afraid of hard problems, but I can see when someone's trying to lure me with empty promises, or who is taking unnecessary business risks.
We also respect you enough to have a frank conversation with you, which could be unnerving if you're accustomed to interviewing people who have been trained to tell you what they think you want to hear.
I'm 53, and consider myself to be in the first and third categories: I'm certainly willing to jump in and produce, and I'm not afraid of hard problems, but I can see when someone's trying to lure me with empty promises, or who is taking unnecessary business risks.
We also respect you enough to have a frank conversation with you, which could be unnerving if you're accustomed to interviewing people who have been trained to tell you what they think you want to hear.
3. Folks who understand business, and know a crappy deal or a hopeless cause when we see one. I believe this is the majority of the so called "risk averse."
You are number 1 in the categories I defined in my original post.
Risk averse people are people who cannot move out of their language, area of expertise etc.
You are number 1 in the categories I defined in my original post.
Risk averse people are people who cannot move out of their language, area of expertise etc.
I hate to think about it, but answering questions about things like risk aversion may be akin to the coding interview, where they could be studied and memorized. The flip side is that with business experience, the older candidate could make an educated guess about how likely it actually is, that they will have to work outside of their existing skill set. So, objectively assessing the risk is sometimes an alternative to simply avoiding it without knowing if the risk is real.
What kind of companies do you all work for that willingness to "battle" and "risk" is so important? Software development is normally one of the safest jobs there is. It is even stereotyped to have above average amount of people on spectrum and that condition makes one sux at both political fighting and risk handling.
If you need everybody to battle that often, then there is something wrong. And if ability to handle risk is so important for developers, then maybe management should start to manage that risk.
If you need everybody to battle that often, then there is something wrong. And if ability to handle risk is so important for developers, then maybe management should start to manage that risk.
>> What kind of companies do you all work for that willingness to "battle" and "risk" is so important?
When I (as a 5 year experienced person) have to explain to an older developer how the code base HE OWNED for 2 years works internally.
When I (as a 5 year experienced person) have to explain to an older developer how the code base HE OWNED for 2 years works internally.
What was the risk there? Why would explaining be a battle? Was he a complete jerk or high in company? I dont know everything about codebase I own either, some parts I barely seen despite owning them and some I have seen but forgot what it means. So I mean, I would not mind if someone learned parts of it I have barely seen and gave me tldr.
The risk is when customer calls with a showstopper bug, if I (the new hire) cannot even rely on the experienced, god save that product.
I'm not saying people need to know everything inside out. But damn it know some codepath please after 2 years.
I'm not saying people need to know everything inside out. But damn it know some codepath please after 2 years.
1) I've witnessed ageism.
2) I've worked with old timers who do nothing and get paid a ton. I still can't figure out what they do all all day. I think they go on 10 coffee breaks and browse the web.
I suspect the latter is a stereotype that motivates the former.
2) I've worked with old timers who do nothing and get paid a ton. I still can't figure out what they do all all day. I think they go on 10 coffee breaks and browse the web.
I suspect the latter is a stereotype that motivates the former.
"I still can't figure out what they do all all day."
Could be not much of value, but could also be that you just haven't figured it out.
I've seen two kind of older employees. 1) Those that have the experience to know which problems are worth solving and how to solve these problems with minimal effort and disruption and 2) Those that have simply grown lazy and complacent while developing the workplace skills to keep their position.
Younger me had a hard time telling the difference and figured it was just lazy all around.
Could be not much of value, but could also be that you just haven't figured it out.
I've seen two kind of older employees. 1) Those that have the experience to know which problems are worth solving and how to solve these problems with minimal effort and disruption and 2) Those that have simply grown lazy and complacent while developing the workplace skills to keep their position.
Younger me had a hard time telling the difference and figured it was just lazy all around.
There are people whose value I don't understand. There are people who are on reddit and coffee breaks constantly. They produce no output. Others complain about them too.
It's just yet one more form of discrimination based on one (or more) stereotypes.
Isn't all hiring based on stereotypes? e.g the "ninja" programmer?
Hmm, maybe you and I have a different definition of 'ninja programmer'.. I, and my coworkers, define it as someone the is highly skilled and is able to get in and get the job done quickly and effectively.
I don't see how you can stereotype based on a skill, ignoring physical qualities of the people with the skill. Maybe we're just naïve.
I don't see how you can stereotype based on a skill, ignoring physical qualities of the people with the skill. Maybe we're just naïve.
And how do you determine this in an interview?
It's incredibly irresponsible to see this and think "not my problem". This is the one form of discrimination that eventually comes for us all, unless you get rich or die first. And yet, does it come up in discussions of diversity and inclusion? Rarely, and if it does, pretty much just as an aside. I've never seen a company that had goals to hire people in certain age brackets, or even bothered to offer an age breakdown of recent hires, as they do with race and gender.
I wonder what the industry will look like at the time ageism really starts affecting the early 20 somethings.
If we are still doing JavaScript frameworks and Webpack in 20 years I'll be a bit surprised. In which case it might be a double whammy. Ageism and a significant start over.
If we are still doing JavaScript frameworks and Webpack in 20 years I'll be a bit surprised. In which case it might be a double whammy. Ageism and a significant start over.
Focusing so heavily on computer science trivia questions favor those who recently went to college, since those tidbits are so rarely needed at the drop of a hat in industry those neurons wither away with more time away from academia. Older developers know you can just look it up.
Take home quizzes and side projects require significant time investments. People tend to have less free time as they get older due to family obligations, changing priorities, and so on. People directly out of college likely have less of these external time pressures and would have less of a problem solving your so-clever little project that only takes 20 hours.
Until we, as an industry, get over the lie that hiring must be incredibly accurate and therefore favor the so-called "false negative", we won't get rid of this kind of discrimination and we'll continue to harm people simply because they're older; not to mention losing out on potential co-workers with a plethora of knowledge and experience.
It's bizarre to me that ageism exists. Other forms of discrimination can be traced to othering someone because they are dissimilar to you. Every single human will become an older person one day, barring early death. Perpetuating this cycle is self defeating in the end.