That may well be, but if you're considering hiring a guy who's an expert at writing package management tools, don't you put him on one of the specific subteams that needs that skillset? Surely it's something Google deals with?

The problem is that Homebrew is very different from the sort of package management tasks that Google deals with. The design goals for Homebrew include: make it easy for users, make it not require root, make it work on Macs, handle dependencies robustly. If he were at Google it would be Linux-only, he'd be using Linux containerization extensively, he'd be deploying packages to thousands of machines instead of one, it'd be a virtual guarantee that some of the machines would fail during the installation process, there would be little or no user intervention and if there was a user it'd be a trained SRE, and the installation procedure would probably need to be an order of magnitude more efficient than Homebrew is.

I don't want to take away from his accomplishments as a programmer - I use Homebrew too. But my point is that it's very easy to see "Good programmer, of course he should get hired" from the outside, while the reality is that it may not be all that similar to the tasks he'd be doing.

If you are hiring the Homebrew dev, and your devs currently use Homebrew, why wouldn't you hire him to work on Homebrew for you?

Last I knew, Google corporate Macs don't include Homebrew. (I left Google a year ago, things could've changed since then.) I'd be very surprised if it was allowed, I have an open-source project that's available via brew and I've had people at other companies tell me that anything brew-only is a complete non-starter at their company because Homebrew isn't allowed for security reasons, and Google cares a good deal about security.

I assume that the dev was referring to Googlers' personal laptops with the "90% of your devs use Homebrew". It's not unreasonable to estimate that 90% of Google engineers use a Mac as their personal machine, although 90% using Homebrew is probably an exaggeration. A lot of Googlers use their corp machine as their personal one (they're not supposed to, but it's hard to police when all you do is surf the web), and the majority of them don't have side projects outside of work. I didn't install Homebrew until after I left the company, since before then all my code belonged to Google.

> If you are hiring the Homebrew dev, and your devs currently use Homebrew, why wouldn't you hire him to work on Homebrew for you?

Macs account for something like 8% of the total marketplace of all PC's. For developers, they account for something like 20%... another 20% on Linux, and remainder on Windows or other.

So even if somehow having a paid Google employee work on Homebrew seemed advantageous, it would only benefit 20% of Google's staff, and 0% of the company itself (all Google servers are Linux).

Except that google 'banned' the use of windows internally a few years ago unless you had a really, really good reason for it.

Not sure what's the status of that ban (nor I care), but will skew the numbers enough to invalidate your point.

> enough to invalidate your point.

It might except ex-googlers in this thread of stated Google "banned" use of Homebrew internally. So the net benefit to the company and/or employees remains small to zero.

This is off topic though, since he was not being interviewed for homebrew development.

As far as I'm aware, Mac is just as 'banned' as Windows. Developers have Linux(Goobuntu) desktops and Mac, Linux, Windows or ChromeOS for laptops (which are primarily used as a terminal for your desktop).

actually internal sources tell me that Mac OS X is the dominant OS at Facebook, Google and Twitter, with a lot lot lot lot more than 20%

Sure would've been nice to have a package management expert working on Go.

I might be wrong, but I'm pretty sure Mark Zuckerberg can reverse a binary tree.

Probably cheaper than starting 1000 $19M projects and dumping the ones that aren't wildly successful.

Very good point. It's like, why do you want to work for Google if you aren't into algorithms?

I failed my third google interview. My problem wasn't that I couldn't solve the problems. I just wasn't fast enough because I didn't spend 3 weeks beforehand training speed in programming brainteasers.

other then search and maps, how many of their products use algos heavily though?

many projects i have worked on over the years required very little knowledge of algos.

All of infrastructure. You end up using LSM trees, Paxos, variations on binary search trees, checksums, Reed-Solomon, bloom filters, external sorts, and all sorts of other academic algorithms when you deal with distributed systems.

Docs/Drive does a lot with operational transforms and CRDTs, ever since Wave was merged into it (c. 2011). Remember that all Google Docs are collaborative.

All logs analysis & experimentation relies heavily on statistics, as well as online algorithms for reservoir sampling, quantiles, and a number of other statistical quantities.

Machine-learning is pervasive, throughout Shopping & News (it's all over these), GMail (spam, priority inbox, categories), Search, Ads, self-driving cars, Brain, and many other areas of the company.

Chrome and Android both do a lot of traditional OS & systems programming.

The main product area that didn't use algos heavily was Google+, although even this had some interesting stuff in stream ranking and search.

This is one thing people don't understand. In my current work I need to regularly design a new algorithm or modify existing ones. I've to keep books like CLRS and TACP always accessible, not for show but actually looking through pseudocode and analysis. I regularly sweep through dozens of research papers to find the state of art. These are not one-off events it's my and my teams day to day life. Lot of people often gets surprised when I tell this to them because most developers think they never need to use any CS stuff they had learned. If they ever need answer on any algo there is always framework or wikipedia. They just don't understand that most real world problems (or at least the ones we work on) require significant amount of customizations and mixing. These same people then insist that just because they have "shipped" some code or because they have showed "coding" capability via github profile, they should be eligible to be hired anywhere. Coding and development is "given" and that's considered as easiest part in our line of work. Shipping things is certainly art but that's hardly sufficient condition. The choice, analysis and design of algorithm makes ALL the difference in type of problems that we work on. If a guy showed up who wrote some package manager on Mac but couldn't work with binary trees, I would probably would pass too because in the kind of work we do his chances of success is fairly low. Frameworks and programming languages can be learned pretty fast but learning CS and building problem solving abilities using CS primitives takes years and years of intensive study.

There's totally a lot of crunchy CS in many things Google is into (and I do distributed systems stuff, so I can empathize heavily with your first paragraph). If you're doing it right, though, writing the crunchy CS bits of these should be exceedingly rare. Understanding is important, but I'm not sure you get a measure of working applied capability from writing this stuff in an interview. Discussing it, surely, but this is stuff that one--wait for it--Googles when dealing with implementations. And I strongly doubt that the overwhelming majority of Google developers are involved with the actual construction of this stuff.

The real reason, as near as I can tell, is because it allows management to not think as hard about allocating talent (the mythical "fungible engineer" nonsense), but whether it even works is another thing entirely.

Not everyone is constructing them, but everyone needs to be able to reason about they behave, determine what they need, and yes write it if a good option isn't available.

Hey man, all that CRUD needed to make all those shovelware google apps requires a ton of algorithmic knowledge. /s