The main factor, IMO, is that everyone wants good engineers but good engineers don't change jobs that often.

Meaning most of the candidates you interview will suck in one way or another.

And everyone calls themselves "senior" nowadays.

It’s always DNS, everyone should know that.

It's not DNS. There's no way it is DNS. It's not technically possible for it to be DNS.

And it's always DNS.

Everyone calls themselves senior because that's the only type of position recruiters look for.

I'm a mid level dev, but I'm encouraged by recruiters to apply for senior positions because their clients are actually looking for a range of levels

I have the opposite experience, when I was doing interviews I just skipped the very obviously underskilled people (which, IIRC were in the single digits) and interviewed pretty much everyone.

For context, I'm the main architect and dev of the company I was hiring for. Most of the candidates were horrible.

The main factor, IMO, is that everyone wants good engineers but good engineers don't change jobs that often.

Meaning most of the candidates you interview will suck in one way or another.

And everyone calls themselves "senior" nowadays.

I'm reminded of when my boss asked me whether our entry test was too hard after getting several submissions that wouldn't even run.

Sometimes prospective employees are just shit.

That is technically correct in a way, but I'll argue very wrong in a meaningful way.

Cloud services are meant to let you focus less on the plumbing, so naturally many skills in that will not be developed, and skills adjacent to it will be less developed.

Buttttt you must assume effort remains constant!

So you get to focus more on other things now. E.g. functional programming, product thinking, rapid prototyping, API stuff, breadth of languages, etc. I bet the seniors you are missing X and Y in have bigger Zs and also some Qs that you may not be used to consider, or have the experience to spot and evaluate.

I'm a very good engineer, but so much of my time is consumed fighting with Tekton pipelines and migrating testing frameworks and versions I barely have time to write code. But that's because I can figure that stuff out when I have to. All the code is written by the people who can't figure that stuff out.

Why this isn't two separate jobs I can't understand. Let me do some stuff I'm good at rather than constantly fighting with things I'm not?

You want to hire the "guru", not the "principal". You want to actually ask him to write 0xD6 in decimal, and if he dares to answer "Seriously? Come on now, that's boring", then you hire him on the spot.

But you can't hire only gurus. You need normal seniors, too. Build a normal team around one guru. Maybe build one ultra advanced team around 2-3 gurus, if you really need to invent new and hardcore difficult stuff.

Does a senior mechanic need to understand the physics of piston design to be a great mechanic

I would argue that if senior mechanic doesn't understand the physics of piston design at least on some degree he's not a great mechanic. Obviously mechanic doesn't need understanding on metallurgy, CAD models and a ton of other deeper level stuff just like an IT engineer doesn't need to know on a deep level how circuit boards are designed or how CPU die manufacturing process works. But both benefit greatly when they understand why something is built the way it is.

I'm also an systems engineer of sorts and have worked with software engineers. And I've had requests like "Can't you just set 'bind-address = 0.0.0.0 on mysql-server and disable firewall" on a directly internet-facing machine and then received complaints when I'm "making things more difficult" from "senior software" -titles. Sure, I can't write the code they're doing, or at least it would take me a crapload of more time to do that but on the other hand there's guys who have so very narrow understanding on anything they work with that it makes me wonder how they can do their work at all in the first place.

Of course no one can master everything in any field but I find it concerning that a lot of guys just press the buttons more or less randomly until their thing works without any clue on what they actually did and how it might affect on different parts of the house of cards they're building.

I disagree. On paper that sounds good, but I firmly believe good engineers are curious, so they'll learn a lot more than necessary to do the job.

For example, when I worked at a company that designed antennas as a software engineer (built something tangentially related), I didn't need to know anything about electrical engineering, but I was curious so I asked a ton of questions and now I know a fair amount about EE. These days I work in a very different domain and still ask a ton of questions to our domain experts. In my own field, I look into all kinds of random things tangentially related to the tools I use. In each case, that curiosity has come in handy at some point or another.

