Personally I don't understand how you can interview someone for a senior position without reviewing their prior work.
Or what they claim is their prior work. And it really isn't reasonable to only consider candidates with lots of code on GitHub.
I think coding problems are terrible for almost any interview because the candidate is going to be struggling to find the right answer that will please you.
To some extent that's going to be the case for any interaction during an interview. At least with a coding question there's an objective fact as to whether your solution works, as compared to trying to decide whether the interviewer wants an honest or BS answer for what your greatest weakness is.
And finally with intuition I like to throw up some source code of some problem I'm working on or interesting ones I've come across (and solved) in the past and discuss it with them. I give them an over view of the code, my expectations of it, and then ask them to read it. We walk through it and I get to see how well they can spot bugs, code smell, what they focus on when they see code.
That sounds like a fine approach, but it can suffer from the same drawbacks. For example it's very easy for a bug to be "obvious" to you and not to somebody else.
Or what they claim is their prior work. And it really isn't reasonable to only consider candidates with lots of code on GitHub.
I think coding problems are terrible for almost any interview because the candidate is going to be struggling to find the right answer that will please you.
To some extent that's going to be the case for any interaction during an interview. At least with a coding question there's an objective fact as to whether your solution works, as compared to trying to decide whether the interviewer wants an honest or BS answer for what your greatest weakness is.
And finally with intuition I like to throw up some source code of some problem I'm working on or interesting ones I've come across (and solved) in the past and discuss it with them. I give them an over view of the code, my expectations of it, and then ask them to read it. We walk through it and I get to see how well they can spot bugs, code smell, what they focus on when they see code.
That sounds like a fine approach, but it can suffer from the same drawbacks. For example it's very easy for a bug to be "obvious" to you and not to somebody else.