At a startup, we interviewed purely for being able to d x task in Angular, Entity Framework, MongoDB, C#, and other components of our tech stack.
It worked out well for us - we just needed a website built.
The company I work for now interviews only on the fundamentals and problem solving in language of choice - I am starting to come around and see the benefit of this, but it seems it only makes sense with senior candidates who context-switch a lot and need to intrinsically understand GraphQL the moment they hear about it because they know it's a graph.
Agreed. We gave up on technical interviews and now offer a paid project. Something in the 5-15 hour range that provides an opportunity for the candidate to show their skill in the areas that we'll actually have them working - usually something from the 'features' list. We pay a reasonable hourly rate for the work because they're worth it. And if we decide their pull request is good enough to merge, we'll send them a job offer.
It's good that you're willing to pay I don't think 5+ hours is necessary. It's perfectly possible to squeeze a realistic set of tasks in to one hour I think (it just takes a bit of work).
completely agree. It's been done to me (at Google), and I'm guilty of this myself. I tend to ask a bunch of obscure questions about topics that ultimately have nothing to do with the daily job. I gloss over the banality of what they'll actually do (push data in and out of databases.. ), in favor of javascript scope, map/reduce esoterica, C pointer arithmetic, blah blah.. shit that I know. It's kinda stupid.
They mostly don't help because they bear no resemblance to what 99% of developers actually do, even at Google.
Realism in dev job interviews is criminally underrated.