At my employer, we deliberately have a junior person interview senior candidates. It helps us understand how stuck the candidate is about their seniority, whether they can explain something to an interviewer who clearly doesn't have the same exposure as the candidate.
This could be fun but there are just too many reasons not to do it.
One is that you need to understand the technical questions perfectly so that you can ask deep probing questions, spot when candidate tries to wing it, etc. All the while evaluating various aspects of the answers and trying to figure out if you are getting all different aspects you need.
After all, the best way too interview is to have a discussion with the candidate. If you just have a list of closed questions you could give him a test to fill out.
You also need to be quite self aware of your own limitations and be able to distinguish between objective and your own preconceptions. As an example, I may like strongly typed languages and the candidate may have other preference. You need to be able to recognize that this is only your preference and try to objectively evaluate regardless of this. Otherwise you run the risk of hiring people that are exactly like you which is interviewing mistake #1.
Often the “leetcode” interview gets tedious. Im not a demon coder, I just seek local minima and reuse things. We stand on the shoulders of giants.
Then I imagine what Aphyr would do and start giggling. It’s often downhill from there. "You have, in fact, heard this one before. In your browser, search for “fizzbuzz solution”, and pick the first link that looks promising. Copy and paste. You are a real engineer.” [1]
First, you would be surprised how many candidates can't do something like fizzbuzz correctly.
Second, if I ask you coding question I am not going after your existing knowledge but rather about how you deal with problems to which you don't know the solution for.
After all that is what development is -- building something without necessarily knowing the solution when you start.
Third, I don't care how good coder you are (well, I do a little). What I do care when I ask you coding question is that you can think logically, ask right questions, work with me to find a solution to the problem and also that you can use the tools that are at your disposal.
Development is a lot of abilities and if the only thing you know is how to write more code then that is how you are going to approach every problem. As they say, if the only thing you have is a hammer...
Most corporate software is extremely simple (or at least it should be). Writing REST API to run couple of agreed rules on objects in a database, call an external service or send a message over network is not a pinnacle of technical achievement.
Arriving at the right solution in a large and complex organization, with many forces around you, people trying to overcomplicate your solution, stakeholders trying to drive your design or speed up development because refactoring is for pussies, on the other hand, is.
Now, I interview only senior engineers and up. I expect senior engineers to be able to arrive at a workable solution in a real organization. Coding should not be something that is any kind of problem for you, it is just one of the tools you use to achieve the result.
>> What I do care when I ask you coding question is that you can think logically, ask right questions, work with me to find a solution to the problem and also that you can use the tools that are at your disposal.
Well, I can’t fault your perspective. As an interviewee I’d like to complain about interviewing fads and about silly questions with dubious rationale. But I have to agree with your premise, as an interviewer I’ve also tried to make the best of it understanding that my reasoning about such things is imperfect.
