tl;dr; I only ask detailed questions about technologies of which a candidate claims recent and deep knowledge. Wrong answers suggest stupidity or dishonesty.
Let's say I'm interviewing someone who claims to have been a professional software for a decade and that most of his work was in Java. I know Java quite well, and I know what sorts of things one HAS to know about Java if he doesn't fundamentally suck as a software developer and isn't lying on his resume. If you claim to have written Java code for the past five years but can't explain the difference between a Set and a List, you are either stupid or dishonest. One of my favorite questions for a supposedly experienced Java developer is to show them a code snippet with a try/catch block and ask them to trace through the code's execution in both the case where an exception was thrown and the "happy path". Roughly 40% of the people I've interviewed who have claimed years of recent Java experience (like they were coding in Java the day before) think that a method's execution terminates when a catch block is entered and that block's code finishes executing! How could one possibly write correct code without understand this? How much evidence to the contrary must they have ignored? One developer complained to me that my question was hard because he was "mostly used to dealing with SqlException and not other exception types." He then complained that he was an experienced Java developer and didn't see how my question was relevant to the job for which he was interviewing. Want him on your team?
Here is the problem. The days of deep reading and understand and learning are behind us. IDE's really know what is good for what situation and just autocomplete whatever is appropriate. The days when you had to read the manual at every unknown point and besides text based autocompletion in Emacs/Vi no other help from IDE's are long behind us.
Most programmers todays are all about such things. In other words and putting it very directly. Productivity has become an order of an magnitude more important than knowledge and intelligence.
That is partly also because a lot of work needs to be done today than it was a decade back. And when the ecosystem grows at such a rate tools to enable the common folks program get invented.
These days its all about productivity.
EDIT : Downvote this as much as you like, but more the frameworks and more the intelligent IDE's get. Lesser and lesser significant our jobs become.
>IDE's really know what is good for what situation
>and just autocomplete whatever is appropriate.
If people claim to be doing something everyday which requires detailed knowledge of X, they ought to be able to tell me about X. An IDE can't know if a List or Set is more appropriate. To know this, it would have to know my intent. I agree that higher-level abstractions (declarative statements implying the need for one over the other, etc.) might be in our future, but the people I'm interviewing claim to be writing Java. I don't expect a Java developer to know any particular processor's instruction set, but I sure would expect, say, a person who recently wrote an x86 assembler to have detailed knowledge in this area.
The areas above and higher your IDE are/will be little to do with math and bit shifting.
They will be more and more of domain knowledge and understanding the problem on hand and little and little to do with worrying and learning arcane facts behind the scenes.
How do you figure that knowing the execution path for a basic language feature is an "arcane fact behind the scene?" This is equivalent to not knowing how an if or for statement works. You can't write ANY code without this knowledge.
How were we able to understand try/catch while all we had known is return statements from functions and error checking through flags?
How were we able to understand if/else statements now, while all we were able to understand jmp and goto statements earlier.
How can people work with Microsoft excel without actually knowing they are into databases and functional programming?
First you learn how to use a logical block of programming, then you learn many other blocks. Then you learn how to use them together. Then many interacting blocks come as a pre packaged solution to a lot of problems. Assembling those blocks comes in the forms of of IDE's. That is how we have managed to move from bits, to assembly language programming, to languages lisp, C and till now where IDE's do most of what we do.
If you had asked anybody 50 years back if we could have come this far. Their answer would be no. Same as many people today can't believe that programming can be done without actually writing code syntactically.
You can do a lot of network programming today or IO programming today without knowing anything about OS or deeper networking aspects. You could not have told the same thing 15-20 years back. The average skill required to achieve these tasks is only decreasing.
On an average scale the skills, knowledge and work required to be a good programmer over 50 years has only decreased.
In the future, the solution to a problem doesn't necessarily has to be a code.
Haven't we seen Yahoo Pipes and things like that?
I can understand this attitude that most people are showing, because it effects their bread and butter. But this is the natural progression in any discipline.
I doesn't take an army of farmers and cows to do farming today. Farming is far more productive today than it was 100 years back.
The same case will be with software. Like it or not, it is going to happen.
Let's say I'm interviewing someone who claims to have been a professional software for a decade and that most of his work was in Java. I know Java quite well, and I know what sorts of things one HAS to know about Java if he doesn't fundamentally suck as a software developer and isn't lying on his resume. If you claim to have written Java code for the past five years but can't explain the difference between a Set and a List, you are either stupid or dishonest. One of my favorite questions for a supposedly experienced Java developer is to show them a code snippet with a try/catch block and ask them to trace through the code's execution in both the case where an exception was thrown and the "happy path". Roughly 40% of the people I've interviewed who have claimed years of recent Java experience (like they were coding in Java the day before) think that a method's execution terminates when a catch block is entered and that block's code finishes executing! How could one possibly write correct code without understand this? How much evidence to the contrary must they have ignored? One developer complained to me that my question was hard because he was "mostly used to dealing with SqlException and not other exception types." He then complained that he was an experienced Java developer and didn't see how my question was relevant to the job for which he was interviewing. Want him on your team?