[throwaway981211]

Is this the right way to hire? Not saying it’s wrong but I’ve taken a different approach which has generally worked out.

Even if I was hiring for a specific role (front end), I care less about familiarity with specific bundlers or frameworks and something more like - “Can this person problem solve and deal with varying levels of ambiguity? Do they seem capable of figuring something out without a ton of direction?”

[mcv]

That is exactly the thing I select for. I recently had to hire 4 developers, and I was not all that interested in how many years of experience they had in javascript or typescript (our main language), and even less if you know Vue or Express (our stack). I mean, it's good to know javascript, and certainly ES6 or typescript, but I'm much more interested in: can I discuss stuff with you, do you have interesting opinions, can you make clear decisions in the face of unclear requirements, are you creative, and can you fix stuff and build features without anyone having to hold your hand? In case of doubt, knowledge of ES6 or Typescript or any relevant front-end framework (Vue, Angular or React) can make a lot of difference, but I'd rather hire someone who knows a dozen languages we don't use than someone who only knows exactly the one language we do use.

[scarface74]

And then when you need to ship now you have a bunch of dead weight while you wait for them to ramp up. Also, since now you are taking time from your devs who do know the stack to mentor your new hires and code reviews because you can’t trust them to do good work without messing up your code base. They are now doing “negative work”.

[mcv]

That's why I don't hire dead weight, or people who require handholding, but people I can trust, who can pull their own weight, and know how to learn. Someone who merely has X years in technology Y means little to me. Plenty of people manage to still be bad after years of working on the same technology.

[james_s_tayler]

But if you're in a secondary employment market as opposed to startup heavy SV you might work with this person for a very long time or have a high chance of working together in the future. So the right, right now isn't always what people are optimizing for.

[scarface74]

After spending 10 years at one company and suffering from not learning anything new but just as importantly salary compression, for the next 8 years, and 5 jobs, I learned the best way to make more money is to do Resume Driven Development and change jobs. While your market value goes up tremendously, HR departments insists on giving 3-4% raises to existing employees while being forced to bring in new employees at market rates.

This is the “secondary employment” market where HR policies aren’t optimized for in demand fields like software development. The immediate managers are usually helpless to do anything about it and see employees they spend time training leave for greener pastures. Being that is the reality, what other course is there but to find people you don’t have to train?

[bcrosby95]

Compared to what, needing to ship now and not being able to find any "qualified candidates"?

It really depends upon the exact situation. We can all make up bullshit examples to make either option look stupid.

[scarface74]

It’s “bullshit” to open req to hire a developer because you need to ship a product within the next six months and you need more bodies? Why are you hiring if you don’t need the extra people? If you didn’t need the extra people for a year until they ramp up, wouldn’t it be better just to take your time hiring until you found someone that didn’t have to spend a year learning on your dime and then leave in two years?

[mcv]

I needed extra people, but not merely warm bodies to fill a seat. I need people who don't need a year to ramp up, but can do so in a few weeks.

[jammygit]

It’s not current speed that matters but acceleration and max speed

[JMTQp8lwXL]

There is no "right way to hire". All "ways" are flawed and miss things. If hiring could've been solved by now, it would have already happened.