Hey Charles! Thanks for sharing your thoughts, and I'm glad you enjoyed the article.

Age discrimination is much less common than people "aging out" of their skills while the entire industry has changed around them.

For example, imagine the job market today for Ruby on Rails engineers -- it's much thinner now than it was in the 00's when Ruby on Rails was a serious competitor to PHP, Java, and ASP

If you go further back and imagine Java developers -- their pay has gone way down, despite their being many Java (especially SpringBoot) openings, because many other people moved on to newer, better technologies that offer a better developer experience.

Those left fighting over the ever-dwindling number of Java jobs have to also contend with the thousands of college graduates each year who only learned Java, not web development, so web development is a skill with both higher demand and lower supply -- thus, higher salaries, and an easier time getting hired when you've demonstrated expert mastery of modern web development tech stack (say, "a Next.js developer" compared to "just another Java developer").

If you're applying for a job with 5, 10, 15, or more years of work experience, but you have no work experience with the actual tech stack.

That's why my entire Career Programming publication is about how to "get over that hump," whether you're starting out or learning new skills.

I've found it be overwhelming true that people who have been in the software engineering industry a long time don't have the same passion for "breaking into the industry," "paying their dues," "specializing in a new tech stack" as early-career developers.

I think a lot of people wish programming was a "typical" job like HR where years of experience was a good thing, but all that really matters in tech hiring is whether you can come in and contribute at an expert level from day 1.

The factors that matter to hiring managers are 1) you're currently employed in another position using those same exact skills and/or you've demonstrated world-class knowledge on a take-home assignment.

Of course, #1 is just an unjustified bias against unemployed people -- "if you're unemployed, then you must be unemployable" -- and #2 requires each candidate who wants to participate to invest 8-16+ hours in completing the take-home, and it has to be intelligently designed and graded objectively to really be of that much use.

--

Oh, and I agree about that the 8-16+ hours spent on a take-home assignment should reduce the number of interviews required, but executives often push for many more, entirely useless interviews under the guise.

I recommended hiring someone once, but he "failed" one of those extra, unnecessary interviews. We hired the guy who that executive liked, instead, and -- after making us wait more than 2 months for him to join the team -- he quit with no notice after less than 1.5 months. We ended up going with the original hire, just 4 months later, for no good reason.

As I wrote in this article, my recommendation is that take-home assignments should be limited to about 2 hours through investing 24+ hours of an engineer's time in designing the assignment and writing down an objective rubric to evaluate candidate's performance.

Those concerns are important both for demonstrating respect to candidates -- many job postings receive 40+ take-home assignments, even when they take 8-16+ hours -- and for ensuring that the process is legal for mandatory equal opportunity employment, which should matter more to businesses since lawsuits are way more expensive than asking an engineer to dedicate 3 workdays to creating a good, short take-home project with an objective scoring rubric.