And people actually try to emulate their interview practises.
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.
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.
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.
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.
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.
Furthermore, for L5 and up Google is most certainly looking for systems design and engineering leadership skills.
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".
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".
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.
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.
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?
Sebastian McKenzie @sebmck Facebook Got rejected from a junior position at Atlassian for not knowing enough about JavaScript. Shortly after they now use the JavaScript compiler that I wrote across most of their JavaScript stack.
Or
Ian Devlin @iandevlin Trivago Rejected by the Google HTML5 Developer Expert programme for not knowing enough about HTML5. Apparently being one of the HTML5 Doctors, writing many articles on the subject and having a book on HTML5 Multimedia being published wasn't enough for them.
Or that's what he claimed.
> Even though they all run it internally.
That's what he claimed as well. But never heard of Homebrew while I was at Google, though I had a Macbook for 5+ years. (Well I can't definitely say my Macbook never ran Homebrew - after all, when you are in Google, all such things are handled by dedicated teams. But I can definitely tell that this "scandal" was the first time I heard about Homebrew.)
Not trying to take him down - I'm now in a different company and use Homebrew quite happily, but it's simply not true that it was widely used inside Google.
So maybe the Google people didn't make the wrong decision after all.
You don't go through the whole process. I can't remember the exact numbers, but iirc the logic is that offer decisions are made on 5 pieces of feedback. If you interview at Google you get a total of 5 interviews. If you're an intern, your intern manager and two peers write feedback, so they need 2 other people to interview you and give a thumbs up.
If you think about it, this is kinda nuts. They're hiring someone to do a job. They have them do that job for 3 months. Yet, rather than fully basing their decision on wether that person is good at the job they will actually be doing, they instead opt for also putting you through coding interview questions.
I haven't heard of another company that does this. I know others also want several opinions, so they just assign more peer/manager reviewers.
The sad part is I know interns who suspect this might well be why they didn't get a return offer-- interviewing is nerve-wrecking for some people, and it can be hard to get up to speed especially because towards the end of the summer recruiting season and early school to-dos start to pile up on top of finishing your intern project.
Please read the above. It contains an updated opinion from the creator of homebrew and is more relevant.
It also contains responses from people who worked at google and were or are part of the hiring process.
I don’t even try to memorize the APIs any more. I kind of keep an inventory of what’s available and just google or read the source to figure out what it’s called this week and what it does with undefined or optional arguments.
We all know I’ll be using a new API in a year or two anyway...
https://www.forbes.com/sites/falonfatemi/2016/09/28/the-true...
This is a myth. There's no good reason to believe he didn't get the job for that reason, other than his claim.
If a genius circuit design engineer from Intel would apply to Google's SWE position, they would be rejected as well, despite Google running on Intel's servers.
It seems more likely that he was shaky in his other interviews which all added up to him being rejected. If you're an interviewer and the interviewee is doing poorly, do you tell them they're failing? I certainly don't.
I bet many Google projects also use `leftpad` internally.
You no longer study? You stopped any form of education? I have an hard time believing that's actually true, but if it is, I guess you aren't a good fit for them either.
I read on new technologies constantly, I learn new languages constantly, I haven't gone to any formation yet (I just finished my software engineering degree) but I will certainly. Continous learning is nothing new.
They need someone able to adapt, which does means learn, and clearly in the case of Google, pretty quickly too. Studying to pass their interview process is no different than studying to apply X new principle.
Oh please.
I've always taught myself new concepts and am constantly reading books and learning new languages. Hell, I went from working in "big corporate" to starting my own business building video games, something I knew virtually nothing about because I was driven to do so. I learned Rust on my own, I taught myself 3D programming, I've taken classes on public speaking. These are things I didn't need to prove to anyone, I just felt motivated to because I felt it would benefit my career.
> Studying to pass their interview process is no different than studying to apply X new principle.
The fact there are websites dedicated to helping you study for Google's interview process means something is broken. You should be able to gauge a person's motivation and willingness to learn beyond knowing seven different algorithms from memory. If they want someone who can adapt, look to experience and have questions ready to prove that experience. I shouldn't need to recall information like flash cards. Applying to Google feels like studying for the SATs all over again.
Two cents. Google isn't for me despite feeling I could make a big impact there knowing my motivation levels and work ethic. I highly discourage anyone from adapting a similar interview process.
If anything you’re convincing me this webpage was a good idea!