I agree with the story. To interview, you don't turn little details into big questions. You turn big questions into little details.
Interviews are lossy compression of a career, experience, and brain shape, over a noisy channel of whiteboards and human speech. The best you can hope is that your interviewer will recognize the larger pattern.
BUT. There is limited time in an interview, so we try to scry nuances like a soothsayer with a pile of sheep guts. Every detail gets magnified.
Examples:
"You chose to return an error code instead of throwing an exception." Is this an optimization, or have you spent a lot of time on system programming?
"I see a couple of fenceposting errors." Is it nerves or do you not have the right shape of the problem in your head?
"You passed some bookkeeping information in a recursive call that should take care of itself." Do you not understand recursion, or are you misremembering something cool about accumulators and tail recursion?
"You chose to use inheritance instead of composition." Have you ever had to extend or maintain such a design, or did you read about it in a book?
"You used template metaprogramming." Are you a misunderstood genius or do you delight in writing unmaintainable constructs from the dark corners of C++ into production?
"You chose to use Perl but don't know what a hash is." Do you have any questions for me?
Scoff if you like, but I hired that guy. He's a fellow at Adobe now. They bought his startup.
We interviewed a Busuness school Finance senior to help on our COMSTOCK satellite feed parsing project.'Do you know C++?" we asked. "Yes" he lied, then "Can I come in over the weekend to get started?" How enthusiastic! Sure!
Turns out he spent the weekend studying code, learned to program C++. I didn't see him for a few weeks, then consulting on his code over something I mentioned "This would be better allocated". "Yeah, I wondered what the pointer stuff was about". I was astonished he'd come so far on guts and smarts. I explained malloc, pointers, he was off again.
You could pretend that. Or you could say, we valued his intelligence and readily-apparent ability to learn over 'fizz-buzz' nonsense questions and cargo-cult interview style.
Looking back, were they overqualified or underqualified? If you had tested the second guy's C++ skill (sounds like he couldn't have done Fizzbuzz in your interview), would you have disqualified him? If you didn't think C++ was that important, why ask in the interview?
All I'm trying to get at is if you take your experience as a rule.
The population of people who lie about their programming skills is unfortunately all too high. The subset who can make up the difference in two days, unfortunately all too small. I think a Google or Amazon has to play the percentages to keep a high bar. The cost of a bad hire reverberates through the organization.
Which is why you should learn more about a candidate than their current programming toolset. Like their adaptability, their insight into problems and their convolutions. Not about their facility with the current fad language.
Interviews are lossy compression of a career, experience, and brain shape, over a noisy channel of whiteboards and human speech. The best you can hope is that your interviewer will recognize the larger pattern.
BUT. There is limited time in an interview, so we try to scry nuances like a soothsayer with a pile of sheep guts. Every detail gets magnified.
Examples:
"You chose to return an error code instead of throwing an exception." Is this an optimization, or have you spent a lot of time on system programming?
"I see a couple of fenceposting errors." Is it nerves or do you not have the right shape of the problem in your head?
"You passed some bookkeeping information in a recursive call that should take care of itself." Do you not understand recursion, or are you misremembering something cool about accumulators and tail recursion?
"You chose to use inheritance instead of composition." Have you ever had to extend or maintain such a design, or did you read about it in a book?
"You used template metaprogramming." Are you a misunderstood genius or do you delight in writing unmaintainable constructs from the dark corners of C++ into production?
"You chose to use Perl but don't know what a hash is." Do you have any questions for me?