Hacker News Reader

Comment by philip1209 | Hacker News Reader

The maintainer's tweet about interviewing at Google is one of my favorites:

https://mobile.twitter.com/mxcl/status/608682016205344768?la...

I love that one. I now regularly use "invert a binary tree" as a proxy joke for "let's grill you at a whiteboard with algorithmic puzzles that we never use in practice here but they make a great reason for us to belittle and laugh at you for not being desperate enough to drill these kind of questions for months before coming here"

This is the thing that always confuses me. Google is a company that we all associate with a fairly high quality of technical work, and yet they still appear to use as interview questions what we'd all consider to be really poor proxies for on-the-job performance. I can't seem to reconcile those two things.

That's easy enough: Google is sufficiently big and well known that even if they have an alarmingly high false negative rate, they will never run out applicants, and "weeding out" even a lot of high quality applicants doesn't substantially reduce the average competence of the remaining pool. And the company is big enough that it can absorb the occasional false positive as well, especially when it comes to people who know their algorithms but not, say, how to work on a team effectively.

I dunno--to me that rant hints at a potential inability to take rejection well. No matter what company you're talking about, getting hired has a luck-based component, so you shouldn't take rejection personally. I've probably been turned down for 99% of the jobs I've applied for in my career. If I opened Twitter to rage every time someone told me "no" I'd sound like a lunatic.

In my view, the correct response to being turned down at a company where I want to work is to simply try again later. No need to stress about it.

You have applied for 99 jobs for every 1 that you've accepted?

I think that is rare.

Throughout my 20 year career? Of course! Probably more than 99:1. I’ve applied to many hundreds of jobs through the years.

The problem with your view is that you're basically expecting everyone to be robots. I entirely can understand needing to vent like that after not getting a job for a very, very stupid reason.

One of my less-favorite things is how many people always pop up to defend the Google approach and argue that if he couldn't pass such an interview he must by definition not be qualified.

Possible points for the defense:

- He may be qualified to work at Google, but that's not apparent just because he created Homebrew, right?

- Google can afford to be picky enough to miss out on popular open-source project authors who _can't_ code on the whiteboard in favor of those who _can_ -- can we argue that they should reverse this, or just that in certain cases potentially-qualified people fall through the cracks?

I get that the response to this will be "they make $INFINITY as-is", but yes, I'd be willing to argue that they should reverse that. My basic argument would look something like:

A) Writing algos on a whiteboard is not the be-all end-all of actual programming

B) The skill set of "can identify things that people want and need and actually implement them" is a useful one that the person who created one of the most widely used pieces of OSS out there has demonstrated they have.

C) There's no evidence that I know of that indicates that whiteboard algo writing correlates with the skill set identified in B, and a fair amount of anecdotal evidence that suggests they aren't correlated. (And there are a range of other skills that are useful for an engineer or someone leading teams of engineers that are similarly not correlated with whiteboard algo writing.)

D) Firms benefit from diversity. Gender-diverse and ethnically-diverse companies are more likely to out-perform less diverse companies.[1] I don't have specific evidence for it, but I suspect that a firm that has a hiring process that brings in people with multiple diverse skill sets will eventually perform better than a firm that only brings in employees with tightly focused, highly similar skill sets.

And to respond to the "well, FB/Amazon/Google make $INFINITY as-is, so nyah-nyah", I would say that those companies are in market-dominant positions now that may make their math on hiring a diverse array of skill sets different from a theoretical firm, but I also suspect that maintaining those dominant positions will be more difficult with an engineering corps that is solely selected on a narrow band of proficiencies.

So, I'm not necessarily saying that Google should change their policy (although I do feel comfortable saying that any company that isn't in that rarified air that decides to copy that policy is making a serious mistake), but I think there's a pretty solid case for why they should at least acknowledge that there are people for whom they should make exceptions and possibly completely reverse that policy and overhaul their hiring process to achieve a broader range of skills among their engineers.

[1]: https://www.mckinsey.com/business-functions/organization/our...

