Thoughtful comment, but there's a practical problem with your last point: how can YOU (as a hiring manager at this "some smarter company") effectively filter through the enormous set of screened-out candidates that Google rejected and find those productive, creative misfits that you want to interview/hire out of the teeming throng of vocational misfits?
Of the people actively applying for jobs at any given point in time, the "truly excellent" are under-represented as compared to the total population of programmers.
If I were looking to hire a developer I would do the following :
1) Select a set of candidates based on their resumes making the assumption at this point that their resumes are honest. Good candidates should have at least worked on some interesting projects so their resumes should look interesting. Most lame candidates wouldn't even be able to invent a credible interesting project.
2) Do phone interviews where I would ask knowledge based (ie not problem solving based) questions related to their resumes. The goal here is mainly to filter out fake/exaggerated resumes.
3) Invite the selected candidates to give a presentation on a topic of their choice related to work they've done that is at least marginally relevant to the job. I think you can learn a lot about someone by seeing how they present their work and respond to questions (though it doesn't tell you if they're good coders, that's for the next step). The presentations could probably be done remotely.
4) Hire the selected candidates for short-term contract work. Set things up so they can work remotely. Assign them real tasks that you would expect them to perform in the job.
Make final selection based on evaluation of the candidate's work on step 4 and offer positions to the best.
You are basically filtering for presentation ability. But 3/4 of programmers are introverts, and giving presentations is simply not part of their job. You're therefore selecting for the wrong skills until the contract step.
At the contract step you create another problem. Good programmers who want to be employees probably already have jobs and are somewhat risk adverse. That kind of person won't find the option of a short-term contract with no promises at all enticing.
Remember, as bad as the economy is, the economy for programmers right now is pretty good. And as annoying as the coding interviews may be, really good candidates don't have too much trouble with them.
I think I'm kind of introverted but I can still interact with human beings. A good programmer should be able to communicate with other human beings, and a presentation (which in this case I believe is "Tell me about a project you've worked on recently?") isn't out of line at all. I talk about what I'm doing at work pretty consistently; you're basically being put in the same position during the interview you would be when having to explain your work to a CTO or someone in a similar position.
And the problem with coding interviews is that they filter out other good candidates, and I've seen plenty of companies complaining that "They can't find any qualified developers."
I would not blame the developers for this, I'd blame their selection process for focusing on things most developers don't really touch or care about when they're working on a project.
We do almost exactly this at my company and it works wonders.
Presentations are not about powerpoint. They are about geeks geeking out with other geeks. Every talented programmer I know has a pet project he'd love to talk your ear off about.
The presentations we solicit are often little more than the candidate opening up a text editor and showing off some code, and fielding tame questions from the other developers.
As for the contract position, everyone that is motivated to switch jobs, or to come work for us, can find time to do the really simple tasks we split off for $100/hr.
It is also made clear that if you've made it to the contract, we are extremely interested in hiring you, or else we wouldn't give you access to the repo or the team. The gig is to give both sides a chance to see what working on something real feels like.
We have found only excellent developers after this process. That said, it probably doesn't scale very well, and I'm sure we've unfairly weeded out many good devs.
Also, we skip a lot of the BS if there someone comes highly recommended from current employees or other partners we trust.
Being an introvert doesn't preclude one from giving a good technical presentation. It's common practice in the academic/research world which is certainly full of introverts.
The assumption I'm making here is that of hiring for someone to work on technically challenging problems (ie. machine learning, computer vision, data analytics, large-scale systems design, etc . . . - the list isn't meant to be exhaustive). For those problems you need people with strong general and/or mathematical reasoning ability. If I was looking for a very junior coder I might skip the presentation step.
At the contract step there doesn't need to be any risk for the candidate - there's no reason he would need to leave his current employer during this phase. Of course there would have to be an incentive of some kind if he was hired - better salary, more interesting work, etc.
You are basically filtering for presentation ability.
...unless you are looking to hire someone in sales or someone to represent you. :) But I agree with you.
For something like software development, I think the presentation process can be improved by talking to the candidate as part of the presentation, not just letting them starve in front of an audience. Let's not rule out the presentation mechanism; you can learn about the candidate's ability to give presentations and handle pressure.
For game development at least I've found that a 10 minute phone interview with simple 'these are things you must know or I will not hire you' questions works wonders for screening. I like to think of it as a bounding volume check for the position you're interviewing for. It's simple, and if you're not intersecting at this level there's no way you'll be intersecting at the more detailed levels.
This works because game development is relatively specialized and there actually are things that I expect anyone claiming to be a game developer to know.
Stuff like basic linear algebra (What can you use a dot product for? What can you use a cross product for?) and simple data structure do's and don'ts (What's one advantage of using an array over using a linked list?). Throwing in a few simple domain specific questions for the position their applying for works well too (I wouldn't ask a network programmer to tell me something about shaders, but I would expect a graphics programmer to be able to talk about them for a few minutes)
Some of the questions are designed so that there are lots of right answers, and some of them impress me more than others. For instance, if you mention that an array is generally more cache-friendly than a linked list and you can explain why when I ask you, you get bonus points.
If they do well on most of the questions then follow up interviews (phone or in person) are in order. Occasionally someone will nail all the questions, I tend to get excited when this happens.
Remember the goal is to find high quality candidates not shift though all of the incoming resumes. So if you have 2 open positions and 10,000 resumes just stop when you find enough high quality candidates.
I agree. Resumes are not as useful as a lot of employers want to believe. They represent what the candidate wants you to see of their history, and you get only one thing from that: Talking Points. Resumes put you both on the same page, bringing up topics the candidate is interested in talking about.
A poor salesman will have a hard time coming up with good or enough talking points. This alone is a reason resumes are mis-filtered.
I want to say that you should avoid filtering candidates based on their resumes, thanks to the holes, but that would be wrong: Sometimes, based on what they write down, you can make a reasonable judgment. For example, if you are looking for a software developer and the resume mentions NOTHING about that field, that is an easy filter.
Not quite so easy a filter: "I know C/C#/C++." but I always find that one amusing.
Of the people actively applying for jobs at any given point in time, the "truly excellent" are under-represented as compared to the total population of programmers.
I'm not a Joel fan boy, but I think http://www.joelonsoftware.com/items/2005/01/27.html states this problem more clearly than I can in a few paragraphs on HN.