Hacker News Reader

Comment by jakelazaroff | Hacker News Reader

Max Howell (the creator of Homebrew) famously was rejected from Google for failing some technical interview puzzle. [1] And it wasn’t before he created Homebrew — the interviewers knew that most of their employees used his software! I have no idea what his skills are like — maybe he can’t invert a binary tree, maybe the Homebrew code was bad, I don’t know. But either way, he wrote some code that was giving a lot of value to a lot of people.

I know a rejection or two or ten can start to pick at your self confidence. But a technical interview is so far removed from what makes you a good developer that you need to resist the urge to judge yourself on that basis.

[1] https://twitter.com/mxcl/status/608682016205344768

View on HN

We have no idea why Max Howell was rejected. Only the interviewing team knows that. Maybe there were a variety of other problems. Maybe he came off as a complete asshole during interviews. Often not knowing something is fine during an interview, sometimes the point of the interview is to see if you can ask good questions and collaborate with the interviewers, take advice, without becoming defensive or combative.

Even if feedback was given after his interview, it's often the case that the real reasons are too sensitive or controversial to feed back.

You can't trust a candidate when they complain about why they were rejected. They really don't know.

> Often not knowing something is fine during an interview

No it's not, from my experience. I've had Google jackasses push away from the desk during interviews chuckling "how much do you program?" when you don't know their pet quiz.

(The answer to the last question "is more than you", but ashamed I've never said that)

The prick culture at Google is entrenched. I (jokingly) blame Stanford.

> You can't trust a candidate when they complain about why they were rejected. They really don't know.

Sure they know. One or more people didn't like them. Oh, but there's nuance, details and such, but it usually boils down to one simple - someone didn't like you as a person.

This is absolute bullshit. I have been part of many panels at Amazon, and subjective criteria like this just doesn't happen.

I haven't conducted a single interview where time wasn't an issue, so I guarantee you that there is just no time to like or dislike the candidate.

What kind of opinion about "likeness" do you think I can form about a person when I have to ask them intense questions over an hour?

Yeah I probably won't like a candidate that is obviously way below the hiring bar, and I will probably like a candidate that provides solid answers to all my questions. That doesn't change at all the outcome of the interview.

> You can't trust a candidate when they complain about why they were rejected. They really don't know.

> Yeah I probably won't like a candidate that is obviously way below the hiring bar, and I will probably like a candidate that provides solid answers to all my questions.

So, which one is it? Do you have time to like/dislike a person, or not?

> That doesn't change at all the outcome of the interview.

It clearly does.

> So, which one is it? Do you have time to like/dislike a person, or not?

No, you don't, not for what you are talking about which is their personality.

You will like their skills or dislike their lack of skills, which is what is being evaluated.

After working in the industry it is easy to realize that "code providing a lot of value to a lot of people" does not at all mean "good code".

When I was 15 I had a website with 80,000 members, yet my code was shit and any company would be simply reckless to hire me. I had a friend that worked on World of Warcraft private servers code when he was also a teen, it was used by millions back then, and yet he told me he was doing little more than copy-pasting code from somewhere else until it worked.

For small teams and solo developers, compared to having business value, the importance of having good code is not even secondary, it's barely a concern at all. For a big company like Google, priorities are slightly different because they have the scale and the team that allows it.

I would be willing to bet that a lot of the code produced at large companies is not very good either, honestly.

Almost every company I've ever been at, code quality is a far down the list concerns for the business and that winds up infecting the dev team as well who is constantly scrambling to hit deadlines and produce business value.

Some of these companies have been in business making money on these shoddy codebases for decades.

Yeah, I can second this. I worked at a big company popular on this board and while all the devs there were obviously absurdly talented, the general level of code quality was... not good. And it's specifically because management prioritized shipping features over literally anything else, so any time you spent on designing or refactoring was a negative mark on your perf sheet (since that's then a gap where you weren't shipping anything).

Maybe the secret sauce is that if you hire good devs and make them write bad code, the code is still workable and is just a huge PITA to figure dev work instead of being totally intractable?

I think this is basically exactly it. Everyone needs to hire the best, 10x, rockstar ninja programmers that they can find. They find the people who, given time, could build absolutely amazing high quality systems.

They have to try and find those people because they can still produce working, somewhat maintainable systems in less time.

And all companies just want to give less time to build things.

At some point clean code doesn't really exist. I mean, after eliminate this two big cases; a too big function and too deep(inheritance)/wide(composition) indirection. Is pipe only function clean? I don't know, I think it's sometimes.

Homebrew is an awful system, it's the exact opposite of what should be held up as an example of a well engineered "packaging system". It's not even a proper package management system anyway, and there are far, far better systems for Mac OS X. The whole "dump everything into /usr/local" is absolutely insane, and it's depressing that the development community on OS X has fallen for it.

Does it solve the problem?

Ray of sunshine aren’t ya :’)

