I've had to do a lot of telephone interviews and then face to face interviews. I'm regularly surprised how many developers can't do basic stuff. I'm not talking

I've had to do a lot of telephone interviews and then face to face interviews. I'm regularly surprised how many developers can't do basic stuff. I'm not talking code that requires specific knowledge of an obscure area of an API or language, but things like picking the smallest values from an array (without using a language's built in array min function). At my current company we get them to write code (or something like pseudo code) down on paper. We give them a print out that clearly explains the task, which requires no domain knowledge and then leave them to it for an amount of time to write stuff down on paper. We then go back in the room and get them to talk us through their solution. But so many developers just can't do this. Then some can, and they can't explain the edge cases, what if the array is empty? What if it's null? What if it's all the same value? They'll just freeze. They would have past the phone screen first to get this far. We're not looking for more advanced stuff with red–black trees or an exotic data structure. Just a demonstration of what you've written and simple understanding. In reality, this is an invitation to a conversation. Why did you do it that way? Is there another way to do it? Which way do you prefer? Why? All if this is basic first principle stuff. Generally when you get to the good candidates you know. They can answer all these questions and you go in different directions with the questions, they're comfortable doing it too. You can get a technical conversation going. They won't lie and I say they can do X, the good candidates will quickly admit they haven't done X or Y, but their overall impression means not knowing X doesn't matter. The trouble is I've had so many candidates who are on the wrong end of the Dunning–Kruger effect. [Minor grammar edits]