I remember well an interview with a company where I was asked a lot of questions that pertained to scaling characteristics of algorithmic solutions. For example, I was asked to describe ways to implement a solution for determining all of the words that can be composed from a given combination of numbers. (similar to how early texting was done on flip phones with numbers but no keyboard) We talked about how a conventional lookup would entail 3 possible letters per key and that the order of growth for checking words in this fashion would be 3^n. I was asked if it could be optimized, and I proposed a sorted list of number combinations in which you could do a binary search on the number sequence and get all of the possible words. I explained that this would facilitate a single lookup in logarithmic time. They asked if I had other ideas, which I didn't, and they brought up the use of a hash. I hadn't thought of it, but that also made sense, as it would result in a fixed time lookup. (Not a major improvement over logarithmic time, especially at scale, but an improvement nonetheless.) We discussed a few other things, and all in all, it felt like a very good interview in which I thought I had demonstrated good working knowledge of the concepts they were asking about - and was comfortable doing so.
Then came the second interview. They asked me to, in real time, using a shared coding system, construct a javascript program that would, given any input string, print out a list of all the possible letter permutations. (eg. "abc" would show "abc", "acb", "bac", "bca", "cab", and "cba") The challenge didn't scare me, and I had an idea of what I wanted to do algorithmically. I certainly knew it would be a recursive sequence of calls moving along the string until it was done. Using the "abc" example, you'd rotate "a", "b", "c" into the first spot, then, with each of those rotations, you'd do the same on the next digit, and repeat until getting to the last character. When you get to the last character, on each rotation, you'd have a result, which you'd store. You'd then unwind back up the chain storing the results as you went along. So it involved a recursive sequence that was rotating letters in each spot and then on the unwind aggregating the results.
I sat there, with the interviewer watching my every keystroke as I put together a first pass that didn't work. I added some diagnostic output and worked through a few things. For some reason, the interviewer, apparently thinking I was "close", jumped in with a couple of things to change, which I did, but there were still problems. After about 45 minutes, he called the interview over. Shortly afterward, I got an email from the company thanking me for taking the time, but declining any further interest.
That evening, I sat down to write the exact program they had asked for. It took me the better part of two hours, but I got it working, and working well. Having no prior experience with this problem, I wouldn't have solved it in the time they were expecting. I was going to email my solution to the company, but I figured they'd just dismiss it and assume I had cheated, or, perhaps not be interested anyway since it took me so long.
To this day, I think the company misjudged me. I'm not one to produce rapid-fire, bug-free, algorithmically magical solutions in a first pass on the spot. But I do pride myself on the quality of what I write and how well I'm able to address and understand the very problems I was being asked about in a variety of contexts.
In this scenario, I felt that "leetcode" skills and speed were given too much weight over other factors including the thought process and eventual solution. I don't disagree with the use of some "leetcode" competency tests, but I think a company should be careful not to eliminate a candidate who doesn't sling code fast enough in an interview, particularly if, through probing questions, you can establish that they have a sincere and thorough understanding of the problems at play and how to solve them with code.
My two cents.