What the interviewer is actually measuring

Candidates believe they are being scored on whether the code runs. They are not, or not mainly.

Four things are being assessed, and only one of them is the answer.

Can you understand a problem before solving it? Most failures happen in the first two minutes, when a candidate starts typing on an assumption nobody confirmed. Repeat the problem back in your own words. Ask about the edge cases: empty input, duplicates, negative numbers, size of the data. This is not stalling. It is the single strongest signal available, because it is what the job is.

Can you think out loud? Silence is unreadable. An interviewer cannot distinguish deep thought from being stuck. Say what you are considering and why you are rejecting it. A candidate who says "a nested loop works but that is quadratic, let me see whether a hash map helps" has already demonstrated most of what is being measured.

Can you take a hint? Hints are offered on purpose. Ignoring one, or defending a bad approach, reads worse than being stuck. Say "that is a better idea" and change direction.

Can you write code someone else can maintain? Real names, small functions, no cleverness for its own sake.

Notice that none of these is memorising solutions. A candidate who has memorised two hundred problems and cannot explain their reasoning is easy to spot and routinely rejected.