In each role, I can tell who's there to clock in and clock out vs who is genuinely curious and looking to improve, and it's the latter group who tend to produce the best work and go on to great roles after leaving our company, while the 9-5 warriors who just focus on the requirements tend to do pretty mediocre when it comes to advancement.

When I hire, I look for that curiosity because you never know what you'll need to know to fix a prod issue quickly. My esoteric knowledge about SSH helped keep my team productive for a few days when IT was being slow revolving our issue, and likewise we've had quick resolution to prod bugs because someone on the team knew something random that ended up being relevant. That's what I mean when I say I look for a diverse team, I want people with different strengths who all actively seek to improve so we'll have a good shot at handling whatever comes down the pipe (and we get a lot of random stuff, from urgently needing to embed 3D modeling tools into our reporting app to needing to embed complex C++ simulation code or rewrite Fortran code into our largely CRUD Python app).

Most of these cases of "focus on one niche" are often symptoms of lacking curiosity and just wanting to tick boxes to quality for a role. I'd much rather someone miss a few important boxes but tick a lot of random ones because they're curious; they'll take longer to on-board, but they'll likely be more useful long term.

I don't work in the security space, but I think the same applies to most technical fields. Breadth of knowledge in an individual provides depth of knowledge in a team.

I 100% agree.

The best mechanics can track down an issue by reasoning about what could be causing it, and understanding how pistons work can help deduce whether that knocking is actually the engine or something else entirely. They probably didn't learn that from their official training, but instead worked with some guy who used to work at a car manufacturer or something and picked their brain.

The best engineers are curious and jump on opportunities to learn more.

The best mechanics can track down an issue by reasoning about what could be causing it

Same principle works with IT. I do and have done sysadmin stuff for quite a while and there's always some random software or whatever I've never heard of and someone comes and asks me to fix it. Then you start to ask questions, "what exactly doesn't work", "can you show me what you're doing", "what should happen when you press that button", "can you show settings on that thing" and so on. Then you can start to dig down, does the server they're using respond to ping, does DNS resolve (it's always DNS after all), does that thing work on the next workstation, when did the problem appear and was there some other maintenance or changes going on at that time and so on.

Same principle, just start to reason the whole thing from bottom up, check everything you come across untill you find something which doesn't work and then do what's needed to fix that, rinse and repeat until the problem goes away and make sure that what you're doing won't cause new problems. Just the tools are different, the mindset is more or less the same.

Yeah I don't think we actually disagree much here.

I think my angle is just slightly different? I see that ease of access (eg cloud) make it possible for a lot more uncurious and clock-out people to enter the field and pass as competent. To be honest, even the modest introduction of auto-formatting editors are easy to see as good and useful, but I also feel that they allowed shoddy work to look passable at first glance. AI will make this a lot worse.

But as for the actual people who have it in them to be competent, people that were always there and still are, cloud is not going to make them worse.

I went through hiring several times at several companies, being on the interviewer side.

Typically it's not the talent pool as much as what the company has to offer and how much they're willing to pay. I referred top notch engineer friends, and they never made it past HR. A couple were rejected without interview because they asked too high of a salary, despite asking under market average. The rest didn't pass HR on personnality or not having all the "requirements", because the really good engineers are socially awkward and demand flexibility and are honest on the résumé/CV, or are self taught and barely have high-school graduation on there (just like me).

I've literally seen the case of: they want to hire another me, but ended up in a situation where: I wouldn't apply for the position myself, and even if I did, I wouldn't make it to the interview stage where I'd talk to myself and hire myself.

Naturally the candidates that did make it to me weren't great. Those are the people that do the bare minimum, have studied every test question (without understanding), vibe code everything, typically on the younger and very junior side. They're very good at passing HR, and very bad at their actual job.

