Hacker News Reader

Comment by pmden | Hacker News Reader

"possibly the most important piece of software on OSX"

I'm earnestly trying to avoid downplaying his work, but it's only a package manager. Unless he was interviewing to be Google's next head of package management on OSX, I'm not sure why you think assessing him on something other than his useful side project is bad form. I'm also not certain how an answer being 'easily-googleable' makes it arbitrary or pointless. Someone had to write that answer on Stack Overflow, and the chances are you'd rather hire that guy.

View on HN

> I'm earnestly trying to avoid downplaying his work, but it's only a package manager.

I'm earnestly trying to avoid downplaying your comment, but you sound like you have no clue how much engineering effort and talent is actually required to build and maintain a reliable, functional, production-grade package manager that a huge number of people use.

Being able to completely implement and support a sophisticated software product end-to-end is a FAR better indicator of engineering talent than isolated algorithm puzzles on a whiteboard. Whiteboard problems are used in interviews simply because individually executed complete projects are so rare (at all, let alone publicly visible).

In fact, whiteboard interviews have all but been proven to be among the least useful at distinguishing good vs bad candidates. The only reason it works is because everyone knows it's a game, studies the game, and gets tested at the same game. It's essentially a disguised IQ test that you have to study for.

The problem is, if you don't study for it specifically, you're at a huge disadvantage. This leads to famous engineers (clearly talented) getting rejected because they don't practice jumping through the particular hoops the company makes everyone jump through.

It seems there are more than several cases where Google needs a high profile engineer more than that engineer needs Google, and as a result the engineer doesn't study the hoop-jumping Google wants. Google rejects them out of bureaucratic process, and loses out on a good hire.

On the opposite side: I'm not a famous engineer, so I suck it up and practice whiteboard algorithm problems like most everyone else -- and as a result, I've never had a problem passing coding interviews. But just because most everyone jumps through hoops to play the game, doesn't mean everyone should have to.

To add to your points, the problem is not just missing good engineers because they don't study and play the game, but also hiring bad engineers because they study and play the game.

I personally know of people who habitually study FAANG interview questions, and make it their career to jump ship every few years for salary boosts. I've worked with some of these people; while they are nice and friendly folks and I consider some of them good friends of mine, they are much less-good engineers compared to many others I know, who stay in smaller startups and want to get things done and don't want to play the interview game.

I'm one such 'engineer' who is good at whiteboarding algorithms. I can do well on 'system design' questions but dont feel confident at all about really designing such a system from ground up. I, for one, am glad that I can find gainful employment by memorizing 200 pages.

I'm happy for you, but I hope you're also that honest with yourself and your employers about your limits when they want you to built something that you know is over your head

> I'm earnestly trying to avoid downplaying your comment, but you sound like you have no clue how much engineering effort and talent is actually required to build and maintain a reliable, functional, production-grade package manager that a huge number of people use.

It's also entirely possible that Google saw Homebrew as neither reliable, functional, or production-grade enough for their taste. While Homebrew is somewhat decent today (though, it's still broken in some ways that I will not go into here and I'm under the impression that it's being worked on), but it wasn't always particularly reliable or stable. The only real benefit it had (and arguably still has) is that it has massive traction.

That's a very good point -- I've never had any issues with it, but I've also not used it very extensively, so my anecdotal experience doesn't count. If it's true that it's more broken and unreliable than alternates, then I'd agree with you.

> I'm earnestly trying to avoid downplaying his work, but it's only a package manager.

I don't really know what to tell you, except I feel like you may be new to software engineering or have forgotten much of what goes into it. The vast majority of engineers at Google will never lead a software project with the utility and breadth of use as the most popular package manager for mac OS for almost a decade. Most engineers at Google will contribute to a small portion of software that will be run by a large fraction of the planet's computers, but owning the architecture, project management, testing, community support, and coding? No.

A package manager that works as well as brew (though it's not without its faults!) is non-trivial to say the least. We suffered through fink, and things got better with macports. But brew clearly works better.

It's reasonable for a company to reject a new graduate applicant based on their freezing during an interview, for an algorithm that is part of freshman year courses in Computer Science. It's also reasonable for us to comment on the absurdity of a company making the same determination for a senior software engineer at a top software company, the vast majority of whom do not touch binary trees for an entire career!

If a Google engineer were to reimplement a binary tree or quicksort in a backend service, that code would fail code review with the comment: "use the library."

> Someone had to write that answer on Stack Overflow, and the chances are you'd rather hire that guy.

The popularity of his tweet indicates that no, chances are that engineers interviewing Max Howell would absolutely choose him over a binary-tree-implementer. Evidence indicates your viewpoint is in the minority.

I think you answered it yourself. His skill set (running, managing, community, etc) are not what Google needs (as they see it). They need someone who "will contribute to a small portion of software that will be run by a large fraction of the planet's computers, but owning the architecture, project management, testing, community support, and coding? No."

Your "etc" includes writing the damn thing in the first place, which indicates he is more than qualified for "will contribute to a small portion of software that will be run by a large fraction of the planet's computers".

Furthermore, for L5 and up Google is most certainly looking for systems design and engineering leadership skills.

> he is more than qualified for "will contribute to a small portion of software that will be run by a large fraction of the planet's computers".

Maybe, but for that part he was in competition with people that were simply better to "contribute to a small portion of software that will be run by a large fraction of the planet's computers".

That's where we come to my second point.

Additionally, the public perception of the Google hiring process (a perception cultivated by Google themselves) is that candidates are not in competition with anybody. It's just "do you clear the bar or not".

Companies rarely hire people in a vacuum; almost always, it's because they are looking for someone to fill a certain role (be it "we need another competent engineer who we can assign arbitrary work to"), and there are always other people that can do the same job.

If you take the tweet at face value, being dinged for a whiteboard exercise is pretty silly. But people do get hired for specific roles and just having demonstrated you're great at X doesn't mean you should clearly get hired for an only somewhat related Y.

I like to think I'm pretty good at certain things but that doesn't mean I'm a good candidate, especially at a senior level, for lots and lots of roles that, while somewhat related to my skills, aren't really in my wheelhouse.

Max Howell was applying for the binary tree reversal team?

Package manages often determine the success of an entire ecosystem. To give you an idea of how hard this is, Go still has not been able to come up with proper package management. Some of the best engineers in the world built that language.

> Package manages often determine the success of an entire ecosystem.

Nobody said it wasn't great, just that whether he is good to make a package manager, doesn't determine if he is a good fit for anything else. If that hiring position was to build a system to manage packages, sure, he is probably the best hire for that, but theses skills are specific to exactly this task.

A great interviewer though would have kept his contact information though and would have tried to put him somewhere else though. He may have not been a good fit for what they were looking for, but they can clearly use his skill in some ways some where else.

You're absolutely right. the best metric is to see how quickly he can reverse a binary tree. now that is grounds for instant dismissal !

macOS had multiple package managers prior to Homebrew.

And they sucked.

You're acting like all the engineers at Google work on search algorithms and incredibly research-focused work.

I bet you they still have the footsoldiers out there building consumer facing products. You're telling me the guy who built Homebrew can't sprinkle some awesome dev ux to some of Google's tools?

Reply on news.ycombinator.com