But I want to say that the difference between a good programmer and a bad programmer isn't as clearcut as you might think. One programming job might call for a fast and dirty start-up prototype approach while another might call for a thoroughly documented overtested last-year's proven technology approved by a committee following the standards approach. Sometimes writing as many lines of code as fast as you can is more important and sometimes it's really thinking out and coordinating the design that's necessary. Sometimes a programmer's style doesn't fit the job style, especially if there are communication hurdles. Also, unless there are code reviews, it's hard to judge somebody else's code. If you know some approach they don't, teach them. They might return the favor some day, or they might have some hazard unknown to you they were protecting against.
If they really don't know the technology, get them a book or a url. Not knowing a particular piece of technology doesn't make one a "bad" programmer. Communicate, and find out what the block is, rather than sit in silent judgement.
Which leads me to the next point. If part of the job is documenting code, writing help screens, explaining functionality, debating design, interpreting requirements, etc in English, then a person whose English is not good will not be as good at the job no matter how much code they can spew. Some people in my office cannot make a basic business phone call, and that means they are not as valuable - for example, days have been wasted coding the wrong thing. Of course some H1Bs have excellent English and some USA citizens are impossible to understand. But coding is no longer something you can do alone in your cube all day - it takes interaction and coordination, and as long as that happens in English, some managers will justifiably prefer hiring people whose spoken and written English is effortless.