I'm terrible at big tech company interviews--kind of a generalist, read Cicero rather than Knuth in college, tend to start out problems kind of muddled, etc. After a while I concluded the only way to get into large SV companies was to sell a company to them. It's easier to go through due diligence than the corporate interview process in a lot of places.
(That's how I got my current job.)
I do however think it's a game that conflicts with certain personality types, including myself early in my career.
I'm always curious what you (or anyone else!) think could be done better.
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.
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.
1.) They select using criteria that are easy to test, such as writing quicksort on the fly. That's a small part of engineering --you also want people who can recognize big-picture patterns and communicate them clearly. This is a lot harder to evaluate so many interviewers simply don't.
2.) They select for people who are already in similar positions. For instance, white-boarding kubernetes application design is pretty easy if you are already doing it. As an interviewer it does not really tell me much about your ability to think originally or whether you can adapt.
Getting around these biases is hard. One way I test people now is to ask them to show me their favorite design or code and explain exactly how it works. That starts them off on comfortable ground. Then I start to tweak the boundary conditions to see if they can adjust creatively. It removes the stress factor and is a lot more illuminating than coding up something totally new from scratch, especially if you only have 45 minutes to extract as much information as possible about somebody's thought processes.
Very interested in other thoughts on this topic. It's a hard problem.