Hacker News Reader

Comment by eru | Hacker News Reader

I was working for Google at the time, and saw an internal post by the guy who interviewed the candidate.

I'm not sure if there's anything public (and what I am even allowed to say.)

See https://www.quora.com/Whats-the-logic-behind-Google-rejectin... where he (at least partially) admits that he was bullshitting:

> I want to defend Google, for one I wasn't even inverting a binary tree, I wasn’t very clear what a binary tree was.

View on HN

That was interesting.

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

To me at least, being a dick is a negative that outweighs making good things, especially for a large organization. Maybe google made the right call.

Right, Google actually has a 'no jerks' policy and values being a good team player more than pure technical brilliance. Being a good engineer gets you L4 (mid) or low L5 level at Google. Growing beyond that is mostly about soft skills and influencing other people - that's not compatible with being a dick. It probably wasn't the case for him in 2015 yet, but these days google has a mandatory 'googleyness' behavioral round that the guy would fail hard with that attitude even if he could invert the proverbial binary tree.

I joined in 2014 as L4 (I think), and I remember having some googleyness interviews even back then.

But I could be remembering wrong.

I dont think its unique to google that companies want to filter out people who are "dicks". Every company i have ever had an interview at has done behavioural interviews for that purpose.

I highly recommend interested readers to follow through to the Quora page. It’s more or less a public apology, and helped break me out of the echo chamber that occurs here and on Reddit related to interviewing at Google.

It looks like there are a bunch of programmers who think that having taken the first year uni course on data structures is more important than having experience actually building product and having it used by millions.

It's kind of silly. Most programmers out of school have a lot to learn about building product and actually getting a big project done - which they are supposed to learn on the job. At a place like Google. Somebody who knows this part already could probably spend some time on the job learning about data structures.

It's like these conventionally-taught programmers think they get to look down on somebody who actually built something cuz he's self-taught. (As a conventionally-taught programmer who is very comfortable with data structures I find that attitude aloof at best)

I have a traditional Computer Science background and I'm still intimidated to even apply to Google. I got out of bigCo Software Engineering in part because I wasn't interested in putting myself through the wringer of whiteboarding memorized solutions.

I'm also the guy that found low hanging fruit in a huge codebase to replace things like frequent linear array lookups with hash table lookups for 10x+ speed improvements in the build process. This is IMO precisely the type of capability that "Oh, that's O(n^2), surely we can do better. Is there any way to do this in O(1)?" is designed to tease out in the interview process. I did it! In a build process effecting 1000+ engineers, used to build for millions of shipped units! But talking about this in an interview makes eyes gloss over as we prepare to move on to sort algorithm trivia, how would I design search, or doubly linked list implementations.

But you know, hash tables have O(n) access...

And this is where interviewing gets hard. Are we really going to not hire someone because hash table is O(n) in the worst case but O(1) on average. It seems like half the time there isnt a match, the interviewer is just as wrong as the candidate, and they are looking for someone who knows the same info as them, even if its half baked.

Some implementations have O(n) access in the worst case.

Often people are interested in something like the 99.9999%ile case. And, of course, you can design hash tables with better worst case behaviour.

It's almost trivial to get a hash table with O(log n) worst case access: when you have a collision, just resolve it with a tree instead of a linked list.

With some more fancy math, you can also get O(1) amortized worst case behaviour with arbitrarily high probability that doesn't depend on your input data.

See https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

> It looks like there are a bunch of programmers who think that having taken the first year uni course on data structures is more important than having experience actually building product and having it used by millions.

To be honest, drilling down on all the stuff they teach you in first year helps you more in getting a job at Google than having lots of practical experience.

I'm inclined to believe that this is a problem with Google. But I am not sure you should trust my opinion: I am sure Google spent much more time and money and figuring out the right approach here than I ever laid my hands on in my whole life.

he wasn't "bullshitting", you didn't get the point of his tweet and quora post and I think you're kinda proving his point.

He wasn't "bullshitting" indeed. He was straight up lying. And his lie poisoned the thinking of millions (myself included) wrt. tech interviews.

My opinion of the guy just dropped hard.

Reply on news.ycombinator.com