This is way more common than you think and it seems like it's a tragedy of the commons.
Companies struggle to hire, yet have crazy demands and interview practices that filter out good candidates with potential, because they're looking for the 'perfect candidate', whatever that means to them.
From my experience, the whole shortage in this industry is mostly companies being too picky, because they're afraid of the small chance of letting in a less ideal candidate. And I'm not even talking about unicorns/FAANGs/big-tech, but regular companies.
What is baffling? OP explains that they didn't have certain things on their CV. If I was hiring for a JS app and the applicant was all Java or .Net, it is no disrespect to them to filter them out at the CV stage.
I can only speak for myself but as a Dev of 20 years, mainly in .Net (but with Java, Obj-C, PHP and JS experience) I wouldn't dream of applying for a JS job because despite the trope, it is not easy for a Senior to switch languages and just pick it up.
> it is not easy for a Senior to switch languages and just pick it up.
This surprises me. I have 15 years of experience in the field, and it was many years ago when I got my degree in computer science. Back in the day, they thought me algorithms and what not using pseudocode (!)... nowadays I can easily pick up any tool (programming language, framework) in, I don't know, a month? Of course I won't be the best developer out there with 1 month only, but pretty much I can be productive. Sure, if one is switching from, let's say Python to Haskell, then the learning curve is higher than if you switch from Python to Ruby or JavaScript. Still, it still amazes me seeing some developers call themselves "PHP developer" or "Kubernetes architect".
Languages are easy, it’s the ecosystem, framework and best practices that take time.
Any developer can pick up Java or Swift in a month. That doesn’t mean you could turn them lose and tell them to write a mobile app by themselves or lead a project doing so in a month.
A “JavaScript developer” is useless as a front end developer if they don’t know the clusterf^# of the modern front end ecosystem
I was a “C# developer” until 2020. That implies I knew the ecosystem, frameworks, corner cases, best practices, what could go wrong at scale if you used the different frameworks incorrectly etc.
What I didn’t have to do - ever in the last 12 years of my career - is reverse a binary tree on the whiteboard while juggling bowling balls while riding a unicycle on a tightrope. I went into smaller companies and got hired based on my expertise.
Even now, I didn’t have to go through the DS&A grind to get into BigTech where I code everyday because I was able to sell myself as an “enterprise developer who knew how to lead projects and talk to customers and I specialize in architecting solutions on their cloud platform”. Does it limit my optionality? Definitely. I’ll be working on that over the next couple of years.
I'm going to rail against this. The far majority of tools are not so obscenely complex you can't learn the majority of it. The far majority of jobs are not so obscenely difficult you need the bleeding edge implementations available in those tools. Looking online, the amount of information available to do what you want is insane. There's almost always someone who has already done things, especially for technologies older than a few years.
This is even more problematic considering this selection is done on framework and library level as well, and many other tools. At the same time, making a tech stack is much like creating an ice cream cone with thousands of flavors, decorations and even cones available.
Language agnosticism and general intelligence should be applauded far more than the industry currently does. Many toolmakers are doing their best to make using their tools as seamless as possible, and they are doing a good job at it.
Sure, and if I may I'll politely rail back as a former hiring manager... :D
I have no doubt that the senior software engineer with plenty of .net/python/whatever experience could pick up the needed JS if they were given the position. But there's going to be extended ramp up time as they familiarize themselves, they won't know the libraries let alone their intricacies and idiosyncrasies etc, they won't have a lot of language specific fresh approaches and experience to inject into the team (which I'm looking for in a senior+ role). I would rather just hire someone who already has the deep bench of JS experience at the same level.
Language agnosticism and general intelligence should be applauded far more than the industry currently does.
The reason for this is because I'm not hiring for the craft of software engineering, which your perspective aligns with, I'm hiring to achieve business objectives quickly, efficiently and to a high standard. Not realizing that most hiring businesses are optimizing for the latter and not the former is what trips a lot of career software engineers up. You see yourself as a craftsperson, the employer sees you as a resource to achieve their business objectives.
>I'm hiring to achieve business objectives quickly, efficiently and to a high standard
Don't misunderstand, I do understand the point of view from hiring managers. But in the current job market, where people change jobs rapidly to actually obtain said knowledge while at the same time technology continues to change rapidly (often repeating the cycle rather than actually innovating), surely it should be evident this isn't going to be efficient if not sustainable in the long run.
If anything, you're giving people the exact arguments why we shouldn't trust companies to act for the good of the industry long term.
I’ve been actively using .Net since 2008. Sure it changes slowly with the biggest change with .Net Core and ASP.Net Core and EF Core. But it didn’t take that long to learn the differences.
>The reason for this is because I'm not hiring for the craft of software engineering, which your perspective aligns with, I'm hiring to achieve business objectives quickly, efficiently and to a high standard. Not realizing that most hiring businesses are optimizing for the latter and not the former is what trips a lot of career software engineers up. You see yourself as a craftsperson, the employer sees you as a resource to achieve their business objectives.
You put it in an interesting way. But FAANGs and big tech are businesses, too. They would want to achieve their business objectives, too. Still they hire someone who is not proficient in a particular language / framework if he is a good developer. Maybe the time it takes for them new hire to ramp up is worth.
> I would rather just hire someone who already has the deep bench of JS experience at the same level.
I love frank advertisements. Just put your real requirements up front and don't interview anybody who doesn't (claim to) fill them. Then it's fair to call bullsh*t.
No complaints about the salaries you have to offer or the thin pool of applicants, though. It's all a tradeoff.
I guess I'd like an evaluation as a hiring manager: does it work? Are you able to hire the people you want? If it's working none of this HN bellyaching matters.
That's quite correct. You want an expert in X, you should pay the high price he will ask. Unless you settle for an expert in Y and give him time to get good in X.
Generally there is an onboarding period for engineers regardless of seniority. I think this tends to be a lot longer than the time needed to pick up a new language.
There are also a lot of valuable skills that transcend writing code. I'd argue these are probably more useful in achieving business objectives quickly instead of just having another warm body to write code.
Given the above reasons, it seems odd to me that you would discount an engineer solely because they don't have experience with the stack. I guess it depends what you're looking for though. If you specifically want a JS expert who will bring best practices and new approaches to the team then it makes sense, but otherwise I don't see it.
> But ... they won't know the libraries let alone their intricacies and idiosyncrasies etc
triggered a related thought (also closely related to recent "how do you learn effectively?" and "I'm exhausted/burned out, what do I do?" HN threads):
In my most recent job-search, I found this type of expectation/requirement (specifically regarding deep (down to idiosyncratic) library (aka framework) knowledge & experience) to be the most off-putting. The likelihood that I will have used a specific library in the ecosystem your team/company has chosen in its pursuit of "teh hotness" is (to put it mildly) low, but I'm certain that my resume will be discarded, or worse, an interview process spun up but doomed because I'll be unable to regurgitate library documentation chapter and verse (much less idiosyncrasies (many of which may be version specific).
The proliferation of libraries/frameworks seems to be exponential; how would I ever acquire deep knowledge of the complete set of same that are considered "today's hotness" (both today and of the past N years) in an language ecosystem which I have extensive experience and familiarity with? My current employer/team has made its language and framework choices, and I'm bound to them for (typically) years, and I focus (for years) on being productive in that context. Am I expected (in the context of my next job) to have spent my non-working hours gaining/maintaining knowledge of both the contemporaneous competing frameworks (which current employer/team didn't choose, but came in close second, etc.) as well as each "new hotness" that comes along? The alternative appears to be that my future employment possibilities are continually being reduced/narrowed as the set of libraries/frameworks in popular use expands (exponentially) while my knowledge remains tightly focused within the domain. Even if I was willing to make an investment in self-study to learn a new library/framework well, given the above-described circumstance, what would be my criteria to make a wise choice? And if presented with the same question 6 months later, what is the likelihood I would make the same choice? I'm pretty sure the answer is not "100%".
In practice, I simply did not apply to the vast majority of job listings which I would have considered myself otherwise a good fit (i.e. could immediately grow into), due to this factor.
If my company is using a standard tech stack - React/Angular on the front end, Java/Spring or C#/.Net Core on the backend or some similar popular framework - I can throw a rock at a recruiter and they can find me plenty of “good enough” developers who can “hit the ground running” well enough to do your standard full stack CRUD app
On the hiring side, why should I invest time for you to “grow” and do negative work in the beginning just for you to leave for another job?
Yes, I realize it’s the company’s fault for not offering competitive salaries to incentivize you to stay. But often as the (hypothetical) manager, that’s out of my hands.
> I can throw a rock at a recruiter and they can find me plenty of “good enough” developers who can “hit the ground running” well enough to do your standard full stack CRUD app
But those developers might cost you quite a lot. My current employer has trouble hiring new people. Speaking with recruiters and hiring managers from a few companies (as I'm in the process of changing jobs) they told me it's hard to fill their positions.
