As a developer I am tired of seeing technical-tests where I had to find the ships in an M x N array for jobs where later you will have to build an API with CRUD's for different entities: no relationship between technical-test and the real final position.
For me, the main problem with interviews is that they are focused in "do you know how to solve this in-an-academical-way?" but later you won't have the same kind of problems in the real life, where you probably were more focused on architectural problems, or refactoring problems, or more high-level issues.
Most of the time the final algorithm is not the key and, more or less, anyone is able to solve the way for doing something at low-level (if/foreach/while/... there are few control structures) but not all the people is able TO THINK PREVIOUSLY about the problem itself and the best way for solving it, so I think the technical tests should be more focused on the way a candidate could face to problems instead of "this guy has forgot finishing the line with ';'"
When I had to hire engineers I focused on abstract concepts like "this person could face any problem and solve it", "this person could learn about our business in not so much time", "this person es naturally curious", "this person knows how to approach to the problem" or "this person has different ways for trying to solve problems" instead of "this person could solve NOW the problems we have", so I think you have to lead the conversation with the candidate to be able to answer this concepts and not to try to know if the candidate could write code fluently (if it's senior I assume he could), but the abstract concepts I have told could be potentially candidate weakness if he/she doesn't have it.