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!
On NOT Staying in the Same Company for Longer Than 2 Years
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".
On Passion... The Greater of Two Evils
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!
On Ageism... The Greater of Two... wait... they're both Evil, OK?
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.
On the Combination of the Two (Two Bad Tastes That Taste Terrible Together)
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.
Full Disclosure... I never finished the last 12 credits on my Bachelor's
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.
How Does This Impact the Real World (Not Google)?
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.
Oldest comments (11)
Awesome article especially the part in companies limiting their pool of engineers by trying to follow Google in the most extreme way.
Thanks! I think it's critically important for companies to honestly understand where they are in their lifecycle and make decisions based on what's best for that company, at that time.
None of us can predict the future, so trying to build a 5 person team to operate (and hire) like Google is going to make the road a LOT harder than it needs to be!
"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""
Bingo!
When I get this same question (I have yet to), I'll simply say that all projects worked on at companies are closed source. Which is the truth.
Alas, look at my portfolio instead!
I feel like a lot of this overemphasis on being able to see your previous work comes from a decade-old blog post from Jeff Atwood (blog.codinghorror.com/why-cant-pro...) which is also what popularized fizzbuzz IIRC. The fear you will get a programmer who can't program.
It's part of the anti-academia movement too.
But honestly tools like fizzbuzz or just a little bit of light whiteboarding (another thing we glorify a bit too much in interviews) takes care of that.
Styleguides change by company and can be taught. If a person has a long track record of implementation and no red flags, I don't see how useful it is to require that they build a long collection of code-samples, just to prove they can do their job... There's not another knowledge worker that has the same except maybe for the scientific fields and publishing... But I think that's a poor standard for a field that changes as rapidly as software engineering...
Today, being asked fizzbuzz in an interview would be a red flag.
I've seen people say that even a simple "problem" like that can tell you about the interviewee. Sorry, beg to differ with such folk. Even though interviewers who used it might well be competent developers themselves, it's an un-enlightening interview question.
The thing about fizzbuzz is not that it is too simple. It is that it is trivial. It is trivial even to a competent student midway through a CS course. The only thing you can attempt to find via fzzbuzz is aspects like how they name, or whether they write tests. But, fuzzbuzz is too trivial a test for these aspects either. So, you'll end up judging a candidate by trivial choices and trivial disagreements.
Instead, find a problem that is simple in the sense that it does not take too much time, but make it something a programmer has to think about for a few minutes. Make it something that has at least one follow-up question, perhaps with a twist. You can still judge things like naming (but, don't be pedantic).
But, mainly... watch if the person's eyes light up when they try to figure out your little problem, and see if they give it their best shot. That'll give you more than watching how good they are at stifling their yawns as they plod through fizzbuzz.
Honestly I'm being a bit loose with the definition of fizzbuzz, because yes the exact "fizz on threes, buzz on fives, fizzbuzz on both" has been ground into the dirt so much that it's useless due to exposure.
Originally it was to test if the candidate knew how to use the modulus operator, as knowing how mod works indicates an understanding of how a lot of things in programming work...
Now it just tests if you did the bare minimum refresher before the interview haha!
When I say fizzbuzz I'm really thinking of a small algorithmic problem for exactly the same use. I think I agree that the best indicator is if they shrink away and don't try or if they jump in feet first!
I'm never worried about naming or whitespace or whatever in an interview... Like I said, styleguides change from job to job, but that urge to learn and solve problems is what we all should be striving for!
Understood. My rant was confined to true fizzbuzz.
I'm fine with little coding problems. Ideally, the candidate can be asked to do something like that before they come in for an interview, or before they actually interview with a person.
There's an aspect that's useful during an interview too: to try to see how they think (without making it some super puzzler).
The key thing to look for is clarity of concepts and clarity of thought.
A great post and good continuation to mine! I'm sure you're not surprised that I pretty much agree with everything you wrote.
Thanks so much! I think it's an important conversation to have, and one that can help move the industry forward. Thank you for kicking it off, because we need to keep the focus on improving our industry and move the standards a little bit at a time!
I see what you're saying, but rocket engine plumbing is actually a thing.
I'm actually excited about this comment because it gives me a chance to talk about one of the funniest conversations I've had about this article.
One of my friends is a mid-career changer from hardware to software engineer.
We joke about the fact that, before he switched, he used to work on lightsabers (plasma... Specifically plasma torches IIRC)
He called this out as well:
I responded with one of my favorite nerd jokes I've ever made that only works in this context:
Replace lightsaber plumbing with rocket science and it still works haha