But under moderate questioning, most interviewees don't hold up well.
For example, I once had school project where we where supposed to implement some fairly simple math function in x86 assembler. My first question in class was what instruction set could we use? (x86 Pentium I) So we can use the floating point unit? (Yep) So while everyone else was implementing floating point functions by hand I simply used the built in floating point unit. I still remember handing in 4 pages of clean code and asked why this was a major project until people started asking for more time to fix their buggy 40+ page programs even though I had told several people what I thought was an easier solution. I even told people that I finished the thing in a few hours while watching TV but they forged ahead I guess thought the sunk cost fallacy or something. I mean sure the way you do arbitrary exponentiation is a little funky, but that's better than doing it by hand.
Oven and over I see the same things. Last week someone was demoing his custom cashing solution created by hand and I was like A this does not fit our architecture and B why did you spend the time on this? Sure it's 'fun' but why bother?
At the same time in interviews I have been asked minutia about the java object system etc, and all I can think of is if this matters your doing something horribly wrong.
I understand that the interviewer probably works with them every day and has them memorized, but really that's something I could have looked up in 10 seconds. I don't think people should be penalized for following Einstein's "never memorize what you can easily look up in a book" philosophy.
422 Unprocessable Entity - The request was well-formed but was unable to be followed due to semantic errors.
"Daniel Kahneman: How cognitive illusions blind us to reason"
"Because our impressions of how well each soldier had performed were generally coherent and clear, our formal predictions were just as definite. We rarely experienced doubts or formed conflicting impressions. We were quite willing to declare: "This one will never make it," "That fellow is mediocre, but he should do OK," or "He will be a star." We felt no need to question our forecasts, moderate them, or equivocate. If challenged, however, we were prepared to admit: "But of course anything could happen."
We were willing to make that admission because, despite our definite impressions about individual candidates, we knew with certainty that our forecasts were largely useless. The evidence was overwhelming. Every few months we had a feedback session in which we learned how the cadets were doing at the officer training school and could compare our assessments against the opinions of commanders who had been monitoring them for some time. The story was always the same: our ability to predict performance at the school was negligible. Our forecasts were not much better than blind guesses."
Another recent article was about the author was discussed here:
"The King of Human Error"
Interviews are a very flawed system for identifying skill.
I always thought a great interview would be something like "Here's a dev machine, make me an app that does this. I'll be back in an hour." (coding test), followed by a code review and "Let's go to happy hour." (personality test).
I would never want to hire or work with someone who read docs only once a day.
This is still nuts. There is literally no amount of documentation checking that is too much, as long as the guy produces results.
I'm fairly introverted and a competent developer; I've only done two interviews in my 13-year-so-far professional career writing code.
The first was for my first job after college. I only called one company in the city where I planned to move; they seemed good, so I got a job there.
The only reason for the second interview -- last year -- was because I moved to Europe, and decided after 4 years that working on the projects & jobs I could get from my contacts in the US wasn't great, so I'd have to (ugh) meet some new people.
I suspect there are plenty of competent developers who have experiences like mine. We'd rather go work with people we already know, the folks on the hiring side would rather grab someone proven, vs. (on both sides) interviewing with strangers and hoping for the best.
I don't know if it's common, but I tend to judge competence by the bottom line: does it work? is it supportable? what was the cost of getting there?
If it doesn't work, or does work but cannot be supported/modified, and cost a lot, it is a product of incompetence. Possibly the manager's, and not the tech guys.
I've never heard anyone refer to djb as incompetent. Some people dislike his coding style, but I haven't heard any criticism about it that is not about style. And yet, he's working with different constraints and experiences than everyone else. And things are often not immediately apparent.