I don't know how true the % is, but that is what Howell claimed and several Google employees verified that his software was used by significant parts of Google's engineering staff.

At any rate, the point is that a guy who used software used by a large portion of Google's engineering team because it was superior to the in-house solution could not get a job at Google because he failed to answer a programming question in the specific manner the interviewer wanted for a type of problem he would never actually encounter on the job. And in that vein, Sergie and Larry would similarly have difficulty getting hired at Google because other than their original algorithm, which Google has not used in over a decade, they have no modern or recent software experience and would likely fail all of the programming interviews.

People at Google use blaze. I've never heard of anyone using homebrew. I think number is quite near 0%.

It's hard to put everything in a build system like blaze but if you do, I think the outcome is superior to Homebrew.

I have never worked at Google, but around 2015 everyone I knew working there was using Homebrew if they used Mac for development. Moreover, there were quite a bit of HN and Reddit discussion about this incident at the time, and a number of Google engineers confirmed that Homebrew was in widespread use among the Mac-based developers.

I have no idea how great a developer Howell is, but it's simply not true that Homebrew was used by many Google employees. I was at Google at that time (2015), had a macbook for several years, and had never even heard of Homebrew.

Google is a linux shop, and you were generally not allowed to even keep the source code in your notebook.

Where would one keep the source code then - if not locally?

Either in a desktop sitting securely under your desk at office, or "in the cloud". You would remotely connect to them to do your development. (Most of Google binaries I saw were way too heavy to run on a Macbook, anyway.) Macbooks were just for checking email, calendar, or similar stuff.

> At any rate, the point is that a guy who used software used by a large portion of Google's engineering team because it was superior to the in-house solution

Do you seriously believe that they couldn't come up with something better than mediocre package manager?

Based on Google's track record the past few years, Yes, I seriously believe that Google could not come up with a better package manager. They've taken 6 shots at a basic messaging application and they still haven't gotten that right. 4 attempts at a payment application. Stadia. Wear. Nest (post-acquistion). The had 1 shot with Stadia to do it right and they fucked it up so badly that it's impacting Google's ability to sell other services to prospective business partners because prospective clients rightly doubt Google's ability to launch and maintain a product.

The real question is: knowing Google's track record of almost complete failure for the past few years, why would you believe in Google?

And again, do you seriously believe that any of this has to do with engineering and not lack of business vision?

Based on the bugginess of Maps, Duo, Hangouts, Wear, Stadia, and other products, I would say that the poor engineering is almost as much a factor of these failures as the lack of business vision. After all, the product doesn't need to work well for the PM to get promoted. It just needs to exist.

Google is run by the engineers. You don't get to blame the MBAs for its failures.

> Based on the bugginess of Maps, Duo, Hangouts, Wear, Stadia, and other products

What are your sources?

All code at google is built from source from a single mono repo with a one version rule. Approximately zero googlers use homebrew since almost no development is done on macs and there is no need for packages management.