[melbourne_mat]

In my country, last year it was definitely a candidate's market: I had recruiters reaching out all the time and I got the first job I applied for. This month I've been applying for jobs and not getting interviews.

From the conversations I've had it seems recruiters want someone who has an exact skill match for the job. They don't care what else you have done or how many years you have under your belt it's gotta be the exact list the employer wants.

I'm now optimising my resume (CV) for the job. I summarise the stuff that I think recruiters / employers don't care about.

The other thing I've noticed now is that when a recruiter reaches out quite often that role is not listed publicly anywhere. So your profile on the job systems - linkedin and elsewhere - better look real good or you won't get a call.

[ToucanLoucan]

I've helped hire three different developers where I work now, and been a part of countless interviews. I've found it much more beneficial to look for people who think like programmers than know any given language. Unless you're talking really specific, deep stuff in a given language, the syntax and whatnot are trainable. What you can't really train people to do is take a large task that we want our software to accomplish, and break that up into pieces or steps that can be built. Nor can you teach the basic pragmatic techniques that go into things like using objects and classes.

We hired on someone who had barely touched Swift as he'd been out of the iOS environment for many a year, and even before that had never done a ton of app development, but he had solid fundamentals in other languages so I went to bat for him and got him hired. Not even 4 months later he's a top contributor on our team.

[wwweston]

Spot on. Even too many developers think that their main skill is recall of language/platform/tool specific niche arcana, and while it's true that sometimes having that will reduce friction, it's rarely what actually drives things forward.

Arcana are concrete and relatively easy to test for, though, so my theory is that it's a bit like the story of looking for the keys by the lamppost because that's where the light is, even if you dropped them somewhere else.

[hoosieree]

I feel like this is a pretty common opinion among HN comments, and yet the vast majority of interviews follow the known-bad pattern instead.

Are HN commenters simply too rare to make a dent in the larger hiring landscape, or are they not walking the talk?

[ToucanLoucan]

(Didn't see this reply and it's an interesting question so excuse some necro)

For my case above, this devs experience with iOS was so minimal he didn't even have it on his resume, he listed himself solely as an Android developer (but like most places we develop for both, so it was useful experience regardless). I have a strong feeling most HN folks would absolutely interview like I do, but the problem is the interview is the last step of an otherwise highly bureaucratic process that is more or less entirely devoid of technically-minded people. Like, even the recruiter that got me my job many years ago, bless em I love where I work, but even that recruiter didn't know shit. They found me because I specialized in a lot of the things my employer was after, and that sounds alright, but that was solely based on the keywords: Swift, Objective-C, etc. A recruiter, for example, won't understand that someone fluent in Objective-C, while they're going to have an adjustment period, could probably competently write C, C#, or C++ as well with some help and training.

[tzs]

If the internet is to be believed the average software engineer changes jobs every couple of years.

If that's true it makes some sense for a company to want to only hire people whose skills exactly match the specific thing they are hiring them to work on. If they only think the new hire is not going to be around long term why put resources into teaching them new skills?

[xethos]

Oh hey, I've heard this joke before -one manager says to another "But what if they leave after we train them?"

The other manager asks back "What if we don't train them, and they stay?"

Not investing in people (and jobs) is a two-way street; there's always someone young and naive to think hard work and investment will be rewarded, and most companies have been around long enough to have set the assumption that "No it fucking doesn't".

The new guys need the most investment. Companies hiring are actively teaching them to be jaded by not investing in their employees.

[michaelbrave]

that's a chicken and egg problem. People change jobs frequently mostly due to two reasons: 1. higher pay 2. to get away from bad management or a bad work environment (same thing really)

If it's the kind of place that doesn't help train new skills, that falls under "bad management". Employees could collectively try to be the better person first in fixing this, but most modern history would show that most employers if given an inch will take a mile, and will generally pay the least amount possible, expect one-sided loyalty, and overall get away with everything they can until either regulation or market forces force them to change.

[johnnyanmac]

>it makes some sense for a company to want to only hire people whose skills exactly match the specific thing they are hiring them to work on

The good ol' "10 years of experience in Swift" approach... Though that joke is so old now that it probably is possible to legitimately have that.

That approach would make sense if the requirements seemed possible to begin with. And the salary was enough to attract that kind of niche talent. You're basically asking for a consultant for an employee's salary at that point.

[majewsky]

> The good ol' "10 years of experience in Swift" approach... Though that joke is so old now that it probably is possible to legitimately have that.

Just about. Swift was released on June 2, 2014.