This is in response to an excellent post by @vorahsa about how the industry treats people, and how he has even heard his coworkers referencing these beliefs that, if true, would mean they wouldn't hire HIM. He's most definitely NOT unhireable and sounds like an asset to his team.
This was originally a comment on his article, but seeing as my comments tend to be long-form, AND I tend to be shy about making my own posts, I figured this was a great opportunity for a standalone article so I have to start off by thanking him for his.
Much of this is opinion. There will be at least one link to a supporting resource. I can't promise any more than that!
Not all corporations are malicious, just as not all coders are job-hoppers, not all engineers over 40 are stuck in COBOL and not all PhD holders will design a Rube Goldberg machine if left unsupervised. There's also something to be said of the sub-industries in software engineering like medical equipment, banking, insurance and others where many of these negative stereotypes are inverted, but the ones mentioned in the original article are some of the most prevalent that you will hear today.
The headings will reference some of the biases he has seen or heard others talking about. Hopefully it's a solid companion to that article, analyzing some of the reasons for these negative memes in the industry, and why you should never, ever listen to them. Evaluate the person, not the stereotype!
Working at the same place for a long time is fine, but I think the reason for this particular piece of bad advice is that if you work in one place for a long time and that place is settled into a particular way of doing things, then it limits the variety of approaches you're exposed to.
I can't let this point go by without also mentioning that it is easier to get a raise by moving companies... but I wouldn't suggest that money is all there is to any given company either.
You can also consider if you've done all you can at the company. A friend of mine used this car mechanic analogy:
You're the headlight guy in the shop and you work on one specific car in one specific garage. You've bought the shop all the equipment, you've put in a lot of work. That car is probably as optimized for headlights as it is going to get with you in the shop. It's probably time to move on to a shop that has never had a headlights guy, and let a guy that is into radiators come in behind you to move the project/team forward.
These are valid reasons to leave after a couple of years, but if that shop has new cars coming in everyday, money isn't the primary motivator for you (those people DO exist), you're getting a good variety of experiences, and you feel like you're expanding your skillset in a worthwhile way, then there's no reason for it to be a requirement.
I think a good pattern for a young engineer (for both experience and advancement) would be to move jobs every few years. After you feel very comfortable in your specialization, either start looking for new things to learn and specialize in or start looking for a long-term position. You may never find it, but there does come a time when the revolving door of new jobs starts to wear thin.
If someone reading this has NOT done that, it's definitely not a career-killer, and to disqualify someone on this basis doesn't make any real business sense. New hires are expensive. Having someone in it with you for the long haul is a huge benefit to a company, but make sure you push your workplace to keep finding better solutions and don't fall into the trap of "the way we've always done it".
When it comes to the general topic of "passion" (Github, when you learned to program, how much you program in your off-time) there are two possibilities I've found when faced with a company or hiring manager that actually believes in this, and neither makes me want to work for them.
Either it's a dog-whistle that they are looking for someone who will work after-hours for no additional pay because they are "so interested in the problem" OR they haven't really thought about what that line of inquiry really means. It's just parroting what they've heard other people say in interviews because it's the "right" question. Neither is a very attractive look, and this approach is a signpost for me as the interviewee that I need to start looking for other red-flags (Though, in fairness to interviewers everywhere, it's not a disqualifier by itself).
Specifically with Github, my immediate response is "I was writing code with a wife, son, and a lawn to mow before Github existed, and none of my jobs have required me to commit in an open-source repo", and I've never had trouble with that answer in an interview. For a younger person, that can easily be modified to "I've never really worked in an open-source job, so I haven't built a lot on Github." If you're being really cheeky, try adding a "Will we be building open-source software on this team?" to the end of it, if it isn't too obvious what the answer is!
Ageism is another place where it's a real issue for the victims, and not even the actual problem it's perpetrators would have you believe. It's more about how much the company can push you to give them more work for less money than it is your age.
While I have run into a few older engineers who learned to program one way many years ago and don't want to learn more (which is the reason ageists give to justify why they want younger engineers, if they even own up to it, instead of hiding behind phrases like "overqualified" for legal reasons) I've met FAR more who are still keeping their skills up-to-date and have decades of experience that would be an asset to any team.
Unfortunately (according to the companies who do this) those "overqualified" engineers have also built lives and interests outside of work (the aforementioned "partner/children/lawn/insert hobby here" issue) and are far more likely to work the hours they are paid to work and go about their lives in their free time. An employer that uses this logic compares that to a new grad right out of University who has fewer home responsibilities, more free time, and an eagerness to "prove" themselves, and chooses the more (seemingly) profitable option, ignoring the benefit that experience brings in favor of the more immediate perceived cost/benefit.
This employer believes that weeks of crunch time are met with fewer complaints if the person has fewer responsibilities outside of work and the employee thinks they "owe" the extra time to the company that "gave them their shot". This is terribly unfair to the younger engineers. It trains them that this is just "how it is" in the industry, and that their free time is unimportant. You have to have downtime, and you have to have time to build the life that a more nefarious company will resent you having once you get to a "certain age".
Crunch time all the time is a failure of the organization. Not your skill or the skill of those around you.
This is also where I have to mention a personal pet-peeve. Take-home coding tests. I put this under a combination of the two, because while I do feel it disproportionately impacts older workers (Again with the "partner/children/chores" issue), it's just as much a test to find out how much of your free time you will spend on work tasks as it is a test of your ability.
I don't do well on them, and I refuse to take them anymore.
That has less to do with my ability as an engineer and more to do with this ("You just black-holed me" is a joke in our house).
My "free time" isn't really mine and hasn't been for over a decade. It's my wife's. It's my son's. If you don't have equivalent relationships, your free time belongs to your comic books, or your mountain climbing, or your volunteering, or your video games. Your free time does not belong to a company that isn't even going to compensate you for the "two hour" test that actually takes two days of every spare moment you can scrape together.
According to some sources, I'm one of the oldest Millennials. Or the youngest Gen-X'er. Or the Oregon Trail Generation... it doesn't matter, with this beard I've been asked if I have grandkids before, and I've felt like the "old man" in a LOT of shops (it's even in my profile). "Passion"-bias and ageism haven't started impacting the majority of us in tandem... but pretty soon many of us will start facing it in the workplace, and Gen Z (who are a bigger cohort than any other generation, and starting to graduate college) will be calling us the olds.
Finally, the anti-academia movement. This one has a lot of roots. Again, the seed of truth in this is rooted in a few negative experiences and plays on some existing biases. The seed is that, while I have worked with some great coders with postgraduate degrees, I've also met a (very) few who were more concerned with extremely complex (one might say complicated, or even accidentally complex) solutions to very simple problems. In these situations, many in this small set hadn't actually spent as much time writing code as they had writing theses, and it shows in their ability. This is not all, or even a majority of the academic population (I currently work with some highly educated engineers who are great, and this post was inspired by a PhD!), but it's where this bias comes from.
On the business-side, higher qualifications means higher compensation. The VAST majority of programming work out there doesn't deal with optimizing compilers, programming gates in the processor, or require a detailed knowledge of how data packets are sent across networks. It's generally code-plumbing. Plumbing is a very hard field, it takes a lot of skill and knowledge of things like building codes, local ordinances, technical knowledge about how fluid dynamics in a system work and a million other things I wouldn't pretend to know, but it is a skilled trade and is well compensated for that skill. That skill comes from hands-on experience over years of practice, not from studying advanced fluid dynamics to understand how supernovae in a vacuum spread or how the atmosphere moves to create various weather patterns. As a business, I wouldn't hire a Physics PhD with a specialization in Fluid Mechanics to build the plumbing in my building, and the same can be said for implementing a code-base.
If that PhD holder had written their thesis on plumbing, spent a career designing and implementing plumbing and had demonstrable skill in that field it's absolutely not a disqualifying criteria either. If the intrinsic complexity of my problem requires someone with a PhD to solve it then I need someone with a PhD. NASA can't hire plumbers for the work they do. In these situations this is an attractive and beneficial trait to have on your team, worth every penny of premium paid for the advanced degree. But very few companies are NASA.
Most of these biases are specifically geared to get the maximum benefit for the company at all costs. Unfortunately these ideas have been seeded into the community from interviews and experiences with very large companies and the cargo-cult following people have about emulating them. That community includes hiring managers who want to build their engineering team into a Google-like powerhouse (but only have the headcount for five people).
These gigantic companies have more applicants than they can hire and are able to pick and choose who to hire and not hire. They are also a very large source of jobs, but a very small percentage in the total number of companies looking to hire engineers. Trying to emulate them at a startup or smaller company unnaturally limits your hiring pool and those are the places where I want to work (so it works out well for me if those places are less discriminatory).
There are fewer engineers than jobs worldwide, and certain markets are starved for talent while others are flooded. If you have good interviewing and social skills, combined with good technical ability, then no one is unhireable right now. Maybe you won't end up at Google... but you might be able to build something great.