Yeah definitely. I have terrible memory and would probably do badly at this even though I'm a very competent programmer (and modest!). And similarly I have interviewed some people who could talk the talk but literally couldn't write a for loop.

I think we also need to shift our vocabulary around "leetcode interviews" because there are two very different things that that word is used for, and I think one is fine and the other is not, but because we use the same word for both people end up talking past each other. Basically there is:

1. Fizzbuzz-level (and a little bit higher) programming problems where there's no real puzzle solving, it's just checking that you can literally code at all.

2. Hard puzzle-style algorithmic leetcode questions. The stuff on leetcode.com. For some reason like 80% of this is dynamic programming questions.

I think fizzbuzz level questions are fine and necessary (yeah I wouldn't have believed it either but there's no way I'm hiring someone who can't write a simple for loop).

At the other end hard leetcode questions are not very good - they are often so hard (in an interview context) that they just select for people who have seen them before (e.g. if you grind the top 100 leetcode.com questions), or have had a lot of recent practice (especially of dynamic programming, which is crazy because I've never used dynamic programming once in my life despite doing a very algorithm-heavy job for a few years).

Even worse they often are selected because the interviewer read the solution, thought "ah yes that solution looks easy" and then it makes them feel good about knowing the solution - they don't even realise how hard it actually is.

So, hard leet-code questions should be avoided, but that doesn't mean you should have no whiteboard coding questions.