Comment by auganov
3 years ago
> It's a bit like asking a carpenter how many years of experience they have with DeWalt cordless nail guns rather than ask about their house framing skills.
This kind of logic only works for tech organizations that already have enough in-house domain expertise to onboard new programmers. The other day somebody asked me how to find a programmer to implement something for them. From a programming standpoint there was very little to do, but it involved many obscure technologies that you couldn't pickup in a day (and no you can't pick different technologies). For a person who's already done something similar it'd be a quick and easy job, shouldn't cost too much. With a generic programmer it'd take much longer, cost much more and you couldn't be sure they'd actually deliver.
Finding someone "experienced with specific tool set" is also not a trivial problem.
It is even harder if you don't even know how to verify that person really is experienced with specific tool set.
So it goes like "pick your poison", hire generic dev and account for learning curve or spend money on recruiting fees/time for finding an expert. Where I would not be so quick to say "expert shouldn't cost too much" - because I can imagine expert taking less time but costing orders of magnitude more than generic dev.