Personally, I've done interviews where I ask a few toy algo questions of increasing difficulty, in a language of their choice. The first question is trivial and

Personally, I've done interviews where I ask a few toy algo questions of increasing difficulty, in a language of their choice. The first question is trivial and screens out candidates who can't code at all. The more difficult questions are more to see if they can communicate clearly about code, and performance / complexity issues, and how they respond to questions and feedback on their code. I don't care that much whether they can solve questions 2 and 3 perfectly, but they should be able to come up with something. If they pass that I would devise a longer interview suited to their CV. I expect a senior to be able to answer architectural questions and / or talk intelligently about architectural decisions they've made on past projects. If they claim experience in a job-relevant domain I would ask domain-specific questions, if not, the expectation would be that they would ramp up, and I would stick to more general questions. So the point is to avoid wasting time preparing and doing longer interviews for candidates who can't even calculate the average value of an array (or worse, hiring them), and get a bit of an idea of their ability to think and communicate about code. I'm honestly not very confident this is a good approach but that's why I did it.