Max Howell's take on getting rejected by Google
quora.com
quora.com
It's bizarre, really.
Falsehoods programmers believe: all the best devs work at the Big Five.
I could get offers at Jane Street or Two Sigma for more money, doing potentially way more interesting things, but my mom isn’t going to brag to her friends about it.
This is notwithstanding that many people would likely recognize the prestige of those companies within tech and finance circles.
well, one answer is easy: resume material.
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*.
His skills align better with product management at Google more than software engineering though.
It's clear when software is written or designed by someone who cares about the user. Homebrew really is a great example of this.
Anyway, why does it take this much to say something we all know true? You don't have to be a good software engineer, a good team player, even a good person to be able to have a good idea for a program, execute it and it be popular. Homebrew was clearly key to people being able to develop on OSX.
What I don't understand is why some of you have beatified Max. Making something you like doesn't automatically speak to its or his technical merits. Trading on the name of your products might be able to get you through the door but shouldn't get you through interviews, alone.
He interviewed at somewhere where they demand you're an exceptional software engineer, academically and executionally. He's neither. The result isn't a shock.
Max Howell created something that everyone uses. He's made the world a better place for many (typically technically oriented) people. He's clearly talented and enjoys what he does(to maintain homebrew for that long?). He does not have a degree in Computer Science.
Google as an exclusive(as in there is a barrier to enter) community has all its rights reserved to reject or offer an invitation to anyone. They can set up (seemingly)arbitrary requirements and degree/knowledge in Computer Science seems to trumps all others. So they said no.(I'm just assuming that the reason behind the rejection was the trick question.)
The two statements can both be true without putting a shade on either. Google may have lost on getting a good talent working for them. With this debacle permanently looming on the web(especially since we're talking about it after few years), they have lost the prospective of working with Max Howell. Max Howell, by writing this now and back then, sabotaged the same prospective. Who will have lost in the end? I'd say Google by a small margin, because a good talent with an indisputable track record is sought for.
Most importantly, that doesn't mean he's going to make Google a better place, or that his skills will be usable at Google.
Second, I empathize with Max Howell's lack of formal CS education. I studied electrical engineering and a bit of software engineering. I attended a top 10 engineering university in the USA, but learning stuff like the nitty gritty of sorting is not part of the EE curriculum.
Fuck that, Quora.
I'd like to try this in an interview: how would you re-root a binary tree such that the ordering of the elements remains the same, but the root node of the tree changes.
That is way too many interviews. I don't think I would have lasted that long. After the second one I probably would have found the third one too much of a pain. But if you really want something I guess you do what it takes.
1> (defun invert (tree)
(if (atom tree)
tree
(list (invert (cadr tree)) (invert (car tree)))))
invert
2> (invert '(((1 2) (3 4)) ((5 6) (7 8))))
(((8 7) (6 5)) ((4 3) (2 1)))
What are the real requirements?
Bonus points for building a #lang for expressing trees and operations on them.
(note: this probably wouldn't actually get you bonus points, and might result in my wildly gesticulating to get your attention to try to drag you back to the actual interview)
A Google interviewer expects you to ask questions and clarify any simplifying assumptions you may have made.
For eg: Are you assuming right at the beginning that the entire tree fits in memory? If so, Google interviewers expect you to clarify that at the beginning. They might later ask you to modify your solution for cases where your assumptions don't hold true.
From what I know, the biggest mistake people make during tech interviews with the big 5 is directly jumping to solutions without probing deeper. At the scale at which the big 5 operate, many routinely simple assumptions can be problematic.
How about just working with the original tree the way it is and just traversing it in reverse order, if necessary.
I would probably ask if this is in-place or do we treat the input tree as immutable.
…that's what the parent comment is implying. Ask questions and don't assume things.
Asking too many questions sounds like you're trying to delay coding something up.
Suppose you just ask questions and they pile on more the requirements. Then the combination of requirements makes it so hard that you can't really code anything on a whiteboard. You're hosed.
If you incrementally prototype, at least you arrive at the same point having some iterations of code on the whiteboard.
Trust me, the interviewer is never gonna pile up requirements on you. In fact, they are trained to ensure that what they ask can be completed in the time allotted (with time to spare for candidate's questions). More often than not, when you ask clarifying questions, you will end up with a much different problem (and sometimes simpler) than what you expected.
> Asking too many questions sounds like you're trying to delay coding something up.
No it doesn't.
> If you can code a prototype as fast as asking question, why not. Code it up and then ask, "how about this: what requirements are missing from this that require changes or a rewrite?"
This is terrible, you are now making the interviewer do your work. You need to tell the interviewer what the boundary conditions of your solution are. That gives valuable data about your understanding of the solution space.
To clarify, by "what requirements are missing" I don't mean "what is wrong with my code" (as in, in what way does it not meet the requirements that were already given; please debug my code for missed requirements). Of course the properties of the solution are clear and remarks are made about that in the course of writing it up and discussing. The "what requirements are missing" question is purely about new/different requirements.
In my experience, if you write boilerplate you'd need to write anyways while asking these questions interviewers don't hold it against you.
No, Google shouldn't have hired him, and he made it very clear why: he's a dick.
Related discussion:
Either option and many more are possible. All the ones I can think of suggest that Google's hiring and transfer process needs work.
In the UK employer-maintained blacklists are illegal http://www.bbc.co.uk/news/business-36242312
I don't know Howell, but that reads more as light self-deprecation than an admission of genuine toxicity.
People who avoid that usually have nothing to tell.
Google shouldn't have... followed their own guidelines?
To say someone should have, is to say they would regret it.
Google isn't a person. And they most certainly will not regret a thing...
The linked article draws more differences than similarities as far as I can tell. Max Howell readily admits weakness before pride. He brags outwardly at the end of his message, which was a little distasteful, but it was after he widely incriminated the project he is bragging about. The linked article describes a very different type of person. People are rarely so simple.
There are many depths of info and systems available for concieving/understanding personality types and archetypes. Reply if you’d like some recs.
That seems like a pretty clear assessment to me.
There is a lot wrong with that article and it should not be used as a reference for this subject.
The tweet was well written.
And brew, well, yah, well written.
Thanks Max for making the missing package manager for macOS. I use it, I taught my kids to use it and will probably keep using it for the next decade. Thanks!
And Google?
Who cares about google. It is Apple that should have hired Max. Years ago. For making their product better.
YouTube, though mature, is still important for profit growth within the company.
There is undoubtedly duplication within the company, but I don’t know of a simple solution for it.
Max was passed over because of the engineering interview process at Google, which hasn’t changed for a decade. It is orthogonal to recent developments within the company.
I agree with Max, but I don’t think there’s anything more to read into it other than the fact that Google is extremely risk-averse to making bad hires. Part of this is due to an almost government-employee-level of process related to performance-related firings. An employee could likely be idle for a year before being fired.
So the hiring process is a rational response to a highly irrational retention policy.