3 ms·

> 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.

> 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.

joshuamorton 10y ago
> 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.
- ivraatiems 10y ago
  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?
  - joshuamorton 10y ago
    Indeed we do. 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.

joshuamorton 10y ago

> 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.

ivraatiems 10y ago
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?
- joshuamorton 10y ago
  Indeed we do. 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.