> I don't think Google's hiring people thing that that's what a good developer is, as much as they think it positively correlates to good developers.
I agree. However, I think they are wrong... I'll expand below.
> This is also a valid concern, but Google is much more concerned about false positives than false negatives. Missing out on a good candidate is a bummer. Hiring a bad one can be a nightmare. So the process is skewed to avoid the latter even if it costs the former.
This is an oft-repeated line about Google's hiring process, and in fairness, I think it's oft-repeated because insofar as it reflects Google's belief that their process results in good developer hires, it is true.
However, my suspicion is that the phenomena going on here is not "losing out on some, but not all good developers in order to weed out bad ones," rather, it's "losing out on a certain kind of good developer in order to weed out bad ones." That is, I'd conjecture that the good developers who can (or want to) memorize algorithms and regurgitate basic CS knowledge are one kind of capable dev, and the good developers who rely on tools to a greater degree are another kind of dev. Call them types A and B.
I don't have the two segregated into neat categories - because this is just a suspicion, based on people I know who work at Google, and my own experiences - but I think it's roughly along this line: Developers in category A have an innate desire to learn about and understand computer science on a theoretical level, as much as or moreso than a practical level. Such a person may or may not enjoy building things as much as they enjoy learning about how to possibly build things. Developers in category B (I'd include myself in that group) don't care about theory as much as practice; they do what is necessary to get the job done. Now, neither group hates theory or practice, they just have preferences about which one to spend their time on.
For an organization to really be successful, I'd argue, you need a mix of types A and B (tending more towards one or the other depending on the type of entity). If Google is weeding out most or all of type B, they are doing themselves a disservice - and I would argue that insofar as many of the common complaints about Google (services created then abandoned, poor support, poor attention to bugs/issues, etc.) are true, if this theory is also true, it would help explain why. The practical-preference developer wants to make things work and keep them working; the theoretical-preference developer wants to discover new things and constantly expand her knowledge. Both aims are good, but you cannot have one to the exclusion of the other as an organization.
> That is, I'd conjecture that the good developers who can (or want to) memorize algorithms and regurgitate basic CS knowledge are one kind of capable dev, and the good developers who rely on tools to a greater degree are another kind of dev. Call them types A and B.
I really dislike this characterization. I'm a googler. I've never tried to, or needed to, memorize algorithms. I don't know if this characterization comes from misunderstanding, rationalization, or what, but in my experience at least, neither do most of my coworkers.
That is, I at least don't recall a rote algorithm when interviewing In fact in one of my interviews (not at google, but I could see a similar question happening there) I had to derive a solution to a problem in a space I was totally unfamiliar with (locking and multithreading).
It seems like, if you assume (incorrectly) that somehow you can't cheat the system, Google is selecting for people who can solve unfamiliar, complex, problems by applying first principles. That is, I think, orthogonal to the idea of 'theoretical or practical' computer scientist.
We have something interesting here, in that I'm looking at this from the perspective of someone the Google system rejected (and who later decided/rationalized/realized participating wasn't really worthwhile) and you're looking at it from the perspective of somebody it embraced.
Naturally, it wouldn't boil down so easily in practice to these two types, even if they are the correct ones. Everybody is a mix of both (and plenty of other things); plus, we have to assume that, like you say, occasionally somebody incompetent or strongly type B "cheats" the system and gets hired.
But I guess the question is: How, to you, does "selecting for people who can solve unfamiliar, complex, problems by applying first principles" not seem to jive with my definition of category A?
So, I think my biggest issue with your A/B dichotomy is that I don't see it. That is, in school, in myself, in coworkers, there isn't this large group of people who are trying to do all the theory at the expense of practicality, as opposed to this group of stuff-accomplishers who aren't theoreticians.
I mean, occasionally those people exist, both the "fuck it I'm going to sit down and type until it works" people and the "I must understand this concept before I write a single line of code" people. But as you say, everybody is a mix of both, and I think most people are nearer the middle than the sides, which makes the possibility of mild bias towards one side or the other a lot less harmful than you maybe expect.
The thing is that as an outsider looking in, I see a lot of evidence that Google has this dichotomy and suffers from it. I mentioned some of it in my posts above, but in general, a lot of the company's pain points from my perspective - and from the perspective of employees less satisfied with their experiences[1] - fit what we'd expect from such an enterprise.
Here's an example of what I mean: Google is a company with incredible tech and quite a lot of money, but its products tend to fall into clear patterns. First, create something awesome, then fail to support it, then fail to monetize it, and eventually, it fall to the wayside and is discontinued. There are so many apps Google has created that fit this mold that people have done meta-analyses on how long the average Google product lasts.[2] Obviously, not all Google's products fit this mold - but I think Google is unique in being able to support this pattern, fiscally and from a development fatigue standpoint.
This pattern is exactly what I would expect to find at a company that is mostly based around theory and concept, and that is either inexperienced at or disinterested in support work after the initial execution.
It's probably true that most people, even at Google, are somewhere in the mid-range. However, a large enough group of people with a small bias will result in a shift in the policy of an organization. I still think it's fair to say that, if my dichotomy exists, it would effect Google's institutional behavior even if the degree of difference between people is low on average. That is to say that while you may not see it, it also may not be obviously or even at all visible from the level of one person in one part of the organization, whereas its effects are visible from both within and without. It's kinda like dark matter - you don't know what's happening in someone's head, so you can't observe it directly, but you can predict outcomes based on hypotheses and see what comes true.
Interesting, when I read those answers, what I see is more or less people saying "management can sometimes be downright bad, and is often stupid". I very much doubt that many of the people (broadly) deciding which products to support and which to drop were hired via a new-grad-like interview process.
For things like moonshots/other bets, the "build something awesome but don't monetize it" makes a lot of sense, since the entire point of that division seems to be "build something awesome and see if it is sustainable too". More often than not, unfortunately, the answer is no.
In fact, if anything, I'd reverse the cause and effect in your idea. If we presuppose that there is this dichotomy in people and it affect google's motives and goals as a company, then this would influence the tech hiring practices to be the way they are, not vice versa.
> I very much doubt that many of the people (broadly) deciding which products to support and which to drop were hired via a new-grad-like interview process.
I'm confused as to why you doubt that. Google's been around for almost 20 years. Their interviewing process has been around since at least 2003.[1] It's 100% possible that somebody was hired, ended up in higher management, and graduated to making driving decisions (at least over a particular area) in that time, unless your suggestion is that nobody who enters as a new grad ever stays long enough to get to that level, which at Google (vs other SV companies) seems unlikely.
> For things like moonshots/other bets, the "build something awesome but don't monetize it" makes a lot of sense, since the entire point of that division seems to be "build something awesome and see if it is sustainable too". More often than not, unfortunately, the answer is no.
It does make sense, it's more the messaging around those kinds of projects that tends to get lost. You end up in situations where thousands or sometimes millions of users are relying on a "beta" product, which has no monetization strategy, and then gets scrapped. It's a pattern that's still unpleasant for end users and not great for Google's reputation.
> If we presuppose that there is this dichotomy in people and it affect google's motives and goals as a company, then this would influence the tech hiring practices to be the way they are, not vice versa.
That's a great point, and likely, assuming of course that Google started this way (I think it likely did, given its founders' backgrounds). It creates a self-perpetuating cycle, though, which still ends up being problematic.
I agree. However, I think they are wrong... I'll expand below.
> This is also a valid concern, but Google is much more concerned about false positives than false negatives. Missing out on a good candidate is a bummer. Hiring a bad one can be a nightmare. So the process is skewed to avoid the latter even if it costs the former.
This is an oft-repeated line about Google's hiring process, and in fairness, I think it's oft-repeated because insofar as it reflects Google's belief that their process results in good developer hires, it is true.
However, my suspicion is that the phenomena going on here is not "losing out on some, but not all good developers in order to weed out bad ones," rather, it's "losing out on a certain kind of good developer in order to weed out bad ones." That is, I'd conjecture that the good developers who can (or want to) memorize algorithms and regurgitate basic CS knowledge are one kind of capable dev, and the good developers who rely on tools to a greater degree are another kind of dev. Call them types A and B.
I don't have the two segregated into neat categories - because this is just a suspicion, based on people I know who work at Google, and my own experiences - but I think it's roughly along this line: Developers in category A have an innate desire to learn about and understand computer science on a theoretical level, as much as or moreso than a practical level. Such a person may or may not enjoy building things as much as they enjoy learning about how to possibly build things. Developers in category B (I'd include myself in that group) don't care about theory as much as practice; they do what is necessary to get the job done. Now, neither group hates theory or practice, they just have preferences about which one to spend their time on.
For an organization to really be successful, I'd argue, you need a mix of types A and B (tending more towards one or the other depending on the type of entity). If Google is weeding out most or all of type B, they are doing themselves a disservice - and I would argue that insofar as many of the common complaints about Google (services created then abandoned, poor support, poor attention to bugs/issues, etc.) are true, if this theory is also true, it would help explain why. The practical-preference developer wants to make things work and keep them working; the theoretical-preference developer wants to discover new things and constantly expand her knowledge. Both aims are good, but you cannot have one to the exclusion of the other as an organization.