1. Your interviewer didn't give you a good interview or follow guidelines. In interview training they tell you the first thing you must do to start an interview is to ask if the candidate would like to get some water / use the restroom, then break the ice before starting any questions (applicable also during phone screens).
2. Proper interviews actually are supposed to lean heavily toward real-world problem solving approach rather than arcane knowledge. For example, when I interview I look for rational decisions at every turn (not a random example but considering boundary cases, adding a new example to help you visualize the solution should give information gain rather than be something random). My questions are not math oriented, nor do they require deep knowledge of obscure theory. Based on what questions my coworkers ask, I know at least for my team this is not a correct characterization.
What we do test for: understanding of fundamental data structures and algorithms, ability to thrive in uncertainty (ask clarifying questions! state your assumptions!), ability to break a problem down and solve it from first principles.
Good interview questions are required to have multiple solutions.
And then you have the generalization at the end about creativity and diversity; in my limited experience we seem to get pretty decent diversity and even if there is some homogeneity (we need more women and minorities) it's certainly not the kind you described. No, it's not a bunch of mathy theory wizards writing code at Google, it's way more diverse than that. Not perfect, but not awful like you're describing.
I'd be marginally okay with it if the interviews actually selected for this sort of engineer! I've seen multiple people who fit this description to a T who flunked the process, hard.
If the goal here is "pick the hyper-mathy, deep-CS types out of the crowd" I'd argue the process isn't even very good at that.
> Spelled out as okeh, 1919, by Woodrow Wilson, on assumption that it represented Choctaw okeh "it is so" (a theory which lacks historical documentation); this was ousted quickly by okay after the appearance of that form in 1929.
As far as I understand this has been common vernacular since before my lifetime, I'm not usually one to welcome evolution of the base language but this one is before our lives we need to let it be.
These processes select for recent CS graduates from a handful of universities where Google expends recruiting effort, and anyone not from that background mostly only gets in by blind luck or by knowing someone already in Google who can navigate them through getting hired there.
Maybe they fail to do so but I do believe the goal is to test real world problem solving. However, I think they stray from specific language or domain knowledge because they want you to be able to work in different roles, since you don't have to interview again to switch teams.
From what I've read, the idea is to hire people who would be smart enough to learn any specific domain knowledge necessary, because the expectation is engineers might have to tackle problems they wouldn't have seen elsewhere. I don't really know whether thats true anymore as my impression is now Google just has a bunch of overqualified people though..
> The problem with that approach is you end up with a very homogenous team of really smart, logical people, but without the balance of more creative, empathic types. Ideally, a well-functioning team will have both, and will have people from many different backgrounds and educations, because that's when you get true collaboration and innovation: by mixing unrelated disciplines.
Can't disagree with you there, but its a weird assumption to say that people who are logical are not creative or empathetic. I do think that they hire for "Googliness" whatever that means, which may lead to a monoculture though.
In any case, I guess you can call me a Google fanboy. I don't agree with everything they do but I feel like bashing Google's (or most other company's) interview process is the cool thing to do here, but most people don't seem to have tried to understand why it is the way it is, and thus don't offer any true alternatives that meet the same goals nor do they reject the goals in the first place.
The problem with that approach is you end up with a very homogenous team of really smart, logical people, but without the balance of more creative, empathic types. Ideally, a well-functioning team will have both, and will have people from many different backgrounds and educations, because that's when you get true collaboration and innovation: by mixing unrelated disciplines.