>Getting to a point where this is obvious can take a significant portion of a 45 minute interview
I mean, without the project being some huge OS thing it's hard to prove contribution it in any amount of time. I don't mind some simple system design questions to sus that out (and maybe relate it to a work experience to test some validity), but instead it turns into 4 rounds of Leetcode. A waste of time and STILL not making it obvious.
At least for our group, the problem comes in the required defense of the written justification. Coding is a better consistent and objective signal, than passing a free form conversation that's completely different for every candidate. A free form conversation also makes the whole process much more susceptible to bias, which is part of the reason we're urged to have the same interview for each person.
If you have four people on the panel, and they're all trying to piece together something perceived as objective, then you could definitely end up with 4 rounds of leetcode. In our group, we have different people focus on different things, so this doesn't happen.
But, I think we're in agreement. I don't think a "conversation only" approach is good, because at the end of the day you have to make sure someone can actually code. A code only approach isn't good, because it severely limits the context that the person can show competence.
I would love to hear opinions on how I could interview better. I've never heard anyone claim that interviewing is easy, or solved, and I'm definitely not doing that here.
I mean, without the project being some huge OS thing it's hard to prove contribution it in any amount of time. I don't mind some simple system design questions to sus that out (and maybe relate it to a work experience to test some validity), but instead it turns into 4 rounds of Leetcode. A waste of time and STILL not making it obvious.