Have a chat, discuss experience and see how well they actually understand the things they have put on their resume. Dig as deep as you can and see if they actually understand what they say they have done. Also, references are at least as important as the interview.
In either case, there are questions that have multiple difficulties of responses. The more experienced/capable they are, the more nuanced and complete their answers will be. For example, ask a Java person how GC actually works. Most people have very little idea, but the best talent knows a good bit more.
But there are other variables. I've known perfectly intelligent and productive coders who took months to build a really complex well architected system that didn't solve the business problem and hence were a bad hire.
That's an interesting statement. Isn't it usually the job of product managers (or someone in management) to determine whether or not what's being done is actually wanted? It is not typical for developers to be brought on under the broad banner of "make us money please" and then set loose to email users and determine 100% of their own direction. Wouldn't the fact that the wrong program was being built have been caught in an informal "let me see how it's going" sort of status update?
The fact that a person with years of experience solves an interview question more slowly than a fresh out of college grad should be a huge red flag that our interview questions are bullshit and don't reflect real world challenges.