Even within Google, Facebook, Amazon, and Microsoft, you're usually being interviewed by a fresh-out-of-school 20-something who has no idea how to do much of anything, let alone evaluate candidates fairly. And yes, they "train" these kids -- but you basically can't train someone to do something that relies heavily on intuition. That requires experience, but 20-somethings don't have experience. So instead, they're "trained" to do the one thing you can do repeatably: ask coding puzzle questions from a book, and reject anyone who doesn't regurgitate answers with 100% fidelity. It's the McDonald's food of interviewing: not the best (or even good), but consistent across a large organization. Sort of.
So while big companies need people who can work on a team, exercise good judgment, communicate clearly, write clean code and not be racist/sexist/evil jerks, they get...people who can memorize questions from a big book of programming questions. I can easily come up with tests that get to each of those properties...but they rely on interviewers having good judgment, and most do not.
My internal dialog when asked things like a linked list or a hash table is "Oh god, does this mean they like code like this? I bet some 'clever person' at this company wrote their own hash table/event queue/template engine* and forces everybody else to use it."
* Unfortunately my current employer is just like this but I didn't pick up on that in the interview process.
One of the most painful interviews I have ever seen was a guy who had a resume listing a number of interesting projects. He could talk energetically and in detail about them. Then we asked him to write some code to solve a simple problem. He said he didn't know our primary language, but was very familiar with Python. I know Python, I was good with that.
He didn't know Python. I tried to help him, but he didn't get much farther. I eventually called the interview, with a complete 180 of my hiring opinion. Nice guy, but he couldn't be what we needed.
Good interview processes reflect complementary broad and deep concerns. It's kind of analogous to the way a strong team is better than the sum its parts.
This could be the first coding interview style that actually makes sense to me
As I mentioned elsewhere I think you can ask questions that look like work but aren’t (go too far the other way and you’re into IP problems)
You don’t want an organization that relies on one or two or three people to swoop in and save the company every time there’s an emergency. A production issue should look like disaster preparedness. Document, train, drill, prevent.
More concretely, make the important parts as obvious as you can, as similar to production as you can, so anyone can set up a system and try to repro the problem. Config, build, and deploy should be push button (very robust scripts with every cheap sanity and safety check you can manage). No flakiness is okay. Nor obscurity. Everybody should understand how it works.
Document everywhere diagnostic data comes from and goes to. Don’t let your most senior people solve production issues; assign them to people one step down (and throw in some promising mid-level team members for diversity and longevity). Five why’s every outage and be sure your resolutions always involve making the problem easier to detect next time, not just prevent.
IMO any team with an SLA should be avoiding these people like the plague, because they will tolerate bullshit manual processes that take all day. They have no motivation to make foolproof automated processes with good visibility and repeatability. The smartest of them will fight attempts to change the status quo because the status quo makes them look good and everybody else look like idiots.
Three of my favorite bosses were from the Fire All Heroes school of management. Two actually gave a speech to that effect in front of the entire engineering dept. They helped me get out of the hero racket.
It’s great to be needed. But it sucks being the bottleneck.