Homebrew on Apple Silicon is finally at /opt/homebrew instead.

One not very sane decision tho is choosing to not require sudo for package installations but have /usr/local or /opt/homebrew writable for more than just root.

And yet it’s by far the most popular, easiest to use, and solves the most number of problems for the most number of people. Millions of hours of saved dev time over the years. That’s well engineered to me - engineered for users, not purity.

While many people would agree that value to users is more important than "pure" engineering/code quality, moving the goalposts doesn't nullify the GP's point. If Google was hiring to acquire Homebrew (assuming it was possible) then value to users would be a factor to consider. But if they were just hiring the person to work on non-homebrew projects, why wouldn't "pure" engineering quality be relevant?

Do the projects at Google not also have to provide value to people? Given the number of products they kill, you’d think that would be a higher priority.

In the decade or so that I’ve used it, it’s pretty much always done exactly what I’ve needed it to with no negative side effects. What else am I supposed to want out of it?

It's OK-good. 95% of the time it just works. One thing I would love is a feature like AppCleaner to know where was dependencies were installed before they are removed. Maybe it's already capable of but I didn't know how.

This interview, what the public knows about it at least, gets brought up a lot. A package manager is a very simple system to write. Brew is very successful, and creating it certainly shows extremely good taste compared to most engineers.

But there are only so many positions for engineers with good taste to work on simple systems. Google was almost certainly looking for engineers who can build and understand large distributed systems and non-trivial algorithms. Inverting a binary tree is basically asking someone if they understand recursion. If he can't clear that bar, there will be algorithms that come up during normal work which, based on the interview, he couldn't be expected to understand.

That's all fine. I wouldn't hire him either, but I still like brew.

Yeah. If he's capable of building good stuff, but couldn't invert a binary tree, it suggests strongly that he didn't even bother to do a minimal amount of preparation, and Google is not unreasonable at all to want to filter out people who don't do that.

in 17 years of professional software development I've used a binary tree exactly zero times

Same. I wrote many AI stuff during 2007-2011. After that, in industry, I use Boolean Algebra Simplification once to undo if-else hell of legacy code. It's always fixing tooling shit and third party apis/accounts/permission madness. No way I can balance a AVL tree now (give me at least 3 days)

That's not the point. The point is that if someone can't do some of the easier Leetcode style problems, they probably didn't try to prepare at all, and that can be viewed as arrogant or lazy.

I'm not disputing that binary trees might not be the most practical topic (especially inverting them).

However, given that one knows that is the sort of coding interview Google conducts, one should reasonably be expected to practice that sort of interview. Inverting a binary tree isn't hard; it doesn't take much practice with binary trees to realize how to do that. So if someone can't do that, they probably didn't practice at all. And if someone didn't practice at all, an employer is acting within reason if they draw some negative inferences from that.

Maybe you've never used a binary tree on the job to store information. If you've ever written a recursive function with two recursive calls, the call graph is a binary tree. The interview problem "invert a binary tree", is more of a litmus test for understanding recursion, which is a fairly basic knowledge item for an SE.

Reply on news.ycombinator.com