> Or maybe, just maybe, interviewing based on esoteric computer science problems isn’t the best way to identify high performing builders.. but a great way of identifying people who can hack a process to secure maximal reward.
If anything, that might be the best way to identify someone that fits in a large corp like Google. Someone that doesn't mind going thru the drudge of studying esoteric CS problems probably will be more attuned to go thru the drudge of working for a large company like Google.
I'm thinking most of the time spent at Large Corp. Inc. is doing menial work, rather than hot projects where you learn and get to work on the cutting edge.
I'm not sure I understand the comparison. CS interview problems are interesting, well-constrained math riddles with endless variety. As far as I can tell, they're nearly the opposite of menial drudgery.
I don't think they're great for interviewing, on account of how they don't resemble what programmers actually do, but I do think they're a heck of a lot more fun than menial labor, especially when job offers aren't riding on it.
The CS interview problems that are asked are a very specific view of CS that not everybody finds interesting or works on. There is a lot more variety to CS and software engineering than string and graph algorithms, which is all I've ever been asked at Google (where is numerical optimization, statistics beyond basic counting, all of graphics, etc). I also never get asked anything with regards to actually engineering software by them, whereas I have been asked that at Apple for example.
You'd be shocked how many people plan to crack the coding interview by memorizing every problem on leetcode letter for letter without ever trying to solve one without looking up the answer.
It was only 4-5 years ago that Google was considered the pinnacle of Engineering centric culture. It was still considered top up until last year. Something is going off the rails in the big tech firms if people now view big-tech work as menial. These were the same companies that pioneered CI/CD, Services, cloud, scalable web services, and myriad other technologies.
Many of the top engineering companies (Boeing etc.) are also objectively crappy places to work at. When you're doing things at the scale of Boeing or Google, you need a lot of process, and it's just no fun to do engineering this way.
That's probably true. Not that there aren't bits of Google doing fun and interesting work, it's a massive company after all. I've worked at a few, what I would consider to be large orgs, but my experience of Google was that it's truly on a different scale when it comes to bureaucracy and company politics.
At large scale you can't hire enough competent people. And scale x low tolerance for error means you can't rely on humans even if they are competent. To fix that you basically have to introduce process. Things are checked and controlled at numerous points, using blanket processes that often don't make any sense for the specific scenario at hand but are needed for something superficially similar. People end up in hierarchies of approval. And that's without even considering regulatory compliance which often simply mandates things at a blanket level because micro-auditing each individual part of a big company is essentially an impossible proposition.
Engineers have the best chance because we have it in our hands to automate so much, but still, we just haven't figured out a better way to do it I think.
Most of the time when I see a heavy process at work, it's a good question to ask who does it serve?
Most of the time, the answer is that it keeps someone important entrenched in work. It's very rare that I see altruistic processes that benefit the customer.
I've had a different experience (at least with engineering processes). Most of the time, it's been due to things in the past that have broken because we didn't check things or we got misaligned on something or people made assumptions that turned out not to be true.
I'm not saying that adding additional layers of process is always the right answer--there's obviously a cost to adding more process so there needs to be a balance and a continual reassessment of which processes are worth keeping. But in my experience, the intention has always been good: to avoid mistakes, problems, and failures that we've experienced in the past.
If anything, that might be the best way to identify someone that fits in a large corp like Google. Someone that doesn't mind going thru the drudge of studying esoteric CS problems probably will be more attuned to go thru the drudge of working for a large company like Google.
I'm thinking most of the time spent at Large Corp. Inc. is doing menial work, rather than hot projects where you learn and get to work on the cutting edge.