[kozhevnikov]

For personal projects. For engineering managers, popularity of a language or a framework is a significant consideration from resourcing perspective. It is the driving force behind many migrations off Perl, i.e. inability to hire Perl developers in sufficient quantity to continue supporting Perl-based backends.

[FpUser]

In my other life I used to manage bunch of developers while still developing myself. My criteria for hiring them generally was not their proficiency in particular tool but ability to grasp programming concepts in general and ability to grok any particular tool in short time. Practical experience in particular areas of course was a big plus.

Over the time this strategy proved beneficial. My team ended up having the highest salaries and bonuses in the company along with being given most interesting projects (developing new products from scratch as a rule).

I still went on my own after some time as I could not really tolerate that employer/employee style of interaction.

[dgudkov]

>My criteria for hiring them generally was not their proficiency in particular tool but ability to grasp programming concepts in general and ability to grok any particular tool in short time.

I'm curious how did you test candidates for this? Did you give them any specific tasks to accomplish and then evaluate their ability to learn?

[FpUser]

I asked them what did they do (projects) and how exactly and what particular parts they were responsible for. After that if I still feel interested I would proceed to delve into details like how they handled this problem/that problem/etc. Sometimes would check references. This would give pretty good picture of what the candidate is capable of. I do not remember being disappointed.