Hacker News new | ask | show | jobs
by umanwizard 2784 days ago
I always see this trotted out as proof of how bad Google’s interview process is, and I always wonder: what makes people think creating homebrew was particularly difficult or impressive? Package managers are a dime a dozen.

It has also never been conclusively explained what “invert a binary tree” means (see the tweet a sibling comment linked to — that’s what the Homebrew guy claimed he wasn’t hired for not being able to do).

6 comments

I realize you asked about people in general and not Howell himself, but he said[1] almost exactly that about his product:

Well, no I didn't [write something worthy of Google]. I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly.

But he goes on:

On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user. When things go wrong with Homebrew it tries as hard as it can to tell you why, it searches GitHub for similar issues and points you to them. It cares about you.

1. https://www.quora.com/Whats-the-logic-behind-Google-rejectin... (Quora link, sorry)

Definitely a bad fit for Google, they aren't especially well known for caring about user experience or the user these days... (/s)
That sounds like he would make a mediocre software engineer but an excellent product manager.
I think the fact that he was able to recognize all the faults (and can therefore correct) in his package manager shows a great level of competency. The fact that he was able to productize his learning experience in the form of homebrew makes him all the more impressive.
I love how you belittle one of the most successful package manager systems out there..

We can apply the same logic to almost anything.. Because nothing is truly original and "difficult/impressive" are pretty broad metrics. Feel free to give us your definition.

Software engineering is about building functional systems for humans. Quite frankly, Google needs to hire more people that are able to deliver products that actually work.. From the looks of it, hiring people that can solve "impressive" and "difficult" sorting algo puzzles yield to the Sluggish Gmail mess we have at the moment.

Maybe google needs to start hiring competent people instead of anyone that can recite the corporate gospel.

Just my 2c.

so much this!

in my job i've dealt with dozens of Google engineers across a few teams... 95%+ of the time I don't get useful answers, and sometimes no answer at all. We have found many bugs in their systems, as well as broken API endpoints that did not work as advertised. Dealing with one issue right now that no one at google has been able to assist with in over 12 months. Of course with all the turn around on some teams, the issues just keep getting passed to the next guy.

they are by far the worst of the FAANG-level engineering teams we deal with, competency is severely lacking.

Package management is a task filled with subtle pitfalls that is much, much harder than it looks on the surface.

It's a lot like syncing files - e.g. how Dropbox looked similarly deceptively easy to build but really wasnt.

IMHO the fact that the homebrew guy didn't get hired and that golang package management was a dumpster fire for years isn't coincidental. Both were part and parcel of a systemic bias that plagues Google's culture that they're blissfully unaware of.

Google doesn’t do package management well because they don’t do package management at all; they have a monorepo. If anything, the systematic bias is that Google built their way around an entire class of problems that others still face.
This has something to do with why the Go team waited so long to solve package management. Having little experience with it, they tried leaving it to the community.

But I don't think you can generalize to the whole company. For example, the Dart package manager is pretty nice.

I agree, to some extent. It's not terribly difficult to make a package manager. But it's a strong positive signal: it's hard for someone who is really bad at software to design a popular system like that. Also, it's unlikely for someone who is a really bad employee to take the initiative to even execute a task like that.

Regardless, I don't think qualifications like this should bypass the interview. The author almost sounded a little entitled when describing the rejection. That said, I don't think his achievements got sufficient weight while evaluating him as a candidate.

See my comment [1] regarding what these interviews are selecting for -- it might be a bad process, but it might come closer to the intended goals than other processes do.

[1] https://news.ycombinator.com/item?id=18382384

Why shouldn't major accomplishments bypass the "random algo from a hat" that Software Engineering interviews have devolved into? If someone is a core contributor to a large, highly successful open source project, you have concrete proof of practical experience that you can discuss with the candidate. I'd put 100x more weight on that versus his ability to invert a binary tree on the spot.
There are more people in the world using homebrew than what most of Google engineers single handedly wrangled or produced -- excluding google products that came out of Google Labs that we now use. So if you want someone who can take shitty lemons and create a tasty lemonade out of it he is definitely your guy.

Here's the thing - outside some special projects for which people are hired without going through the standard interview process Google does not want those who can take shitty lemons and convert them to tasty lemonade. Google wants specific kinds of butts that fit into a specific kind of seat. It wants the most homogeneous high output monkeys that would do what they are told, such as spitting out a code to invert a binary tree.

You can also set up cloud storage quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. Yet, the Homebrew guy went out and made a package manager actually getting used but still couldn't get past Google's abysmal interviewing process.