It strikes me that in the same day (albeit one filled with hiring articles) we get an article about the success of Greyston Bakery, which will literally hire anyone and train and support them as much as needed to be successful—and this, which is along similar lines but is about software development, which, obviously, requires special aptitude that not just anyone can succeed at, and must be protected from those who would trick us into getting hired. /s
Somehow, it feels warm and fuzzy to support the social justice of the little bakery that could, but when it comes to our own companies, our true colors shine.
Continue to take the systematic approach. It is still the best way. Of course, of course you should hire as effectively as possible, and try to have a baseline of aptitude, but there are always going to be outliers and bad fits. It's far more effective to optimize your system for the success of all employees than to focus on weeding out the 'bad ones.' Sure, there will be people that won't fit your system, but they made it through the hiring process for some reason—figure out their true aptitude and transfer them to something they'll be effective at.
The article may be wrong about the existence of fakes and bad programmers—anyone who has filed through a stack of resumes knows that—but it's right on the unreasonableness of the fear and the weight we give it.
I say it all the time to our CEO: if hiring is really a huge problem we want to focus on, how did we get all these great people? Hm.
The real problem is organizational. Stop worrying so much about hiring, optimize your process and be done with it, and focus on what happens afterward instead.
Much as successful security involves "defense in depth," I suspect that good HR involves much the same. It's not reasonable to build a strategy on some sort of ultimate impenetrable barrier.
Most organizations have two actual levels of membership that often exist outside of the formal rules. The reason it works this way, is to sequester the "net negative" members and protect the contribution of the "net positive" members. This must be what Valve is aiming for with it's hyper "flat" lack of structure.
It seems to be something that is clearly inevitable. We've been trying for decades to construct the perfect interview process to weed out people, and while we've had some fair success, people always manage to slip their way through.
I wonder if we spend sufficient time on the remedial end of things? Can we improve our practices for handling bad software engineers? Can they be saved? When do we get to the point where it's appropriate to cut and run?
Mostly what I look for in candidates I interview (for sysadmin/sysengineer roles) is signs of aptitude. I have a baseline knowledge I'd expect from them, but after that I'm more interested in gauging how flexible they are, and how they adapt to circumstances and change. e.g. "I see you introduced Chef to your current place to handle configuration management, why did you pick Chef vs other solutions? What did you compare it to? What hurdles did you come across implementing it?" and diving deeper and deeper in to it. The deeper you dive the more apparent it should be what kind of role they played in the whole thing and what they've learnt.
Me? I suck at whiteboard coding exercises. I'm a sysadmin, and one who does a reasonable amount of coding, but put me in a room under interview conditions and ask me to write something to solve a problem and I'll struggle. Worse it always seems like I get stuck with a developer asking me to solve some ridiculous thought exercise that bears little resemblance to anything I'd do in the real world, that I'm assuming ties in to their favourite algorithm or something.
> It is also, regretfully, not the case that all applications one receives to an advertised position of Senior Ruby on Rails Programmer would be from people who had ever opened a command line.
It always amazes me how many "Geek Squad" candidates you'll see who never even mention Linux on their resume that go and apply for Linux Sysadmin roles.