For a lot of the people Google needs to hire to write Google-scale code, maybe "can identify things that people want and need and actually implement them"" isn't a particularly useful skillset _to Google_, but the skill set of "ingrained knowledge of data structures useful to writing scalable, low-level code" is.

I do agree that the "make things people want" is a very useful/desirable skillset for a vast array of non-Google-scale companies, and I'd personally prefer to work for a company that values this.

But I'm willing to posit that at a certain software engineering scale, the problems and valued traits are very different, and may align more with "knows data structures" than "can make something people want".

I'm not saying Google should value one to the exclusion of the other. But perhaps if you have Google's talent pool, the base level is "ingrained data structure knowledge" (correlating to engineering skills they need), and they'll also get the "ingrained data structure knowledge AND ability to make something people want" applicants.

I'm not arguing that other companies should do this. Just exploring whether it makes more sense for Google than perhaps we would think.

Sure, that's what I was trying to convey in the paragraph after D. That said, I think that even for a company Google's size, having those different skill sets will be useful as your business ages. Google will probably always need a number of people that have memorized every data structure known to humanity, but they would probably be better set up to avoid stagnation and continue in a position of market dominance into the future if they also have a set of people who can come up with new things and implement them.

But also maybe it's better that those people don't end up at Google et al. and that these gigantic companies stagnate and eventually die because their corporate bureaucracy/scar tissue prevents them from hiring the people who can prevent them from stagnating and dying? I dunno, haven't really fleshed this idea out too much.

> Google will probably always need a number of people that have memorized every data structure known to humanity, but they would probably be better set up to avoid stagnation and continue in a position of market dominance into the future if they also have a set of people who can come up with new things and implement them.

Yep, agreed! But since there's probably some overlap in that candidate skillset Venn diagram, maybe they're getting the people that can do both, and the data-structure skillset's the one that's possible to consistently interview for.

It’s not complete crap - the cost of a bad hire is a lot more than the cost of missing out on a good one.

Except that implies that someone who remembers how to invert a binary tree but doesn't have an open track record is a better hire than someone who couldn't remember but created, maintains and improves a popular open source project for YEARS.

Working software should be prioritised over rote memorisation of data structure theory.

It also implies that just because you can invert a binary tree on a whiteboard you’re actually good. That’s debatable but I guess it’s one of N filters.

When I interviewed at Google they asked a lot of (at the time) very specific questions about various languages but only 1 “solve this riddle” type question. It was a pretty good experience.

The best interview I ever did was with an investment bank where I was struggling to whiteboard some problem (after a string of really tough, challenging problems I did well at) and they let me use a terminal to actually code it up (which I managed to do very quickly). I got that offer. ;)

I can count the number of times I've needed to implement any binary tree algorithms on one hand. And they've all been either homework when I was in undergrad, or job interviews.

That said, I'm pretty sure that interview questions like these are not about whether or not someone is qualified to do the job they're actually doing, and 100% about companies trying to come up with a standardized, one size fits all tech interview that can be used for every position. Since the intersection of necessary skills for all kinds of developer jobs is something close to {"understands values vs. references", "knows at least 1 programming language"}, though, the result of any such endeavor is going to involve a lot of noise.

It works for Google because they're such an attractive employer that they're dealing with essentially zero risk that they accidentally filter out all their qualified applicants with stuff like this. It probably even helps company morale by fostering a perception among Google employees that they are an elect few.

>works for Google because they're such an attractive employer that they're dealing with essentially zero risk that they accidentally filter out all their qualified applicants with stuff like this

You know the founder of homebrew was filtered out by exactly this, right?

Yeah, that's the context of this thread.

I said that there's minimal risk that they filter out all qualified applicants, not that they won't filter out any of them.

“Capable of writing software that solves a real world problem” isn’t necessarily Google’s bar. It’s entirely possible that the creator of Homebrew doesn’t have the level of skill that Google requires.

> and 100% about companies trying to come up with a standardized, one size fits all tech interview that can be used for every position

Pretty much. We had a conversation at work about this recently, where folks were talking about how they were varying up the interview process depending on the applicant.

