Some are good at it most are not. Bottom line if you ask 10 competent developers to build an app you will get 10 different sets of code. If you ask the same developer to write the same app 10 times you will get 10 similar sets of code.

Bottom line like many things in life this cannot easily be quantified.

There is nothing wrong with simple questions like when would you use an Interface and why?
The problem with this approach is that you will end up with booksmart developers who may not have any idea how to go about organizing a project and determining the best and most efficient way to code it. They might know how to get the job done but what about security? What about performance? Do they understand how to avoid SQL injection? Is all their code packed into one huge shambles or nicely tucked away in appropriate classes? Will they go Class mad and produce nasty code as I have run into in the past using delegates for no good reason except to show off something new they learned?

In interview situations I am a LOT more interested in talking about previous projects, (in generic terms) difficulties that emerged during the execution of the project and how those difficulties were solved. How would they go about performance tuning an application or database etc...