It's not the technology, it's the companies that hire that ultimately steers the market and what people study for. Job requirements are ridiculous, HR hires engineers on personnality like they're shopping for yet another sales associate, now it takes 6 rounds of interviews for an entry level position at a startup. VC startups continue to pay wildly inflated wages to snatch all the top talent while established companies are laying off as much IT staff as possible to maximize profits.

I went through hiring several times at several companies, being on the interviewer side.

Typically it's not the talent pool as much as what the company has to offer and how much they're willing to pay. I referred top notch engineer friends, and they never made it past HR. A couple were rejected without interview because they asked too high of a salary, despite asking under market average. The rest didn't pass HR on personnality or not having all the "requirements", because the really good engineers are socially awkward and demand flexibility and are honest on the résumé/CV, or are self taught and barely have high-school graduation on there (just like me).

I've literally seen the case of: they want to hire another me, but ended up in a situation where: I wouldn't apply for the position myself, and even if I did, I wouldn't make it to the interview stage where I'd talk to myself and hire myself.

Naturally the candidates that did make it to me weren't great. Those are the people that do the bare minimum, have studied every test question (without understanding), vibe code everything, typically on the younger and very junior side. They're very good at passing HR, and very bad at their actual job.

It's not the technology, it's the companies that hire that ultimately steers the market and what people study for. Job requirements are ridiculous, HR hires engineers on personnality like they're shopping for yet another sales associate, now it takes 6 rounds of interviews for an entry level position at a startup. VC startups continue to pay wildly inflated wages to snatch all the top talent while established companies are laying off as much IT staff as possible to maximize profits.

I think its actually that most people generally don't really understand most things beyond the minimal level necessary to get by. Now that the tech industry isn't just a bunch of nerds you're increasingly more likely to encounter people who are temperamentally disinclined to seek understanding of those details.

I get what you’re saying, but also see the other side - these services exist and aren’t ever going away, so the level of knowledge you need about these to use them at least competently is significantly reduced.

What their existence does mean is that there are thousands of developers who wouldn’t ever touch or learn any of this stuff previously are now actually learning it and using it. That’s a positive thing. Not everyone needs to be an expert on the inner workings of everything that a service provides unless you’re specifically looking for an expert.

Also…..people lie on CVs and cover letters. If your ad has buzzwords and technology X, Y, and Z, then you should expect people with little to no knowledge of at least one of those things to have all 3 on their resume.

I somewhat disagree here, but also somewhat agree.

In my org, we get a lot of requirements that require very different skillsets. For the first 2-3 years, our task list was mostly CRUD stuff with some domain specific logic, but otherwise a boring web app. In the last 1-2 years, we have:

• ported a Fortran simulation to Python
• embedded a C++ simulation in Python
• created a 3D UX for our previously 2D only app (lots of 3D logic on both FE and BE)
• implemented a machine learning algorithm to train our simulations

If I hired only for the work I'd seen in the past, we'd be completely unfit to handle this workload since we'd mostly have people who are really good at building CRUD apps (so DB optimization and quick UX building).

On the flipside, we cut off huge swaths of work so people don't need to wear too many hats. We have:

• dedicated devOPs - handles everything from trst pipelines to prod deployments
• dedicated QA - manual and automated app-level testing - devs still do unit testing
• dedicated product teams who handle feature requirements and documentation
• dedicated UX team to produce designs for FE engineers to implement

So our devs only need to worry about development, but they also need a broad skillset in that domain, from everything from local tooling to working in different domains. We hire a diverse set of candidates, some with a heavy math background, some with design experience, and some with low level programming experience, because we never know what projects we'll get or who will suddenly leave the org.

That and also - humans not knowing something can man up and learn it. When they need, they'll learn.

And OP's question about European clouds - it depends really. A lot of what this endeavor needs is just advanced use of OpenStack. I'm confident there are plenty of people with such skills in the EU countries.

As for the post content - I dunno, my experience with Kubernetes consists of using it, but not trying to understand or touch it too closely, because it stinks. Maybe those engineers were like that too.