That said, yeah, I think this might be better, because what we currently have is really bad. Recruiters scan resumes for buzzwords. Candidates are contacted and asked to code fizbuzz, or are given 10 java questions. If it's clear they're not a total waste of time, they're brought in for several hours at the whiteboard. They might be asked data structures and algorithms questions (the kind you get from the back of a 2nd year CS textbook), otherwise they might be quizzed on the intricacies of a programming language. If they pass the exam, the process may move toward "culture fit", more soft interviews with various managers and directors. Other variants on this involve homework assignments that can take the candidate a full work day (but reduce the amount of time a company has to spend interviewing them).
All in all, I'd rather spend a couple days building a fun app than spending a day reviewing my old data structures and algorithms textbook and reading up on ruby syntax to make sure people believe that I've actually be using it as a programming language for the past few years, followed by a couple of days of technical grilling.
I don't think hiring is an easy problem to solve. It's very difficult to evaluate programming talent, even if you're a programmer. None of this would be objectionable to me if employers weren't so adamant that there is a shortage of programmers (the bit about paypal was particularly hard to take - at one point, we're hearing about how desperate silicon valley companies are for programmers, next, we hear that a programmer was rejected from Paypal because he used the word "hoops").
Post your jobs to the typical sites. Manage the resumes yourself (for the position you're hiring).
People say hiring is one of the most important things you do, then they turn it over to the car salesmen of the IT industry and can't figure out why they're getting shitty results.
How this is so hard for companies/people is beyond me.
But after that? If an employer is still doing fizz buzz, adding branches to binary trees, seeing if they can write an outer join, quizzing them about ruby syntax - the approach is still pretty bad. Just not quite as bad as when they start with a recruiter.
My goal is to never do another technical interview again. The way I'm trying to do this is by expanding my contacts - and I don't mean exchanging business cards, I mean open source projects where I work technically with a large and wide spread group of people in a number of different organizations. People think you need to be some "rock star" to do this, but really, you don't. Keep in mind, it doesn't need to be the equivalent of being a major contributor to rails or the apache server. They can be business apps with a smaller install base and maybe a dozen or so developers. The key is, at any given moment, there are several dozen developers at perhaps 6-12 organizations that wouldn't need to ask you about binary tree traversal because they have already worked extensively with you. You've done presentations and code reviews, you've made contributions to the code base, you've fixed bugs. If they had a question about certain tech issues, they'd probably call or email you.
Unfortunately, this still describes a relatively small number of jobs. Most orgs aren't willing to make their own code base open source (reducing hiring opportunities for developers), and almost by definition most people doing this already have jobs (reducing hiring opportunities for employers_s who want to get away from the unpleasantness of the hiring process. Get involved in meaningful open source projects, and develop a good reputation for your work. Blog about your technical breakthroughs. See if you can speak at conferences.
I also would say that this isn't at all easy, and that people with this sort of ability are likely to find other opportunities outside software development with better pay and greater career prospects.
I found simply talking to people about development gave me more than enough to know whether they could develop or not. It's hard to fake out someone else that's knowledgeable. Now when you have managers who haven't been engineers doing the interviewing, they have to focus on other shit because they have no idea how to differentiate. I've dealt with that so much in my career I've pretty much given up.
Demanding applicants to spend a lot of time only works on recent grads, or unemployed and desperate.
I'm starting to use it as an anti-filter. If a job prospect demands me to invest time before an interview, I just pass.
Who are you that I should waste 5-10 hours on your interview project, before I even meet you?
I can't see Doctors lowering themselves to participate in this charade, but clearly, programmers should expect less.