I have a completely different approach. I hire people who have worked with a particular technology or ecosystem for a while, because I think that builds the relevant experience and habits. If they are good at things similar to what we are doing, they should be able to pick it up and integrate quickly, and learn more stuff.
And don't underestimate the value of good documentation.
But of course, one prerequisite is absolutely necessary: the ability to approach problems logically. That is what one should look for on top of the domain knowledge.
Besides interview questions, give an interview ASSIGNMENT. Meaning, before you are hired, you have to complete some task. This shows a) commitment to wanting to work here, and b) shows that you can sole the kinds of problems we had to face before.
You know your version control, where someone had to go in and fix some bugs? Well, encapsulate these things as minimum examples (with e.g. javascript errors, maybe a stray comma or something in JSON) and then tell the guy "it doesn't work on IE, please fix it". You know it can be done because it WAS done. That's the kind of stuff they'll need to do at work.
But of course, one prerequisite is absolutely necessary: the ability to approach problems logically. That is what one should look for on top of the domain knowledge.
This is something that many people in the enterprise and in mainstream programming are incredibly in denial about. I would guess that fully half of enterprise software decisions are made on an irrational basis, or at best on stuff that amounts to no more than hearsay.
Actually, most people are partially in denial, in that they are unconsciously trained to operate on groupthink. Most companies are not startups, so they have some proven formula for making money. The best strategy in this case is to let that work and to not rock the boat. In this case, being an obedient corporate drone is desirable. In the startup case, one is actively in search of a new formula, so it is most certainly not!
>Besides interview questions, give an interview ASSIGNMENT. Meaning, before you are hired, you have to complete some task. This shows a) commitment to wanting to work here, and b) shows that you can sole the kinds of problems we had to face before.
Are you hirering for Facebook? Because if not you will miss the developers who aren't desperate to work for anyone.
And don't underestimate the value of good documentation.
But of course, one prerequisite is absolutely necessary: the ability to approach problems logically. That is what one should look for on top of the domain knowledge.
Besides interview questions, give an interview ASSIGNMENT. Meaning, before you are hired, you have to complete some task. This shows a) commitment to wanting to work here, and b) shows that you can sole the kinds of problems we had to face before.
You know your version control, where someone had to go in and fix some bugs? Well, encapsulate these things as minimum examples (with e.g. javascript errors, maybe a stray comma or something in JSON) and then tell the guy "it doesn't work on IE, please fix it". You know it can be done because it WAS done. That's the kind of stuff they'll need to do at work.