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.

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'm here from /all so I can confirm this is happening in non-tech too. Not too long ago, I interviewed to be a product photographer for an industrial manufacturer, and the people who were interviewing me knew nothing about the job I was interviewing for.

They couldn't tell me what camera they used in house, they couldn't tell me what editing software they used, they couldn't tell me about the lights, they couldn't tell me anything. It's like if the interviewers said you'd use 'computers' but couldn't tell you which OS they were running.

Isn't the solution to train people to get past HR? I know it would infuriate me to have to do this but HR needs to be treated as an obstacle. Remember when personality tests first started appearing. There were people teaching how to give the answers HR wanted.

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.

A lot of this has to do with recruiters. I've been interviewing for a few years at my company such with as many different sets of recruiters, from recruiting firms to our corporate recruiters, to ones we hired ourselves. Our corporate recruiters handed over garbage candidates who we could often tell wouldn't work out after the first 10 min of the interview, whereas the other two groups of recruiters would do a good job filtering so we'd get than a 50% hit rate on our first round. Unfortunately, we promoted our recruiters once the need for talent dropped (or they moved on to a recruiter firm), and now they're unwilling to go back to recruiting.

The quality of your recruiter matters quite a bit, so you'll want to find someone who is experienced hiring a certain type of person so they know what to look for.

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.

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 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.

My take on how a decade (or more) of using cloud services for everything has seemingly deskilled the workforce.

Just recently I found myself interviewing senior security engineers just to realize that in many cases they had absolutely no idea about how the stuff they supposedly worked with, actually worked.

This all made me wonder, is it possible that over-reliance on cloud services for everything has massively deskilled the engineering workforce? And if it is so, who is going to be the European clouds, so necessary for EU's digital sovereignty?

I did not copy-paste the post in here because of the different writing style, but I get no benefit whatsoever from website visits.

Using Clouds for too long might have made you incompetent | Loudwhisper

(loudwhisper.me)

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.

You were at screening level #1. When I applied for work in Manhattan in 1988 it was like that: 9/10 jobs you applied to weren't the actual employer, they were agents building a pool of candidates to be able to present to the actual employers at a moment's notice if the employer should ever actually call asking for candidates.

Today I bet it's rare to get hired without at least 3 screenings before you actually meet the people you might be working with.

That has been my experience with security people, too. They are button pushers and copy pasters. But I don't think it's cloud computing causing it. They were like that before clouds.

My take on how a decade (or more) of using cloud services for everything has seemingly deskilled the workforce.

Just recently I found myself interviewing senior security engineers just to realize that in many cases they had absolutely no idea about how the stuff they supposedly worked with, actually worked.

This all made me wonder, is it possible that over-reliance on cloud services for everything has massively deskilled the engineering workforce? And if it is so, who is going to be the European clouds, so necessary for EU's digital sovereignty?

I did not copy-paste the post in here because of the different writing style, but I get no benefit whatsoever from website visits.

Using Clouds for too long might have made you incompetent | Loudwhisper

(loudwhisper.me)

Nah brah, knah waddahma? Running my own Nextcloud instance is basically what drove me to become a linux novice.

I used to be a windows gamer. Now I run my own home-LLM server for the self hosted cloud assistant.

People should try, it's fun!

Maybe, but that doesn't quite track with what I experienced. It was for a fairly well known company that builds industrial tools and machines, and I interviewed at their HQ, so I don't think it was an agency building a pool.

The screening part sounds right, but I think these guys were doing it in-house.

My take on how a decade (or more) of using cloud services for everything has seemingly deskilled the workforce.

Just recently I found myself interviewing senior security engineers just to realize that in many cases they had absolutely no idea about how the stuff they supposedly worked with, actually worked.

This all made me wonder, is it possible that over-reliance on cloud services for everything has massively deskilled the engineering workforce? And if it is so, who is going to be the European clouds, so necessary for EU's digital sovereignty?

I did not copy-paste the post in here because of the different writing style, but I get no benefit whatsoever from website visits.

Using Clouds for too long might have made you incompetent | Loudwhisper

(loudwhisper.me)