Some people pushed back saying we needed a one size fit all process to avoid things being unfair/biaised/etc.

When you push that to the extreme, the google process is what you get (and who gets hired is biased as hell anyway).

While it has its flaws, Ill always push hard for personalized interviews whenever possible. Look at someone's resume to see if its someone who would be useful to you, then test them on THAT to make sure they're not bullshitting on their resume.

Nope. It's just hazing. The geek version of fraternity pledge week.

The only standardization is the thud of hitting the floor due to all participants expending the least possible effort. Like a team building trust fall where everyone is too busy checking Messenger to be bothered to extend their arms.

The shared failure of institutionalized apathy.

I don't see the a contradiction between these two ideas. That last sentence, about this contributing to insiders' perception of being an elect few, describes the same kind of mentality that allows hazing to persist in organizations that do it.

yes, the goal is standardization of interviews, not hiring the best candidate, but it's also about signalling the cleverness of the interviewer and the company. if you're actually clever, it will be evident during the interview without having to plan for it with a pre-determined interview puzzle.

but your "zero risk" assessment is a common but unproven justification of such hiring practices. with good management, you can easily bound the cost of a bad hire to a few (tens of) thousands of dollars. it's hard to estimate the benefit of a good hire since that's an alternate reality not taken, but it's probably many, many times higher than the cost of a bad hire:

opportunity cost of losing a good hire >>> realized cost of a bad hire

(the probability of a bad hire is higher than of missing out on a good hire however, so you'd need real numbers to estimate the relative costs)

Binary tree questions probably come up as often as they do, relative to how often binary trees are actually used, because so many interview questions can be solved trivially with hash tables.

Just because you don’t use binary trees doesn’t mean Google or Amazon don’t, though. Maybe not binary trees themselves, but b-trees and similar data structures are widely used in file systems, databases, and other large scale systems that these companies routinely work on.

Also, everyone knows that companies ask questions about data structures and algorithms. If you’re have the ability and inclination to prepare for these interviews, that says something about you as a candidate. If you don’t prepare at all and then go on the internet to whine about it when you don’t get an offer, that also reflects on you.

No, but just because he created homebrew doesn't mean he's qualified either. Homebrew is one of the least reliable pieces of software I've ever used. It's popularity puzzles me and I've stopped letting it get near any machine I use. It's baffling and annoying to me that people view it as some default packaging solution for Mac, especially when the platform already has pkgutil/pkgbuild. I really wish something like Rudix [0] had taken off instead of homebrew since it's far superior.

Popularity doesn't mean quality and the entitlement of that tweet would be a red flag to me as an interviewer.

[0] http://rudix.org/

Popularity may not inherently imply quality, but enough popularity over time correlates with a gradual improvement in quality.

Homebrew has improved a ton over just a few short years. The Linux ecosystem did the same, as did many other projects that started out as a popular-but-less-featureful/reliable alternative.

If it's been awhile since you tried it, I'd check it out.

Welcome to the free market, where private companies are free to hire or not hire at will based on criteria that works for them. Writing OSS doesn’t entitle you to any job.

Also “inverting” a binary tree is a trivial computation exercise. There’s a difference between engineering and scripting. Homebrew is very much a scripting problem.

"Welcome to the free market, where private companies are free to hire or not hire at will based on criteria that works for them. Writing OSS doesn’t entitle you to any job."

Nobody is saying anything other than that. They're pointing out how dumb the decision is.

"Also “inverting” a binary tree is a trivial computation exercise."

It really isn't, especially if you're not doing it on a regular basis. Which I'd contend 99% of people, including those at Google, are not doing.

"There’s a difference between engineering and scripting. Homebrew is very much a scripting problem."

Aside from, you know, the entire infrastructure around it. That is very much an engineering problem.

“Nobody is saying anything other than that. They're pointing out how dumb the decision is.”

I think filtering people based on ability to solve trivial binary tree manipulation problems is brilliant. Seems to objectively be working out great for google thus far.

Reply on news.ycombinator.com