I imagine there are tons of false negatives, but it's nearly impossible for
a terrible programmer to get through a gauntlet of programming interviews.
Depends on what you mean by "terrible", I suppose. Yes, coding interviews do a good job at screening out the bozos who just can't program, period. The ones who don't understand the difference between a for loop and a while loop, or the ones who can't handle boolean logic.
But I've found that even once you get past the outright bozos, there are quite a few programmers who can program quick one-off things, but have no sense of design or maintainability. They can deliver functionality, but deliver in a way that piles on technical debt and damages the long term health of the codebase. I think the traditional technical interview format ironically encourages this sort of behavior, by encouraging applicants to focus on narrowly solving the problem at hand, as quickly as possible, both in terms of machine time and programmer time, even if that means the code is an unmaintainable mess in the long run.
Put another way, think back to the last time you had to do any sort of whiteboard coding, as part of an interview. Are you proud of the code that you wrote? Would that code pass code review at your current position? If so, then congratulations. You're a better programmer than I. The code I've written on whiteboards has been pretty uniformly terrible. Sure, it met the correct Big-O complexity requirements, and it was correct, insofar as it produced the correct output, given correct input. But there was no error handling. Variable names were single letters. The functionality wasn't broken up into logical functions because writing additional function headers takes more time, and my handwriting is messy enough when I'm not rushing. All in all, it's code that you'd see in a prototype, or a programming contest entry, not a robust system that's usable by customers.
Lately, I've seen more and more such code being produced by new graduates not only in coding interviews, but also as part of day-to-day programming. There's an incipient attitude of, "Well this code would pass in an interview, so it's production ready." I find it deeply troubling, and my concern is that programming interviews are setting up incentives by which this sort of code becomes, if not normal, then certainly more accepted than it was in the past.
This is why I advocate so heavily for take-home projects. When a candidate submits a take-home project, you can be assured that they had enough time to design and code the assignment in a maintainable way. You can see whether they added unit tests. You can see whether they split the code logically into objects and functions, or whether they smushed everything into a 500-line main(). I accept that take-home assignments aren't as scalable, either from the interviewee side or the interviewer side, but I do worry about the long term effects on norms that programming interviews are having.
EDIT: grammar