Technology

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

I totally agree with you, but I don't think this is the specific case. Most of the rejections in our case (which I can see) on the preliminary screening were based on lacking CV skills. Which is stupid in its own way, but at least makes sense assuming we are looking for those skills specifically.

For the rest, the company is a remote company paying good salaries for the European market, I would say slightly above market average in many metrics.

I will sift more into the rejections, but from what I have seen, almost all those who had the screening phone call made it to the interview (I.e., rejections were mostly cv-based).

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.

now it takes 6 rounds of interviews for an entry level position at a startup.

I think it was 1996 vs 2002... 1996 we advertised in the Miami Herald for an engineer and got about a dozen applicants, 3 worth interviewing, none worth hiring and had to continue to search through personal networking to fill the role. 2002 we placed a nearly identical ad in the same classified section of the same paper, but by this time the Miami Herald was "online." We even added the line "only local candidates will be considered." Within the first week I had over 300 resumes on my desk, half of them from far afield - even overseas, so they were easy to sort... Still, plowing through the remainder, after about 50 quick scans I found one former employee of a company we did regular business with for over a decade, the question to his ex-manager was "if you had the chance, would you rehire him?" That yes shot down the rest of the applications dead - we just didn't have the resources to even read all the applications, much less sort or answer or interview them.

I can only imagine the flood of candidates applying for every opening today. Take your resume, e-mail it to 30 recruiters, they each apply to 30 positions for you...

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.

Ahaha yes, that might be the case, but I started to lose hope if the top of the applicants (out of hundreds of rejected!) all exhibits this behavior. I can't help but feel that now we are looking for people with a mindset and skillset that is simply disappearing in the industry.

And as I said in another post, I perfectly acknowledge that if I stopped reading and investigating stuff on my own, I could absolutely keep my job by just mindlessly administering a few services and rephrasing CIS benchmarks...

Ours is really simple, like something any somewhat competent engineer could complete in half the time we provide after going through the tutorial on the framework's website. Yet so many people fail, even when they claim to have years of experience with the framework.

There are a ton of terrible applicants out there.

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.

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.

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.

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.

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

Exactly. We don't hire "junior" positions, because all the midlevels are juniors, all seniors are mid-level, and seniors don't apply. I'm a senior and a recruiter found me, I didn't apply (at least not to this company).

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.

Juat as a reality check:
What you and me consider fun isnt fun for most outside of the lemmy techie bubble.

This hits the nail right on the head. The point of cloud services is to take away all the overheads of building and delivering software solutions that have nothing to do with the actual business problem I'm trying to solve.

If I want to get a new product to market, I want to spend most of my time making my core product better, more marketable, more efficient. I don't want to divert time and resources to just keep the lights on, like having to hire a whole bunch of people whose only jobs is to provision and manage servers and IT infrastructure (or nurse a Kubernetes cluster for that matter). Managing Kubernetes or physical tin servers is not what my business is about. All this tech infrastructure is a means to an end, not the end itself.

That's why cloud services is such a cost efficient proposition for 98% businesses. Hell, if I could run everything using a serverless model (not always possible or cost effective) I'd do it gladly.

Not when the skillset is essentially outsourced and you are left consuming the product of that skillset.

Understanding is nonnegotiable in security, IMHO.

You can't fail to understand how signature attestation works, if you are implementing it, to make one example I made in the post. Otherwise you end up verifying the signature in the CI (like that person claimed it should be done) and waste the whole effort. You can definitely still outsource the whole infra and scripting to Github, but you still need to understand. The problem is that when you can outsource everything, at some point understanding becomes an extra step.

That's the thing! I think it wouldn't be conceivable that your "principal engineer" (real position for one of the people) doesn't understand the basic theory of the stuff they are implementing. Now it feels you can instead work years and years just shuffling configuration and pressing buttons, leading to "senior" people who didn't gather actual years of experience.

I don't want to pretend I am outside this logic. I am very much part of this problem myself, having started my career 10 years ago. I do despise cloud services though (if anything, they are super boring), so I tend to work with other stuff. But I could 100% just click buttons and parrot standard and keep accruing empty years of experience...