> my interview attitude is that I'm there to find out what you can do, not to find out what you can't,

Have you ever considered trying to find out and confirm what the candidate has done in the past, instead of the almost impossible task of finding out what they "can do" in a few short hours? Barring some major new life issue, a developer's past performance is highly predictive of their future performance.

Edit: Removed longish rant.

If I can, yes. But many interviewees are not prepared for that, and I've had to adapt to that.

If you are interviewing, please by all means bring samples of your work and be ready to discuss them, if you possibly can. But some people come from places where they can't talk about what they did (like, literally, Federal law in some cases), or for some other good reason can't really substantiate what they did.

You also have to account for the fact that a lot of the ways of finding out what they did in the past are somewhat unreliable. Many past employers have their own reasons for not being forthcoming or entirely truthful. The interviewee is incentivized to exaggerate their claims. In this context it's hard to get very much solid information of the type you're asking for.

My preference is to see past accomplishments, then use the interview to substantiate that they are indeed your accomplishments and you were not just generally in the area of accomplishments that happened to be occurring. But alas, that's not always an option.

That's what interviews for hardware engineers are like. I'm an embedded systems engineer, and as such about half my work is programming. I've only worked for companies that are primarily electronics manufacturers. I've hesitated to apply to companies that are more software focused largely because of my perception of their interview process.

Interviews for electronic engineers consist mostly of talking about projects the candidate has worked on (for young people these might be college and hobby projects). The interviewer's questions are things like "what did you consider the most difficult part of that project?" or "What tools did you use for that?" or "why did you do it that way and not this other way?" No one has ever asked me to design something on a whiteboard, nor would they dream of asking me to rattle off the pinout of some random microprocessor.

The software company interviews I hear about sound more like someone being tested to prove they aren't lying about their qualifications than like adults discussing a business deal.

What about developers with little experience, that come right out of school, or are applying for an internship position? Are you going to cut them out of the process? If so, are you okay with the fact that you'll often be missing out on getting an early lead on good junior developers? Good developers rarely kick around on the job market, and so it's often much more difficult to hire them when they've become more senior. Joel Spolsky's take:

http://www.joelonsoftware.com/articles/FindingGreatDeveloper...

I'm not suggesting to do this exclusively. By all means, hire promising devs out of college using the method the GP prefers.

I'm just suggesting that when an applicant like this exists before you, it makes more sense (assuming you're happy with their accomplishments) to confirm that these are indeed their accomplishments than to try to cram in some ad hoc heuristic for determining their range of skills in an hour or two.

And if my peers are any indication, the reason it's become so hard to hire senior devs is that no one wants to go through the headache of the interview process anymore once you've reached a moderately satisfactory job situation.

When I used to hire people, I focused more on their intelligence, their focus, and their motivation. Any idiot can google snippets of code or memorize answers to questions. What I wanted was someone that could handle learning what they don't know, motivate themselves to get the job done, and most of all, get the job done.

And you can't figure those things out just by looking at a resume or by quizzing them for hours until they break. You have to actually talk with them. Engage them in conversation. Learn who they are and how they fit into this field. Learn about their past experiences and their future goals. Then the question as to whether or not to hire them is easy.

Resumes are a starting point. Previous knowledge is a time-saver. Problem-solving and motivation is where its at.

*As a side note, most of my interviews were 30 minutes or less. I only regretted one hire, and I got rid of him pretty quickly.

Well if you want to be an innovator in that space, then you can offer an interview process that is more friendly to them.

That means, no onsite interview processes that require taking vacation days to complete mostly. Or off hours interview processes.

Talk to them about school projects or classes. I recall one candidate was in a compiler class, and told me about the compiler s/he had working. I asked 'what's a recursive descent parser'. They didn't recognize the term. I asked what grammar the language had. They didn't know. Other's show excitement, talk about having had to study things on their own because it wasn't covered in class but they really wanted to learn it, and so on. You quickly get a sense of who has a fire burning and who is going through the motions.