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.
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.