4 ms·

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/whatev

by dotBen 4y ago

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.

BlargMcLarg 4y ago
>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.
- scarface74 4y ago
  The .Net and Java ecosystems haven’t changed that much in the past decade. On the front end, it seems to have calmed down.
  - DeathArrow 4y ago
    .NET changed quite a lot.
    - scarface74 4y ago
      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.
      - DeathArrow 4y ago
        Then there's Blazor, there's MAUI, there are changes in C# itself and lots of new libraries.
        scarface74 4y ago
        Changing - do I have to learn something new to do the same thing today as I did yesterday - is different than adding new capabilities.
cagey 4y ago
Reading this > 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.
- scarface74 4y ago
  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.
fn-mote 4y ago
> 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.
- DeathArrow 4y ago
  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.
DeathArrow 4y ago
>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.
ZephyrBlu 4y ago
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.

by dotBen 4y ago

BlargMcLarg 4y ago

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

scarface74 4y ago
The .Net and Java ecosystems haven’t changed that much in the past decade. On the front end, it seems to have calmed down.
- DeathArrow 4y ago
  .NET changed quite a lot.
  - scarface74 4y ago
    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.
    - DeathArrow 4y ago
      Then there's Blazor, there's MAUI, there are changes in C# itself and lots of new libraries.
      - scarface74 4y ago
        Changing - do I have to learn something new to do the same thing today as I did yesterday - is different than adding new capabilities.

cagey 4y ago

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

scarface74 4y ago
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.

fn-mote 4y ago

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

DeathArrow 4y ago
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.

DeathArrow 4y ago

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

ZephyrBlu 4y ago

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.