Out of interest what skills are you talking about? I am an old fart by IT standards and i have come to realise that being able to come up with an algorithm randomly is not such a useful skill considering how infrequently we actually have to do it. Being able to say "no" and getting on with other developers are far more valuable than being able to solve a soduku puzzle once you have acquired a certain level of knowledge. After that it should be about managing complexity.

>i have come to realise that being able to come up with an algorithm randomly is not such a useful skill considering how infrequently we actually have to do it.

This isn't what I'm talking about - I'm talking domain specific skill. If you're a frontend developer for instance, you should understand the new language features of JavaScript that came out in 2015-2016 and be able to use them. You should know how to use flexbox for CSS instead of floats for layout (IMO)

If you're a senior developer still writing code every day, you have to keep up with that stuff. You're ultimately responsible for the codebase in a way that junior/mid devs are not and if you don't understand large aspects of how it works you can't be effective.

It doesn't help that people who stagnate like this usually weren't very good at/engaged with their jobs to begin with. They're usually senior in name only, where their managers know not to actually assign them stuff that matters.

But why?

Do new languages, new language features, new frameworks, new methodologies necessarily add business value? Or are they sometimes just being used because they are new and shiny? Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill. One distinguishing attribute I'd expect from a "senior" developer is the ability to quickly evaluate new technologies, choose and focus on what actually provides business value and have the discipline to ignore the rest. It is possible to be a top performing, highly productive developer today by very effectively using 10 year old technologies.

>Do new languages, new language features, new frameworks, new methodologies necessarily add business value?

Sometimes they do, sometimes they don't. But the tech stack will eventually come to include these new things whether you like it or not. And even if somehow you're able to stop that from happening, eventually it will become very difficult to hire junior developers with experience in old frameworks and eventually those frameworks stop getting supported and community contributions since so many other shops drop it.

The two things I listed specifically are actual fundamental changes to CSS and JavaScript, not fly by night frameworks and they both do add a lot of value.

>Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill.

I actually do sympathize with this way of thinking, and I used to agree with it. But I've come to understand how misguided it really is. Every well paying knowledge worker profession requires updating your skills from time to time. Doctors have to learn new guidelines for treatment and different ways to do surgeries/procedures. Lawyers have to brush up on developments in case law etc...

Programming already has an extreme advantage over a lot of these professions. There's no licensing board, you don't even need a degree if you can pass the interview. It's silly to think that we should also be immune to honing our craft and changing with the times.

If you're a software engineer, you should have the expectation that you're going to need to do a little bit of career development every year. I don't mean spending 10+ hours a week on it, but to use the examples above... I realized in like 2016 that I didn't know Flexbox and that was pretty much the new standard for how layout was going to happen in CSS. So I made myself learn it. And not only does that update my skills, Flexbox is actually way better to lay elements out on a page with than the old way. It's made building html/css views out much quicker.

But there are other considerations. The constraint solver in flexbox used to be a lot slower to render than other layout methods. And if you have experience in non-web UI frameworks, you can see that flexbox isn't that different from things you can find in Swing and Qt, so you can just wait a while and learn it in a day when you need it.

I've seen nigh unmaintainable web apps that were entirely laid out in really overwrought nested flexboxes, when using utterly basic HTML elements like <p> and <h3> and <dl> with a bit of CSS would have rendered faster, been developed faster, worked in older browsers, and worked better with accessibility tech.

So really, flexbox is just another new old thing, and what matters is the concept of constraint-based layout as one tool out of many. If it's the first new thing you encounter in your career, it's worth learning it because it's there, but remember that it's just another spoke on an ever-turning wheel.

Often times none of that is tested during the interview though, so you don't know whether the person is knowledgable on any of those or other frontend specifics until you've hired them because they were able to pass an leetcode DS&A phonescreen and 3-4 leetcode DS&A onsite rounds.

I've noticed this is changing (spearheaded by FAANG & other top tech companies it seems) - there are frontend specific tracks that test more JavaScript knowledge than leetcode puzzles.

But as usual, if there is a cutting edge, there are many more laggards, and I'd say many companies are still doing leetcode DS&A for frontend too.

It really just depends on where you're interviewing. A lot of places that hire software engineers don't ask algorithmic questions at all.

It's really impossible to generalize about most aspects of this career in my opinion. There are no hard rules about anything, even hiring.

I think about this in relation to the "skill gap" in programming a lot. There are people who work in very senior positions in software development who couldn't do a LeetCode easy or a FizzBuzz. They don't read articles about how to get better at programming or about concepts like DRY etc... but maybe they do the very specific thing their employer wants well enough, that combined with their long tenure and relationships with other people they are pretty much lifers.

That's why I laugh when I see articles on Hacker News articles where it says if you don't do X Y or Z you're not a "real" programmer. Meanwhile a huge swath of people employed as programmers haven't even heard of a lot of this stuff, much less actually used it.

"where" is the key word here I think. But at least in the vicinity of the major US coastal cities (SFBA, Seattle, NYC, probably LA and a few others) where a lot of tech jobs are concentrated, I would say most companies are in fact, leetcoding candidates to some degree.

Half my team is in London (big bank), as is my manager, and I know they leetcode candidates there too - and we're not even a tech company or elite financial firm, just a boring big conservative bank.

If you're looking for a job in this day and age, I think it's safer to assume you're going to get leetcoded and be prepared. Rather than try to find the rarer and rarer company that doesn't leetcode you.

> If you're a senior developer still writing code every day, you have to keep up with that stuff.

Can you give me an example of a task that I couldn't have done with ten year old tech?

Will it automatically be better because I am using this years chosen framework (or will it be more likely that there are unforeseen problems because of not using a mature technology).

Not the OP but I largely look for experience with CI/CD workflows and release management, unit/integration/systems testing that doesn't cripple R&D, QA, distributed systems beyond a webserver & DB, and just general "philosophy of software engineering" type stuff like an understanding of the factors that led to the evolution from monolith to microservice, agile/scrum/management fad of the week, and how to make tech tradeoffs based on business goals. These are largely soft skills, not algorithmic trivia.

Unfortunately, there's no one size fits all worksheet for those soft skills that HR can hand out to interviewers, so everyone gets lazy and falls back to the whiteboard BS.

Frontend dev is a really good example of a field that is all short strings and missing the longer trends. It doesn't matter what framework you use, or no framework at all, if the site can be maintained, the site is fast, and it looks good in all the browsers you are targeting. Bootstrap, jQuery, React, Vue, etc can all be sloppy, or they can be used incisively.