that's something i closely relate to verbal expression. the first thing you need to structure are your thoughts. so i simply ask them to describe to me a system they've previously built. if the language is clear, then so are the thoughts and so most likely will the code be.
I'm afraid that assessment of programming skills based on verbal expression makes you vulnerable to many errors and biases. Sure, you'll quickly filter out incompetent candidates but along with them you'll most likely flush out some really good ones, because programming and communication are two different competences and they doesn't have to be correlated. At least not positively ;) Plus, it's generally bad idea to assess two competences on one observed behavior. You're "saving time" on the expense of clarity and precision of judgement.
Don't worry, my recruitment interview also include algorithm and data structure quizz.
But when i do, it's in front of computer, and i'm sitting right next to the candidate while he taps, to see his line of reasoning. Then, if he's in trouble, we talk about it, i give him hints, and see if he understand what i'm saying and fix the code.
Well, it's probably not equivalent, but it's a good hint (aka : you can't express clearly something that isn't well structured in your mind).
Plus, it also let me test verbal skills themselves, which is extremely important as soon as you're working in a team.
Another way of looking at it is that "finding the right word" often means find the good "fit" between abstract concepts shapes or feelings, and a construct of known language items. That's precisely what you're doing as a developer.
Ok, so it's based on reasoning full of assumptions that may be wrong, not on empirical evidence. For me, it's quite hard to think aloud when solving some problem, because it forces me to translate what goes in my mind into words, which is quite distracting, I cannot fully immerse into the problem.
I suppose you're more a "tool" developper than a "business process automation" one.
In the latter, you very often have to talk through the problem with your customer.
But it is an assumption indeed... Only it is based on my personnal experience.
As for the comment mentionning google developpers, the ones i see are good enough verbally to talk about their jobs at google i/o.
I think that mathematicians don't do well in software development because they simply have much less experience than other devs :) I think that what's most important in software engneering is experience, motivation, intelligence, common sense and good taste (aesthetics).
Google is full of engineers that did well on programming contests, they even have their own contest, and i don't think they are all terrible software engineers.
I don't think the problems in algorithmics contests are in the category of brainteasers. As far as i know Google still relies heavily on knowledge of algorithms and problem solving capability to hire their engineers.
