Earlier quoted context omitted.
Possible points for the defense: - He may be qualified to work at Google, but that's not apparent just because he created Homebrew, right? - Google can afford to be picky enough to miss out on popular open-source project authors who _can't_ code on the whiteboard in favor of those who _can_ -- can we argue that they should reverse this, or just that in certain cases potentially-qualified people fall through the crack…
I get that the response to this will be "they make $INFINITY as-is", but yes, I'd be willing to argue that they should reverse that. My basic argument would look something like: A) Writing algos on a whiteboard is not the be-all end-all of actual programming B) The skill set of "can identify things that people want and need and actually implement them" is a useful one that the person who created one of the most widel…
I do agree that the "make things people want" is a very useful/desirable skillset for a vast array of non-Google-scale companies, and I'd personally prefer to work for a company that values this.
But I'm willing to posit that at a certain software engineering scale, the problems and valued traits are very different, and may align more with "knows data structures" than "can make something people want".
I'm not saying Google should value one to the exclusion of the other. But perhaps if you have Google's talent pool, the base level is "ingrained data structure knowledge" (correlating to engineering skills they need), and they'll also get the "ingrained data structure knowledge AND ability to make something people want" applicants.
I'm not arguing that other companies should do this. Just exploring whether it makes more sense for Google than perhaps we would think.