Just because somebody had a hard time grasping Object Oriented Programming (which, really, is not as useful anymore. Plenty of brilliant developers moved past it) in school does not mean that he'd not be a good fit for a demanding company a few years later.
This is true for everybody, by the way, just because you feel like you're struggling on some concepts, don't dismiss yourselves. Try applying at some companies that might be 'out of your league' and you will realize that maybe some of them actually aren't that out there after all.
There's no sure-fire way to know exactly who you're hiring unless you know the person (and even then!).
But: many of these companies are using the wrong criteria, out of bad habit or sheer laziness. You get "brain teaser" questions ("how would you tell which light bulb had been on in the past 10 minutes?"), coding tests, even demands to know which lsof flag does foobar (but that's why God invented man pages!). In my estimation, the only real way to get inside someone's head is to get them talking about what they've worked on, hear their war stories, and talk in depth about how they've solved problems and built things.
Or maybe he works on making a set of algorithms 5% faster.
Making a sorting algorithm just 1% faster for the most used cases will probably save a company like Google vast amounts of electricity.
I guess there are plenty people who understand both algorithms and programming language features well. But if you want someone who is awesome in algorithms you might not care if they couldn't grasp the simplest programming language feature like a for-each loop, or a static variable.
They couldn't complete a single practical lab exercise without help from peers or lecturers throughout the entire time I knew them.
They didn't make it past their trial period.
It makes me wonder whether these hiring processes are built for people leaving university, and not necessarily for those that have spent a number of years as software developers. It's a good way to get those that "know" their theory, but it sounds like a terrible way to hire someone who is expected to be not just a competent developer, but talented.
I dropped out of a masters degree to join a startup as a .NET developer, but kept in touch with a few guys finishing there. One of them now works for Google. He was always great in the algorithm classes, and he knew his theory reasonably well, but he'd constantly struggle with writing the code and REALLY grasping OO. I'd help him structure his Java code, and he'd help me grasp data structures.
He's been there a good four years now, so he's clearly doing something right, but I was initially shocked that he was able to get in when things like static classes confused him.