4 ms·
i think on paper everyone will agree with you. i've hired for [insert specific language] and struggled with the same contradiction. the hard part is there is n
by catshirt 10y ago
i think on paper everyone will agree with you. i've hired for [insert specific language] and struggled with the same contradiction.
the hard part is there is no obvious cost/reward outcome. the ideal scenario is hiring someone with the relevant knowledge immediately. so you shoot for that. a month in you're saying "we're close now, though...". when do you cut your losses?
hiring someone who doesn't know your stack comes with some extra risk, and compared to alternatives, seems like settling.
- flukus 10y ago> hiring someone who doesn't know your stack comes with some extra risk, and compared to alternatives, seems like settling. Is that risk significant in the grand scheme of things? Especially considering how many have used a particular stack incorrectly for years. I have an MVC project around here that is very much a webforms project in MVC clothing.
- catshirt 10y agodepends on the project. and your hiring timeline. and a lot of other things... i mostly agree with you. i did try to soften it by saying "some" extra risk. as in, the net risk is > 0.
- JustSomeNobody 10y ago> hiring someone who doesn't know your stack comes with some extra risk... Have you considered you may be waiting too long to hire.
- catshirt 10y agoyes, that's half my point. :)
- pmiller2 10y agoIf a position goes unfilled for months, are there really any alternatives?
- catshirt 10y ago1. if you've let it go on for months you can probably afford to wait A Little Longer. 2. because everything is relative i take "for months" to mean "for a dangerously long time". and this is what i mean by cutting your losses: it's hard to know in the moment when to fall on plan b. everyone agrees they could train any decent programmer- no one really does it. i'm not trying to defend any practice, just trying to reconcile the contradiction.
- collyw 10y agoGive me an experienced programmer who doesn't know the stack over a junior who does any day. Knowing the stack is often syntax related and doesn't take long to learn. Knowing best practices does take longer to learn, but its easy to point experienced people in the right direction. Knowing how to write elegant solutions and how to do high level architecture takes longer still, thats where experience comes in.
- deleted 10y ago[deleted]