Technology

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

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.