If it makes you feel better bad programmers exist in pretty much every country. How to weed them out is the problem.
First weeding is the resume. One thing I look for is a lot of claimed language experience and nothing to describe what they did in that language. I've seen resumes that pretty much claim they know every language ever invented and yet their experience shows they've only actually worked with Access and Visual Basic. Those go right in the trash. 10 page resumes go right in the trash (especially ten page resumes from people with less than 2 years of experience which I have gotten). From recent college grads with little experiece, you have to be really picky about how they present themselves. The best candiates are careful with their resumes, they don't have errors. Are you really looking for someone who cares so little he didn't bother to proofread his resume?
Professionally prepared resumes go in the trash too. Once you've read hundreds of resumes, you can pick them out as they use the exact same phrasing. You can't trust the content in a professionally-prepared resume and you know the person didn't do his own prep. This is the kind of person who will rely on others to solve his problems for him, do you really want that in a programming position?
Look for things that make the person stand out for the ones you pick. That's harder of course with the ones just out of school, but look for accomplishments, contributions to open source, etc.
The next weed out is the phone interview. Ask about basic concepts that relate to the actual job you have. If people don't have basic knowledge of concepts you need them to have, they aren't worth bothering to bring in to a personal interview. The young often think this is unfair becasue they can look up everything on the Internet, but the truth is I have never met a good programmer who had to look up everything on the Internet. You should have some knowledge of your profession that you don't have to look up each time.
After the phone interview you should pick the best 4-5 candidates and interview. Of course if you only have 1-2 good candidates, don't bother interviewing people you already eliminated. Now you are going to ask the hard questions and get a feel for how they approach problems. I would never use the fizzbuzz test because it is too well known so the answers tell you nothing. Instead make up some problems from your own code base. I might give them a requirement and a piece of code and ask them if the code meets the requirement and if not why not and what they might to do make it meet the requirement. I would ask them to describe the most difficult programming problem they have had to solve and what steps they took to find the answer. I would ask some more in-depth technical questions. Remember you are trying to get a feel for their technical competence, their problems solving and debugging ability and their ability to fit with your existing team. I also ask questions that they probaly don't know the answer to to judge how well they handle stress, it's a stressful job, I don't want someone who folds in the interview because the stress of the job is greater than the interview stress. I look for strengths in areas we are currently weak in and ability to work in teams and to present themselves to the customers (our devs deal extensively with users), your list may be different.