Comment The Answer: Learn how to hire better ones! (Score 2, Interesting) 543
The answer? Make sure you (as the senior dev/team lead) get involved in hiring, and ask people to code on a whiteboard in front of you, a simple problem like a linked list etc. This will have the mildly negative consequence of weeding out some good people who get stage-fright, but it will also weed out those who just cannot write any code at all. And the people who get stage-fright are also likely to suck in code review, where being unafraid of having your code publicly disected is a crucial skill. And people who don't get much review are unlikely to be great coders.
So ask the person to code a simple data structure/utility program whatever. Make the person take their time, comment their code, and ask them harder questions, language specific questions. So for example, I am currently coding Java, so I might ask them about a clone function for the list, synchronisation, serial form etc. For c I'd be looking to ask about pointer issues, and in particular work in a question about the difference between pointers to pointers vs multi-dimensional arrays with declared sub-array sizes.
You can't change what you have, but you can sure make sure the next set are better. For what it's worth, I don't think Brooks' law applies to this situation. Replacing someone who cannot code with someone who can will cost some time, sure, but it will also generate some code. I once heard it suggested that on any project of 10 or more people, you can sack one person and the code will be better quality and delivered faster. The longer I work, the more I believe it is true. And replacing that person with someone good is always a win.