- 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 cracks?
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 widely used pieces of OSS out there has demonstrated they have.
C) There's no evidence that I know of that indicates that whiteboard algo writing correlates with the skill set identified in B, and a fair amount of anecdotal evidence that suggests they aren't correlated. (And there are a range of other skills that are useful for an engineer or someone leading teams of engineers that are similarly not correlated with whiteboard algo writing.)
D) Firms benefit from diversity. Gender-diverse and ethnically-diverse companies are more likely to out-perform less diverse companies.[1] I don't have specific evidence for it, but I suspect that a firm that has a hiring process that brings in people with multiple diverse skill sets will eventually perform better than a firm that only brings in employees with tightly focused, highly similar skill sets.
And to respond to the "well, FB/Amazon/Google make $INFINITY as-is, so nyah-nyah", I would say that those companies are in market-dominant positions now that may make their math on hiring a diverse array of skill sets different from a theoretical firm, but I also suspect that maintaining those dominant positions will be more difficult with an engineering corps that is solely selected on a narrow band of proficiencies.
So, I'm not necessarily saying that Google should change their policy (although I do feel comfortable saying that any company that isn't in that rarified air that decides to copy that policy is making a serious mistake), but I think there's a pretty solid case for why they should at least acknowledge that there are people for whom they should make exceptions and possibly completely reverse that policy and overhaul their hiring process to achieve a broader range of skills among their engineers.
[1]: https://www.mckinsey.com/business-functions/organization/our...
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.
But also maybe it's better that those people don't end up at Google et al. and that these gigantic companies stagnate and eventually die because their corporate bureaucracy/scar tissue prevents them from hiring the people who can prevent them from stagnating and dying? I dunno, haven't really fleshed this idea out too much.
Yep, agreed! But since there's probably some overlap in that candidate skillset Venn diagram, maybe they're getting the people that can do both, and the data-structure skillset's the one that's possible to consistently interview for.