Live data from Hacker News

Max Howell's take on getting rejected by Google

quora.com

61–70 of 73 posts

Re: Max Howell's take on getting rejected by Google

#61
I still don't get why this is still an issue.

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.

Re: Max Howell's take on getting rejected by Google

#62

Earlier quoted context omitted.

> 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.

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?" 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 any…

I'm sorry, this is terrible advice.

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.

Re: Max Howell's take on getting rejected by Google

#63

Earlier quoted context omitted.

> 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.

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?" 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 any…

> Asking too many questions sounds like you're trying to delay coding something up.

In my experience, if you write boilerplate you'd need to write anyways while asking these questions interviewers don't hold it against you.

Re: Max Howell's take on getting rejected by Google

#64
I can't be the only non-OSX/MacOS user in here wondering who the hell Max Howell is, right? I've looked it up since.

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.

Re: Max Howell's take on getting rejected by Google

#65
post #16
post #15

Earlier quoted context omitted.

At least in my experience, the real dicks you want to avoid would never casually call themselves dicks. I don't know Howell, but that reads more as light self-deprecation than an admission of genuine toxicity.

The biggest dicks are the smooth guys who always say the right things and never take a position.

Or worse, who say the right things, never take a position in front of you, and then stab you in the back when you're not around.

Re: Max Howell's take on getting rejected by Google

#66
post #54
post #15

Earlier quoted context omitted.

At least in my experience, the real dicks you want to avoid would never casually call themselves dicks. I don't know Howell, but that reads more as light self-deprecation than an admission of genuine toxicity.

in my experience at least some of those who openly/seriously call themselves dicks are low-level sadists that just enjoy being abusive or insensitive and use the "self-aware" commentary as an equivalent to the standard "inb4" forum post (ie "inb4 i'm a dick").

Insensitive to who? Themselves?

Re: Max Howell's take on getting rejected by Google

#67
post #15
post #3

But ultimately, should Google have hired me? Yes, absolutely yes. I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them. Surely, surely Google could have used that. No, Google shouldn't have hired him, and he made it very clear why: he's a dick. Related discussion: https://news.ycombinator.com/item?id=1…

At least in my experience, the real dicks you want to avoid would never casually call themselves dicks. I don't know Howell, but that reads more as light self-deprecation than an admission of genuine toxicity.

I've worked with many dicks I never want to work with again who proudly call themselves dicks.

Re: Max Howell's take on getting rejected by Google

#68
post #62

Earlier quoted context omitted.

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?" 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 any…

I'm sorry, this is terrible advice. 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 quest…

> you are now making the interviewer do your work.

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.

Re: Max Howell's take on getting rejected by Google

#69
post #61

I still don't get why this is still an issue. 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…

> He's made the world a better place for many

Most importantly, that doesn't mean he's going to make Google a better place, or that his skills will be usable at Google.

Re: Max Howell's take on getting rejected by Google

#70
post #26
post #2

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*. I love that he calls out Homebrew not being a technical marve…

I wholeheartedly agree. If there is one thing I'd like Google to change is to think about and care for their users.

Well, that's probably why he wasn't hired.
Post reply on HN