I would not call adding two binary numbers algorithmic.
Having candidates write code is always a good filter. You'd be surprised by the amount of people who can't write a nested loop with a decade of experience under their belt.
Having candidates write code is always a good filter. You'd be surprised by the amount of people who can't write a nested loop with a decade of experience under their belt.
I was guilty of it too. I wasted a lot of interview time trying to spot the nonexistent gimmick when the optimal (or at least good enough) solution was in fact, utilizing a nested loop.
If you have a decade of real world experience under your belt, your first instinct would probably be to just write code that uses nested loops and perhaps refactor and optimize as necessary for performance.
But now in the leetcode interview game, you're often forced into a situation to prematurely optimize everything to get the "optimal solution" without running out of time.
For the record I always encourage candidates to start with the simplest solution and tell them we can then chat about improvements after we get the basics right.
Sounds like you're a good interviewer, and what you describe is how it should be. Even recruiting literature says that the purpose of the interview is for the interviewer and interviewee to "pair" or "partner" to solve the problem.
What usually happens more often than not though, is the interviewer is not very cooperative, and sometimes even hostile. S/he is not partner, but judge jury and executioner. So the interviewee, especially if they are new at this whole leetcode interview game, feels pressured to find the optimal solution ASAP otherwise face rejection.
And even if you tell them what you say above, they'll still feel pressured because if they "waste time" coming up with a simple, obvious, but seemingly suboptimal solution, then they feel that's less time they'll have to spend coming up with and coding the optimal solution.