As the guy in charge of the DC office (and the google side of this at the time) - I happily would have hired you if I had headcount :-)

You did an amazing job.

(in fact, i specifically asked for HC intending to try to hire you a number of times, but at that point, the politics of getting resources in remote offices sucked)

Yes that seems to be how it works. https://twitter.com/mxcl/status/608682016205344768

"Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off."

My interview process with Google only made it to the technical phone screening because I didn't know the Big O complexity of read/write/sort for Trie structures. (https://en.wikipedia.org/wiki/Trie) The interviewer was pretty cool and we had an interesting technical discussion, so I wouldn't consider it a complete waste of time.

As a side note, I joined Google at age 39.

Given that he develops software that Google engineers use frequently, I wouldn't exactly say he is inflating his sense of importance.

It sounds like he is a good software developer who has developed something widely used and appreciated, but the Google hiring script doesn't deal well with those kind of people.

It takes a lot of time and effort to go through interviews, I don't blame the guy for being pissed off that Google wasted his time.

Calculator is a pretty widely used app, too, even by Google engineers. But that hardly qualifies the author to work at Google.

Similarly while Homebrew is widely used and fits a need, it doesn't mean that the author is equipped with the skills that Google wants. A package manager and something like Google Brain don't exactly share much in common. It doesn't mean Google's script failed nor does it mean he shouldn't be pissed off, it's just how things are sometimes.

So what if random Googlers could also have written it? They didn't.

I talk to people about interview stuff, I notice that most people who say "I shouldn't have to know X" seem to be the least intellectually curious, least great problem solvers and just generally combative folks. If you are going into an interview with a serious chip on your shoulder, demanding a job, asking to exempt yourself from having to show problem solving skills, then just how is that going to work out?

Regarding reversing a binary tree, yeah, the interviewer didn't expect you to know it. That's the point. It's something that's a little tricky, not impossible, requires you to be precise about memory ownership and pointers, and algorithmic. It takes no time at all to describe, and isn't impossible to solve. Yeah it's problem solving, but it's not random trivia. It's a functional test of your intelligence and yeah it filters out some who should be at Google, and they know it. However relaxing the bar is fraught with peril. You're quite literally banking the future of the company on it.

It's my opinion that wasn't an unreasonable assessment (from mxcl). Although if indeed nearly nobody at Google uses Homebrew, as now multiple people are claiming, it was, no matter how reasonable, wrong.

I think he saw the question, and basically just refused to grapple with it, thinking it was below him, and then the rest pretty much was inevitable.

The rest of your post is speculation.

No, you actually never earn that right. Seriously.

In fact, it's a sign of good engineers that they just view their stuff as stuff, and not "well, i am doing the super important stuff, everyone else is not".

Note that this is different than prioritizing, etc. If you have a bunch of high level engineers in a room, and they don't value each other's work (IE recognize that a lot of stuff is "important", and there stuff is just part of that) because they think the stuff they do is super-important, that's going to go very badly.

At lower levels, pretty much none of it is so important that there is any value to having an inflated opinion of self importance.

The fact that you've achieved adoption does not necessarily make you a good engineer.

Straw man argument. Nobody stated this.

There's also a difference between thinking that your stuff is super important in isolation versus simply pointing out it's in wide use at a company and hence your previous efforts have in fact been productive and useful for them.

This is pretty much exactly his attitude, even if he did not explicitly add the other 3 words.

"in wide use at a company and hence your previous efforts have in fact been productive and useful for them."

Except that assumes it's literally true. It's not, as a downvoted person said :)

It also assumes that him working on it would be useful or productive relative to doing something else. That is also probably a negative.

Why?

To quote one of the demotivational posters, "just because you are necessary doesn't mean you are important".

https://news.ycombinator.com/item?id=12662182

Cogs in a machine?

https://cdn.shopify.com/s/files/1/0535/6917/products/worthde...

He may be important as a person who has developed software used by a variety of people (including many at Google), but that doesn't mean he is someone who ought to be important for Google to employ.

The number of googlers with Macs is not even 90% so this line of argument is just silly.

Basically the internal dev environment is already fully complete and works great. It's ultra custom and there are strict rules about bringing in open source code. The AGPL and GPL3 are good, but also one has to be wary about them in a commercial environment.

But, hey feel free to judge someone for gasp having a sense of humor more complex than a fart joke.

This is actually a good point that there might be a strong bias in this towards fresh graduates who in most cases are younger folk.

I was contacted by Google several times but chose not to submit myself to an interview process which I feel is biased in favor of CS graduates and consists of exercises which provide little insight into the most important characteristic of a good software engineer; the ability to understand the nature of a given new domain, the problems to be solved in that domain, and good ways to solve those problems.

I cut my teeth on MIT's Computations Finite and Infinite by Minsky (now out of print), Donald Knuth's three volume classic, and later The Structure and Interpretation of Computer Programs, which, at least, I suppose recent CS graduates are familiar with. And many many books after those.

