Why I Don’t Talk to Google Recruiters

Consulting firms and investment banks recruit plenty out of my alma mater, UCLA (a public, state university that isn't considered part of the Ivy Plus). They did the same at University of Texas, where I went to graduate school, another public, state university.

No problem, whats a good email for you?

Edit: heck with it, I've got nothing to hide. Enjoy: https://www.fuzzy-logic.org/file/Lee_Whalen_Resume.pdf

So folks don't abuse my poor auto-responder, here's what would happen if you hit the email in that resume: http://bit.ly/2lxsly3

> I very much doubt that many of the people (broadly) deciding which products to support and which to drop were hired via a new-grad-like interview process.

I'm confused as to why you doubt that. Google's been around for almost 20 years. Their interviewing process has been around since at least 2003.[1] It's 100% possible that somebody was hired, ended up in higher management, and graduated to making driving decisions (at least over a particular area) in that time, unless your suggestion is that nobody who enters as a new grad ever stays long enough to get to that level, which at Google (vs other SV companies) seems unlikely.

[1] http://jeremy.zawodny.com/blog/archives/000616.html

> For things like moonshots/other bets, the "build something awesome but don't monetize it" makes a lot of sense, since the entire point of that division seems to be "build something awesome and see if it is sustainable too". More often than not, unfortunately, the answer is no.

It does make sense, it's more the messaging around those kinds of projects that tends to get lost. You end up in situations where thousands or sometimes millions of users are relying on a "beta" product, which has no monetization strategy, and then gets scrapped. It's a pattern that's still unpleasant for end users and not great for Google's reputation.

> If we presuppose that there is this dichotomy in people and it affect google's motives and goals as a company, then this would influence the tech hiring practices to be the way they are, not vice versa.

That's a great point, and likely, assuming of course that Google started this way (I think it likely did, given its founders' backgrounds). It creates a self-perpetuating cycle, though, which still ends up being problematic.

> It's about as relevant as implementing quicksort.

...did you actually read my comment? Because I went on to say that I didn't think it was relevant.

That said, understanding how quicksort works is important, not because you'll be called on to implement it, but because there are key strategies used in its implementation.

And yes, I can implement quicksort without looking up the algorithm. It's really not that hard.

> Or it's actually a javascript event handler that is doing something else expensive per char delete. It's more important to know to profile rather than try to memorize every algorithm used by a system and guess which one is causing the problem. Once you identify where the bottleneck is, you can search for "efficient algorithms to do X".

Sorry, but no, wrong answer. Partial credit for suggesting profiling. Let me take this apart:

> Or it's actually a javascript event handler that is doing something else expensive per char delete.

If they're calling a function that triggers an event handler for every character deletion when they're deleting a block of text, then they're Doing It Wrong. Yes, profiling is important. But calling delete one character at a time for a block of text is plain lazy.

> Memorize every algorithm used by a system

Umm....this is a text editor we're talking about. There are very few algorithms, and it shouldn't be a case of "memorize them" as much as "observe them." If there are more than 3-4 algorithms, then it should also include "draw a picture of how they interact," if your abilities at modeling them in your head are insufficient.

But someone who is strong at algorithms should be able to just see what's wrong with a text editor that deletes characters one at a time. It should be obvious that it's likely to be a problem, and they shouldn't do it to begin with.

> People who profile and fix bottlenecks are much more valuable than people who think they have implemented the most efficient algorithm for every operation in their program.

Both are necessary, and as I've said elsewhere, "developers that are anal about optimizing everything" is a straw man; good developers know when optimization is important, and good developers can write more optimal code without making it harder to read. Just knowing how to optimize doesn't automatically make you optimize every single routine, nor does it mean everything is more complex. Half the time when I optimize something the code ends up cleaner and easier to read, in fact.

And it's not always about bottlenecks. Sometimes it really is about the algorithm, and if you don't know your algorithms, you won't be able to recognize this. As said above, it's a prime example of the Dunning-Kruger effect: If you don't know algorithms, you don't even know what you don't know. Claiming you don't need to know algorithms just reinforces the point. Sorry.

In another comment on this post I described an optimization that I did that had no easy-to-fix bottleneck that was slowing things down, and that required a high level algorithmic change to fix. [1] In about an hour I sped it up by a factor of about a thousand. Ultimately I was doing the same things, but I was able to improve the algorithmic efficiency.

And someone strictly looking for bottlenecks can look at that code forever and not see the algorithmic change needed, because the code itself was written to be pretty optimal; it was a high level change to the algorithm that made it so much faster.

[1] https://news.ycombinator.com/item?id=13701931

I do think that hard work and preparation can land you a job at these companies. I went from doing a manual labor job and never making over $33k/yr, to busting my hump 4 years in University to land these jobs. I also recognize that interviewing is its own skill that needs to be worked at, and simply doing LeetCode questions or reading Intro to Algorithms by CLRS isn't everything. I can honestly say that I have never had all the interviews go my way during a loop. I have been given problems where I could only find the naive solution. I have been in an interview where I made it through the first teaser question to be completely stumped by the second question. And I have made really ridiculous coding mistakes like increment the string variable instead of the index variable. But I also manage to never beat myself up about these mistakes, always talk about what I'm thinking during the interview, listen and try to apply the hints that the interviewer gives me, and have pleasantries with the other person during the interview. I dress well, always with a fresh haircut and clean shaved face, wear deodorant and take a shower the morning of an interview, and walk with good posture, because I do think that these things matter.

I do also believe in the interviewer anti-loop (see Steve Yegge's blog[1]), but I also think that it doesn't really matter unless you really want to work for a specific one of these large tech companies.

I currently work at Microsoft and just finished interviewing with a couple of the other large tech companies and have pending offers from them. I don't know, maybe I am smart, but when I see people like Andrei Alexandrescu or Mark Russinovich speak, or watch a video of Grace Hopper explain how she demo'd nanoseconds to military generals, I feel like an idiot compared to those people. I personally think you obviously have to have problem solving skills, but also gumption and a can-do attitude goes a long way.

[1] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...