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.
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.
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.
When they need, they’ll learn.
100% agree. But. If you are a principal engineer claiming to have experience hardening the thing, you would expect that learning to have already happened. Also, I would be absolutely fine with “I never had a chance to dig into this specifically, I just know it at a high level” answer. Why coming up with bs?
Maybe those engineers were like that too.
I mean, we are talking about people whose whole career was around Kubernetes, so I don’t think so?
Ah. OK. Yep, people lie in their CV’s.
I like to understand what I work with, but I also like to keep my tools (like: Docker container images) as close to “stock” as possible, because that way they benefit the most from security testing and patching that others do, and make as little work for me as possible when I install upgrades.
Having said that, some tech (especially Bluetooth) is best “reinvented locally” IMO, simply because so much effort is being put into breaking Bluetooth security, and nobody really cares to break our products, but if we use Bluetooth we will be slapped with CVEs to patch constantly. So, yeah, use the Bluetooth supporting hardware, but roll your own reasonable security appropriate for your applications and get the hell out of the firehose of whack-a-mole security patches.
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.
That being said, I am genuinely frustrated by how little people know or care about the plumbing these days. :D
I am so fucking tired of seeing someone spin up 3 cloud databases for what could be a 40k in-memory hashtable.
Mind you that my take and experience is specifically in the context of security.
I struggle to make the parallel that you suggest (which might work for some areas) with a security engineer.
Say, a person learned to brainlessly parrot that pods need to have setting x or z. If they don’t understand them, they can’t offer meaningful insight in cases where that’s not possibile (which might be specific), they can’t provide a solid risk analysis etc.
What is the counterpart to this gap? Because I struggle to see it. Breadth of areas where this superficial knowledge is available is useless, IMHO.
Yeah I can see that.
However, you are now arguing a different point than I am getting from your original post. Maybe my fault in interpretation ofc, but the main difference (in my view) is:
You say “incompetent” and “less skilled” as general statements on senior engineers. Those statements are false.
You also say “missing the skills you are looking for” which is obviously true.
And the implication that before cloud, people developed the specific skills you need more naturally - because they had to. This makes sense and I believe it.
You say “incompetent” and “less skilled” as general statements on senior engineers. Those statements are false.
I am saying that the competencies of people who grew up (professionally) with outsourced services are more superficial and give them way less understanding (and agency) on the systems they oversee. I make the opinionated argument that knowing which service to use in a cloud provider is not just a different skill from implementing that functionality “manually”, but is hierarchical inferior, easier to acquire and less useful in general.
A weird parallel would be someone who hikes 100% of the time with a guide who takes care of orientation, camp setting etc., and someone who goes alone. If I am simply comparing the pictures they are showing me, I might not appreciate the difference, but if you asked me who I would trust to come hiking with me, I wouldn’t have doubt, because I consider the skill “finding, choosing and listening to the guide” to be hierarchial inferior to “orient, set camp etc. by yourself”.
So it’s not just a matter of matching the skills I need, is actually a much broader argument about deskilling engineers.
I understand.
Obviously, “knowing which cloud services to enable” is a lesser skill than knowing how those services work. That is not a parallel or equal skill in any way.
But do you assume people are just going drrrrr brain off when they don’t learn that one skillset you are accustomed to spotting?
Well, for the relatively small sample of Kubernetes experts I interviewed, basically any topic beyond “you use this tool” was a disaster, including Kubernetes knowledge. I am not selective, it’s not like I expect a specific skillset, but what would you think if someone with a decade of platform security doesn’t understand cryptography and supply chain, Linux permissions, Kubernetes foundational concepts, container isolation or networking? At some point the question is legitimate, what are you expert in? The answer I have been able to give myself so far is “stitching together services that do stuff” and “recommend what the documentation/standard recommends”. I consider myself satisfied to have somewhat decent knowledge in some of those areas, I am not expecting someone understanding all of that, but none of them? Maybe from someone who just joined the industry.
nah, I was incompetent long before cloud services.
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!
Juat as a reality check:
What you and me consider fun isnt fun for most outside of the lemmy techie bubble.
I’m not in any way, shape, or form an engineer so I don’t really understand the exact details of your post.
However, you post reminded me of a really good episode of a podcast called Hidden Brain. In it the host, discusses the topic of knowledge with a cognitive scientist.
At one point, they talk about how sophisticated technology has gotten that people don’t know how to solve problems if that technology brakes, especially since technology is getting so good that it makes fewer mistakes. They use an airplane as an example in which an experienced pilot forgot how to get out of a nosedive and crashed the plane. On a smaller scale, the host mentioned that he has a hard time navigating if his phone’s GPS doesn’t work.
Its a really interesting listen if you have the chance.
Thanks, indeed I think there are many parallels with other areas. I will check it out.
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.
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.
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.
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.
Our entry test should have been dead simple for anyone applying to the position. Position: C++ computer graphics programmer, 1-2 years experience implementing technical graphics displays in C++ language. All resumes submitted, of course, claimed this and more. All interviewees, of course, professed great confidence in their abilities. 9/10 candidates, when presented with “the test” failed spectacularly. The ones who passed, generally, did it in less than 10 minutes - with a couple of interesting quirks which revealed their attention to and/or willingness to follow directions. The failures ranged from rage-quit and stomping out without a word, to hours of pleading for more time to work on it - which, in principle, we granted freely, but after 30 minutes if they didn’t have it they never got it.
I got asked the same. I simply pointed out the test is a reproduction of last week’s bug that took down prod at 2am and got paged to fix, and is therefore as realistic as it gets of what they’ll need to be able to handle.
It’s always DNS, everyone should know that.
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.
deleted by creator
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.
Yeah, they are frequently just parroting things like CVE notices as highlighted by a fairly stupid scanning tool.
The security ecosystem has been long diluted because no one wants to doubt a “security” person and be wrong, and over time that has made a pretty soft context for people to get credibility as a security person.