Over the subsequent decades I have developed many unique algorithms to solve specific problems. Most recently, the past month, I increased performance of a graph database issue by an order of magnitude by creating an abstract representation of the graph connections in RAM. That is not a terribly unique approach but somehow it never occurred to the CS types here that the cause of their performance problems was a failure to understand the fundamental nature of the problem being solved.

If Google's filtering consisted of solving a real-world problem, one requiring some days of research and development, then I'd be happy to go toe-to-toe with recent CS graduates. I know how to use The Google to find related domains, problems, and solutions. After understanding the nature of a problem research is step #1, regardless of whether I think I already know a good solution, it is almost always the case that someone has already solved a similar problem (if not the exact same problem), there is value in understanding the differences.

But I suppose that's not a practical filtering process for a company hiring many engineers and not having the resources to evaluate real solutions to real problems.

Also, side note, approximately 5% of the population do not imagine the same way the other 95% do. Like me they cannot, to varying degrees, actually visualize anything with their eyes closed. I never see anything but black with my eyes closed, when not dreaming. I suspect that this is related to my inability to do whiteboard exercises. I don't visualize, I think.

'nuff said

Even a simpler real world problem whereby it takes days of research is not respectful of your time. I've seen people note they can't take a 6 hour time-out of their busy work/home lives to do coding challenges that are popular among startups.

So the balance is in-person interviews. Ones where you have to give difficult problems, ones you haven't seen before and ones that don't take days to explain. This usually means algorithmic, data structures, or mathematical in nature. They have subtleness, depth and complexity. As for 'reverse a string', you'd be surprised how many people who have "programming jobs" who apparently can't do basic programming.

And do I use these skill sat my job here? Yes. All the time. I'll spare you the spiel about "everything's different at scale". Google is a different kind of company that attempts to solve as many problems as possible with CS.

For reference, I work at Google, given interviews here, and passed the interview bar twice. Once at 29 and once at 39. Some of my coworkers are older than me. Many of them have children. Some are younger than me. I see plenty of people in the office with grey hair (I work in the SF office).

I refuse to defend past practices, but I believe the company currently sincerely overall seeks to be the best employer for any age. Small pockets of suck happen, but the internal transfer rules let you switch without your manager's permission. The interview process is known to not be perfect, but that is inevitable for any process - nothing is ever perfect!

However, the interviews do involve whiteboard problem solving. I understand some can't do it, and this is one of the blind spots. I personally love diagrams, and think visually, so it works for me. I also prefer when my colleagues use diagrams as well.

About diagrams.

I had the whiteboard experience once and will avoid repeating it.

When I get a problem I want to sit back and think about it. The interviewers kept insisting that I draw diagrams, and that interrupted my thought process, they were not impressed.

However that does not mean I am incapable of making diagrams once I've sorted the problem out in my mind. After I've arrived at a proposed problem solution I like to produce a written document with just enough information to convey the problem and the solution approach, together with whatever diagrams, data structures, and pseudocode are required to communicate.

That's how I roll. ymmv :)

As a side note, I think there are fundamental limitations to "solve entire problem in mind" - tooling, including written word, pens, pencils, crayons, paper, documents, diagrams, whiteboards, provide methods for expanding your working memory.

One other thing "just enough information" is a phrase that worries me. I've seen a lot of academically written papers that basically "by implications you should know that the resulting answer is X". I'm not sure this is your style or not, but it is one style that personally I believe has no place in the workplace. Convey your ideas clearly, and help your coworkers.

With regard to your other two points I either wasn't clear or you took my comments too literally. Be that as it may, let me clarify.

I do form my entire impression of the problem and various solutions entirely in my mind, without the aid of external memory. However, and this is important, that evolves out of research. During research I build something like an intuitive understanding of the problem. Along the way I consider possible solutions to the evolving problem, solutions by others or that happen to occur to me. Eventually, usually at night when it's quiet, I have an insight, which often turns out to not be quite right. Rinse and repeat until I have something that seems good. At which point I will sketch out some data structures (as struct or object like things, or simple diagrams) and some pseudo code to operate over the data. If that finds a flaw in my idea I go back for more rinse and repeat cycles.

When I say "just enough information" I mean just enough for any engineer with sufficient experience and background to fully understand the problem and solution. I don't leave anything out, I want feedback and I don't want the feedback to be "huh?". By "sufficient experience and background" I am leaving open the possibility that there might be someone in the group who doesn't quite get it, but to tell the truth most good solutions to most problems turn out to be reasonably simple, simplicity is one of my target criteria. Simple solutions are easier to implement, less likely to have bugs, and if the solution is both simple and good the performance is likely to be at least acceptable as well.

Better? :)

The one thing I'll say is that with your background, it's a shame you filtered yourself out. You might not have gotten through the interview process, but if you retained anything significant from what you cut your teeth on you also might have been more successful than you think.

http://nautil.us/blog/why-blind-people-are-better-at-math

It seems that I'm better at doing math in my head than most people. I've wondered whether that might be related to aphantasia.