Sorry, but this just sounds very easy to bullshit. Unless you're doing real in depth quizzing of stuff people wouldn't know if they didn't work with it (e.g. in HFT, explaining what a potential implementation of std::string could be and what the tradeoffs of each design choice would be), generic backend principles are very easy to spew correct answers for without actually knowing how to code. How are you going to filter out people that just memorize the concepts for their chosen language and are good at talking but can't code for their life?
> generic backend principles are very easy to spew correct answers for without actually knowing how to code
I'm not sure I agree with this. IMO trying to get someone to explain the ins and outs of a particular facet of the technology your team works in is less effective than getting a sense of how a candidate architects their code and manages complexity. That type of "art more than a science" craftsmanship is not something you can easily fake in my experience. Maybe I'll be proven wrong. We shall see. So far I've had pretty good luck with the approach and gotten some really great teammates.
It's almost always obvious whether the candidate really knows their stuff. They go into details, when you ask probing questions they don't revert back to generalities or repeat what they already said.
Where this does not work, however, is interviewing junior developers. They don't really know anything at all yet (well, some do, but again, that's almost always quickly obvious), so you're hiring for potential rather than actual skills.
Yeah you have to use the appropriate strategy for the interviewee. In the case of a junior, you are looking for potential and teachability as you said. You tailor your questions towards that angle. I've yet to see any take home or live coding challenge that answered those type of questions for me. All it told me is what I already knew: they were more junior and needed mentoring.
