
Google: 90% of our engineers use the software you wrote (Homebrew), but... - syrusakbary
https://twitter.com/mxcl/status/608682016205344768
======
mikek
At a certain point, your resume should speak for itself. The fact that
experienced engineers with impressive resumes are put through these types of
interviews is insulting and frustrating to the interviewees.

Succeeding at these whiteboard questions requires weeks of preparation. You
need to practice, practice, practice. After enough practice, you are pretty
likely to pass. So ultimately, it is more of a test of "how much do you want
to work here." If you care enough, you can pass. That said, these types of
interviews do favor fresh grads over experienced programmers (you have
algorithms and data structures fresh in your mind), which means that they are
flawed in IMHO.

~~~
kenrikm
These types of interviews work really well for the "I got 1600 on my SATs and
went to {insert high profile school here} crowd" There are books out there
just to prep you for Google interviews I see these as very similar to SAT test
prep books. I'm not so sure Google is really interested in hiring the best
engineers but rather a specific type of engineer.

~~~
thethimble
Think of the problem from Google's perspective though. At some point, you have
tens of thousands of candidates and you need a system to quantify how good
they are. Further, it's reasonable to have false negatives (people you don't
hire that should have been hired) but really bad to have false positives
(people that you hire that you should not have). Together, these boil down
into the de facto whiteboarding interview process.

~~~
fsk
This has got to be the biggest hiring fallacy I've ever heard. "It's better to
reject a good candidate than hire a bad candidate."

That's completely false, and anyone who says that is completely ignorant of
Bayesian logic.

Here are some simple numbers.

Suppose that a "good" candidate is a 1-in-100 find. Suppose that a "bad"
candidate has a 1% chance of tricking you into hiring them anyway.

Every time you pass on a "good" candidate, that is greater opportunity for a
"bad" candidate to trick you into hiring them!

Counterintuitively, if you pass on too many of the "good" candidates, in your
overzealousness to reject bad candidates, you're actually INCREASING THE ODDS
OF A BAD HIRE.

This is management porn. "It's better to reject a good candidate than hire a
bad candidate." It makes the manager feel good. "Wow! That candidate seemed
smart, but I rejected him anyway! I'm such a great leader! I make the tough
decisions!"

tl;dr summary

Because "good" candidates are rare, every time you pass on a good candidate
that increases your odds of making a bad hire! This is simple Bayesian
reasoning!

~~~
bskinny129
Those are simple numbers, but they don't get at the real issue. People say
that because 1 bad hire can have negative effects on the whole team, causing
others to get less done and leave. Missing a good hire doesn't poison your
team.

~~~
krschultz
But 1 bad hire is easily correctable - you fire the person. You won't know
that you missed on the good hires.

I personally have worked with several awesome people that have interviewed
with Google, and none of them got hired. They all said the interview process
was flat out insulting.

Interestingly enough, most of them ended up at Facebook.

~~~
enraged_camel
>>But 1 bad hire is easily correctable - you fire the person.

Not sure if you have ever been a manager, because firing someone is NEVER
easy. It hurts everyone emotionally. The person getting fired feels awful. The
person doing the firing feels awful (unless they are a real sociopath). And
team morale tends to take a big hit.

Here is my stance: if you hire someone who isn't a good fit, unless they
actively deceived you, it is your god damn job to find a way to make it work.
As a principle you should treat people with respect and dignity, and not as
easily disposable and replaceable cogs.

~~~
kogepathic
> it is your god damn job to find a way to make it work.

No, it isn't. This is why probation periods exist. If you hired someone and
they aren't working out, then at the end of the probation period you don't
keep them on.

Trying to force someone who doesn't fit the team dynamic to stay is going to
hurt your org. It doesn't make you a "good" manager to say to everyone "I know
this sucks but deal with it because letting them go would mean I was wrong."

> As a principle you should treat people with respect and dignity, and not as
> easily disposable and replaceable cogs.

Which is ironic because so many job descriptions I see today are basically
written as "we want to hire someone with exactly these skills, who requires
zero training, and can become an expert in our systems in their first week."

No one is that way, unless your system consists of pressing one button all
day, but then the job description would probably require that the person have
intricate knowledge of the button and is friends with the engineer who
designed it so they know what to do if the button suddenly stops working.

If companies actually treated people with respect and dignity, I'd get the
training I need to become a better employee, instead of going to management
and begging them for any training every 6 months like the industry is now.

/rant

~~~
tommorris
> Trying to force someone who doesn't fit the team dynamic to stay is going to
> hurt your org.

Doesn't this rather presume that your "team dynamic" is actually good to start
with?

Let's say you had a team of not very good engineers. Then you hired quite a
good engineer who looked at all the terrible practices (e.g. no version
control, shitty or nonexistent testing, poor build processes) and said to
themselves "look, I need to fix this shit or I'm leaving, and I've got ten
better offers in my inbox".

They might not be a very good team fit, but that's because the team is filled
with idiots who haven't figured out how to use version control or whatever.

So, you know, the best thing to do is to get rid of them for not being a
culture fit or for not being good for the team dynamic...?

~~~
kogepathic
> They might not be a very good team fit, but that's because the team is
> filled with idiots who haven't figured out how to use version control or
> whatever.

Yes, if you have a team like this and you hire someone who has a higher
standard, there is going to be some friction between them and the existing
team members. Letting that person go isn't your concern, because as you said
yourself:

> and said to themselves "look, I need to fix this shit or I'm leaving, and
> I've got ten better offers in my inbox".

I've been in that situation before. I was hired to a company and when I got
there I found out that every single day they were fighting fires because of
stupid decisions management made with little foresight into how it would
affect the team. Funny enough none of this was mentioned during the interview,
although it was a definite red flag that they had high churn for this
particular position.

I stayed there for my probation period trying to fix things so the team would
fire fight every day and change management's mentality, but it wasn't
happening, so I gave notice and went somewhere better.

> So, you know, the best thing to do is to get rid of them for not being a
> culture fit or for not being good for the team dynamic...?

No, you took me too literally. Obviously if you've got someone who has
friction with the team, but they're a hard working individual who is trying to
make your team better and more efficient, you should try to work through those
stressful periods because in the long run it will be better for your team's
health and the company's health. If some of your low performers leave during
this period, that's okay, they were only going to hurt you in the long run.
That being said, don't burn bridges with your existing employees. Try to find
a happy middle ground that results in a better work environment for everyone.

------
joshstrange
To all of those saying ranting on twitter is the wrong move I couldn't
disagree more. Twitter is often the ONLY tool that the average person can use
to communicate and/or call out large companies on their actions. This is BS
and should be made known. Homebrew is an amazing tool and I'd be falling over
myself getting the offer papers in this guy's hands if he came to me looking
for a job. The fact that google turned him away only further cements my
opinion that google would be a terrible place to work.

~~~
philipwalton
My main complaint with the tweet is that it's almost certainly speculation.

1) Most companies (for legal reasons) don't tell candidates why they weren't
offered a job. Maybe it was because of the binary tree question, but maybe it
was for some other reason.

2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use
homebrew is very low. Moreover, Google does not track the software its
employees download onto their laptops, so there's no way they would even know
the percentage.

~~~
austinjp
Really? In the UK companies are legally obliged to reveal why a candidate did
not get a job, if asked... in my understanding.

~~~
mdpopescu
Huh? I've been rejected by an UK company with just "you're obviously a very
experienced programmer, but "we are not able to take your application any
further at this time".

I did get a code review out of it though, and it did point out a few real
issues, so I'm ok with it.

~~~
austinjp
Maybe I don't understand the legals fully. My experience comes from being on
the hiring side. Our HR department were very keen that we kept detailed notes
so that the decision not to hire could be justified in the case of a tribunal
or suing situation. For what it's worth, it did make me question my motives
and felt that it ensured I gave every candidate a fair shot.

------
Alupis
Has no one stopped to question what Google may have been looking for in a
candidate?

The OP has written some great apps, sure, but there is a huge difference
between writing a package manager for Mac (among other Mac/iOS apps and
utilities) and writing incredibly complex, highly performant algorithms for
say search indexing, machine learning, ai, etc...

In that context, knowing CompSci basics like Binary Trees (usually taught to
pre-major CompSci students) has a lot of relevance. It's clear Google was
looking for a Computer Scientist here, not just another developer.

I am also put off by the extreme display of non-professionalism here. It's
like the OP took this personally as an insult. "I've written popular things,
how dare you not hire me if I want to work for you!". That's not a
professional I'd like to work on a team with. Rather, that's a throw-back to
the "Rockstar" programmer that nobody wants to work with.

This boils down to a person who was personally offended a company did not hire
them at a drop of a hat, as-if he was "blessing" Google with his presence.

I'd say, Google (and other companies) are better off without this type of ego.

They made the proper choice to weed this individual out.

~~~
emsy
If you follow the twitter discussion, it says he applied for iOS tools. I
don't know what tools they write but I'd be surprised if someone who manages
to write a (pretty good, actually) package manager can't solve the problems in
this position.

~~~
Alupis
> If you follow the twitter discussion, it says he applied for iOS tools

We cannot just assume that since he applied for iOS something at Google that
he's the best fit and what they were looking for.

Maybe the tools Google needs built are very CS heavy (hence the "Build us a
Binary Tree" question)? Maybe during the interview his arrogant attitude was
on full display? Maybe the interview team dug up past episodes of explosive
arrogance like this very one we're discussing right now?

Even if they were looking for someone that matched his profile exactly, his
post-interview display of non-professionalism is sure to hurt his chances of a
re-interview anytime in the future (and quite possibly at many more companies
than just Google).

He conveyed several things with this display, none good;

* he's incapable of handling rejection

* he feels entitled

* he feels he's better than everyone else

* he's unwilling to admit his own shortcomings

None of these are good qualities.

~~~
omegote
He actually didn't apply, it was Google who contacted him in the first place.

~~~
pound
Google contacts plenty of people. Reaching out to yet another engineer (not
even talking about this particular case) doesn't mean they really want someone
particular. They just going through the pool of potential matches. Person who
initiated contact may not even know what exactly Homebrew is.

------
fishnchips
[Ex-Googler here] Truth be told this is a trivial question to be asked during
an algo interview and as an interviewer I'd consider this a warm-up. Otherwise
it's a rather poor question since either you know how to do it (ie, you have
an idea about recursion) or you don't - there aren't too many shades of grey
or possible follow-up questions that I can ask to probe the depth of your
knowledge.

That being said if I asked this as a warm-up and we'd spend the whole
interview trying to get that done then of course my verdict would be No Hire.
As an interviewer it is not my job to look at your GitHub profile - instead I
am assigned an area to check and I try to come up with the best understanding
of the candidate _in that area_. While failing to reverse a binary tree is a
total failure in algo/ds you can still be hired since there are several
interviewers (if you make it to onsites, that is), each probing a different
area.

My biggest problem with Google style interview process is that it's easily
passed by folks who already passed it in a different company. After having
interviewed hundreds of Google's candidates I moved to another big company
with the same interview type and the experience was really surreal. On my
algo/ds interview I got asked slight variations of the same questions I was
asking myself - and over time I've seen some totally brilliant, unexpected
solutions. Must have been a strange experience for the interviewer who got his
questions each answered in 3 minutes tops. I also made it a sport to solve
each one in a different language because why not. Not sure though about
validity of the signal the company got from this interview.

~~~
Aloisius
_> [Ex-Googler here] Truth be told this is a trivial question to be asked
during an algo interview and as an interviewer I'd consider this a warm-up.
Otherwise it's a rather poor question since either you know how to do it (ie,
you have an idea about recursion) or you don't - there aren't too many shades
of grey or possible follow-up questions that I can ask to probe the depth of
your knowledge._

It is a terrible question.

First, you can't invert a binary tree (as in flip upside down). If you did,
you'd end up with multiple roots and since all binary trees are rooted, you'd
no longer have a binary tree. It'd be a tree, just not a binary tree.

If the questioner meant mirror a binary tree (swap left & right at each node),
then it is a no-op. You do not need to modify memory to do it. Left & right
are just labels for two pointers. You can just swap the order your variables
in whatever struct defines your node and cast it against your existing memory
(or change what your accessors return in a derived class or create a reverse
iterator or however you want to implement it) and there you go, a "reversed"
tree with zero overhead.

Either way, it is a terrible question unless you wanted to see if someone
understood the difference between how a data structure is drawn on a
whiteboard for humans vs. how it actually works. Maybe they were actually
asking that question, but that seems highly unlikely.

And if they actually meant for you to recurse down and swap left and right on
everything, it would dramatically lower my opinion of them because it would
make me wonder if _they_ knew the difference between how a binary tree is
drawn on a whiteboard vs. how it is laid out in memory.

~~~
gaustin
Would a multiply-rooted tree still be a tree? I thought a single root was part
of the definition of a tree. Would it instead be a graph?

Sorry for the elementary questions. I'm bad at algorithms and just trying to
get a grasp here.

~~~
kele
At my university it's common to call acyclic, connected graph a tree. We
distinguish between rooted and unrooted trees. For example, minimal spanning
tree doesn't really have to be rooted, it just has no cycles.

~~~
haversoe
> acyclic, connected graph a tree

This is the graph theoretic definition of a tree.

------
kazinator
WTF is "inverting a binary tree?". The smattering of search engine results
points to some seemingly operation that basically generates garbage by
destructively manipulating the tree into a DAG in which the leaves of the
original tree are roots, which point downward the parents. The original root
node is returned, and still points to its children. Unless you return some
aggregate (e.g. list) of all the roots which are not direct children of the
original root, or it is understood that something elsewhere holds reference to
them, they are leaked.

Be that as it may, _if the interviewers hand you a reasonably detailed
specification of what "invert a binary tree" means_ and you can't whiteboard
it, I don't see how you can expect the job.

If you're expected to know what it means, and get no hint, then that is just
stupid. "Whiteboard up an implementation for something we refuse to specify,
beyond citing its name."

~~~
tzs
My guess is that the potential leaking of some nodes is one of the points of
the question. A lot of people would not notice it.

Note that in the original tree each node needs storage for two pointers. After
inversion only one is needed. You can use that now unused storage to link
together the multiple roots to solve the leak problem.

But note that only consumes the second pointer storage in the roots. Interior
nodes end up with some free storage after inversion.

Since inversion is reversible, the binary tree and its inverse contain the
same information. Does this mean we should only need one pointer's worth of
storage in the binary tree nodes?

Is there something for binary trees similar to Knuth's xor trick for doubly
linked lists?

~~~
kazinator
If you invert the tree such that each node points to its parent, and there are
no child pointers, you lose information. Namely, the order among children is
lost. A given interior node still has two children as before, but it is not
known which is the left child and which is the right child; there is just a
set of up to two nodes which point to the same parent.

The binary tree inverse specifications/implementations I have looked at
preserve the information by selectively using the left or right links. For
instance, given:

    
    
         P
        / \ 
       L   R
    

The inverse would be:

    
    
       L   R
        \ /
         P
    

Both children point to the parent. But the left child uses its right pointer,
and the right child uses the left pointer. That's what preserves the
information about which child is which.

------
nostrademons
Sorta ironic, but remember that the point of an interview is to determine how
well you'd do _in the environment that 's hiring you_, not _how good a
developer you are_. Because Google tends to reinvent the wheel for basically
everything, algorithmic knowledge really does matter. Package management only
matters within a few very specific subteams. If you're interviewing for a
general SWE position, you could be Mark Zuckerburg and still not qualify for
it.

FWIW, I find Facebook turning down Jan Koum in 2009 and then spending $19B to
acquire his company even more ironic.

~~~
apendleton
That may well be, but if you're considering hiring a guy who's an expert at
writing package management tools, don't you put him on one of the specific
subteams that needs that skillset? Surely it's something Google deals with?

~~~
nostrademons
The problem is that Homebrew is very different from the sort of package
management tasks that Google deals with. The design goals for Homebrew
include: make it easy for users, make it not require root, make it work on
Macs, handle dependencies robustly. If he were at Google it would be Linux-
only, he'd be using Linux containerization extensively, he'd be deploying
packages to thousands of machines instead of one, it'd be a virtual guarantee
that some of the machines would fail during the installation process, there
would be little or no user intervention and if there was a user it'd be a
trained SRE, and the installation procedure would probably need to be an order
of magnitude more efficient than Homebrew is.

I don't want to take away from his accomplishments as a programmer - I use
Homebrew too. But my point is that it's very easy to see "Good programmer, of
course he should get hired" from the outside, while the reality is that it may
not be all that similar to the tasks he'd be doing.

~~~
smackfu
If you are hiring the Homebrew dev, and your devs currently use Homebrew, why
wouldn't you hire him to work on Homebrew for you?

~~~
Alupis
> If you are hiring the Homebrew dev, and your devs currently use Homebrew,
> why wouldn't you hire him to work on Homebrew for you?

Macs account for something like 8% of the total marketplace of all PC's. For
developers, they account for something like 20%... another 20% on Linux, and
remainder on Windows or other.

So even if somehow having a paid Google employee work on Homebrew seemed
advantageous, it would only benefit 20% of Google's staff, and 0% of the
company itself (all Google servers are Linux).

~~~
loopbit
Except that google 'banned' the use of windows internally a few years ago
unless you had a really, really good reason for it.

Not sure what's the status of that ban (nor I care), but will skew the numbers
enough to invalidate your point.

~~~
Alupis
> enough to invalidate your point.

It might except ex-googlers in this thread of stated Google "banned" use of
Homebrew internally. So the net benefit to the company and/or employees
remains small to zero.

This is off topic though, since he was not being interviewed for homebrew
development.

------
robbrit
I'd like to present HN with a challenge. Come up with an interview process
that matches _all_ of these requirements:

Objective - the process avoids human bias (this guy was in my frat, therefore
is awesome).

Inclusive - someone doesn't need extensive past knowledge in a particular area
of coding to do well in the interview.

Risk Averse - Avoids false positives.

Relevant - it properly tests the abilities needed for a coding job, and not
irrelevant ones (like the ability to write an impressive resume).

Scales - this will be used for tens of thousands of interviews.

Easy-to-do - this will need to be done by hundreds/thousands of engineers, who
would probably rather be coding.

It's easy to poke fun at what is perceived to be a flawed process. It's much
harder to propose a solution that satisfies the above requirements. Google has
done extensive research on this topic and has done remarkably well with it
compared to other companies of similar size.

~~~
ridiculous_fish
Xoogler here. I can't meet your challenge. IMO the very premise of a company-
wide unified interview process for all software engineers is wrongheaded.

How can you make the interview relevant without knowing what the position is?
I was asked the typical CS-type questions in my interview, but the team I
ended up on required no theory.

How do you define false positives before you know what the candidate will work
on? A superstar in one team will be a dud in others.

And let me add another bullet point to your process wish-list: gives the
candidate a sense of whether they want the job. This is impossible when the
interviewer is a random engineer from an unrelated team, unable to speak to
what the candidate's work life will be like. A Google style process gives
candidate very little information.

I would instead propose something very old-fashioned: teams hire for
themselves. The usual reply is that this results in an "inconsistent hiring
bar", but so what? Teams have different requirements and need engineers with
different skills, so why shouldn't the hiring process reflect that? We are not
fungible engineering units.

------
carc
To be fair, inverting a binary tree is a pretty easy question. Google also
tells you BEFORE you start the interview process that it'll be very data
structure/algorithm oriented and asks that you please prepare (and take as
much time as you want doing so). They even say that they want you to prepare
because they know a bad candidate that prepares can look better than a good
candidate that doesn't prepare - then want all candidates on a level playing
field so they can make accurate judgements. All that being said, I still think
that there is lots of room for improvement in the process.

edit: really good english skills

~~~
jblow
I am dismayed by the way all the reactions on Twitter are piling on with
outrage and/or relating similar experiences.

Inverting a binary tree is pretty easy. It is not quite as trivial as
FizzBuzz, but it is something any programmer should be able to do. If you
can't do it, you probably don't understand recursion, which is a _very basic_
programming concept.

This isn't one of those much-maligned trick interview questions. This is
exactly the kind of problem one may have to solve when writing real software,
and though you may never have to do this specific thing, it is very related to
a lot of other things you might do.

I run a small software company and I very likely would not hire a programmer
who was not able to step through this problem and express a pseudocode
solution on a whiteboard.

~~~
callum85
> If you can't do it, you probably don't understand recursion

No, I can't do it (don't even understand the question) but I certainly
understand what recursion is, and can solve problems and make things work far
more reliably than many of the more academic programmers I have worked with.

~~~
SamReidHughes
I believe "invert" here means to flip the left-right direction. A better word
for it would be "mirror."

------
seccess
What does it mean to invert a binary tree? I'm not familiar with this
operation on binary trees. Does it mean to swap parents with child nodes? Or
to swap siblings?

~~~
x3n0ph3n3
In this case, it means to reverse the binary tree, so that you get the largest
item by iterating down the left branch to the bottom of the tree. You would do
this by breadth-first scanning the tree, swapping the left and right pointers
as you go.

~~~
attilaolah
Oddly enough, Google shows me interview questions where "inverting a binary
tree" means something quite different — for example, flipping it upside down,
and making the left leaf the root, the right leaf the left leaf and the root
the right leaf.

If this was really about "reversing" the tree, as you mention, the question
seems more likely to address how the candidate approaches the situation. Like,
he should start by making sure they both agree on what the question actually
means.

Once that's out of the way, it seems relatively easy to come up with a naive
solution, without having memorised any algorithms. It seems more like a case
of brainfreeze to me, which can be sort-of fixed with practice (which in turn
many candidates refuse to do: the dreaded "If I have to cram for the
interview, I don't want the job" statement.)

So maybe he really wasn't a good fit for Google, despite apparently being a
rockstar developer. Hey, startups need rockstar devs too.

~~~
DannoHung
I was gonna say, who calls reversing a tree's ordering inverting?

> Oddly enough, Google shows me interview questions where "inverting a binary
> tree" means something quite different — for example, flipping it upside
> down, and making the left leaf the root, the right leaf the left leaf and
> the root the right leaf.

Whaaaaa? I can't find this, but it seems like such a weird operation. Got a
link?

~~~
morpher
>I was gonna say, who calls reversing a tree's ordering inverting?

The guy writing the tweet (not necessarily the interviewer).

------
squiguy7
Interviewing seems broken to me too. I have spent the last few months trying
to get a job out of college and everyone seems to be interested in how well
you can regurgitate CS fundamentals.

They are seemingly less interested in seeing how you solve problems and work
through the process of software.

I would be more than happy to see this process change, I am just not sure what
it entails.

~~~
bstamour
Devil's avocado: if they're truly CS fundamentals, then they should be baked
into you good and deep during the course of your college education. It
shouldn't be painful at all.

~~~
gkoberger
I took CS 101 classes almost a decade ago, and since then, I have never once
needed to write a binary search tree outside of an interview.

I think "CS Fundamentals" are really just "abstract concepts used to teach
programming", and calling them fundamentals is disingenuous.

~~~
jblow
Maybe you're just not doing serious programming. Most people I know implement
data structure searches quite often.

If you're writing scripts, or JS code for web pages or something like that,
then maybe you don't use CS stuff, but ... are you able to write a web browser
if you had to? Are you able to write an operating system or navigational
software for a spacecraft? If not, then maybe just see this as revealing
sectors of your skill set that could be beefed up, rather than presuming that
none of that stuff is important.

~~~
Aloisius
> _Maybe you 're just not doing serious programming. Most people I know
> implement data structure searches quite often._

Wow. Really? Most serious people I know use other people's implementations
that have already been highly optimized and well tested because they have
better shit to do than reinvent the wheel.

I suppose if you want to write your own red-black tree from scratch, that's
your prerogative. The last time I did was 20 years ago and not only will I
never do that again, I will laugh at anyone who does it without a damn good
reason.

~~~
MaulingMonkey
> Wow. Really? Most serious people I know use other people's implementations
> that have already been highly optimized and well tested because they have
> better shit to do than reinvent the wheel.

Ditto. Those who decided to reinvent even basic data structure stuff left me a
huge string of bugs to fix, which I eventually got so fed up with, that I
started replacing their code wholesale with off the shelf solutions to stem
the flow at my last job.

Aside from fixing an untold number of implementation bugs, the replacement
caught several _usage_ bugs as well, due to actually having some error
checking built in.

We had just plain broken hashtables, "lock free queues" that didn't use memory
barriers... or interlocked intrinsics... or even volatile, if my memory is
correct - and not a debug visualizer to be seen before I got my hands on them,
of course.

> I suppose if you want to write your own red-black tree from scratch, that's
> your prerogative. The last time I did was 20 years ago and not only will I
> never do that again, I will laugh at anyone who does it without a damn good
> reason.

Besides laughing, I'll tend to -1 the code review as well.

------
bane
I've phone interviewed with Google a couple times. I wasn't really interested
in working there, but wanted to see what it was like. Both times, the people
who interviewed me were decent, friendly folks and we had a good chat. They
then dug into algorithm questions on topics I hadn't seen since my undergrad
(I'm about 20 years into my career) and haven't touched since then -- though
I've done a bit of algorithm work outside of that they weren't particularly
interested in that.

I reached into my way-back machine and tried to derive some approaches where I
simply didn't remember the answer (and I was very open about it). I made it to
call backs both times, but they declined to move forward, probably because
they wanted a younger person who remembered their big-Os off the top of their
head, but I was okay with it. I told all the interviewers I had fun and I did.

Even if I had made it in, I'm not sure I would have taken the job at those
times. So my lack of motivation ended up turning what could have been
stressful into a fun look at their hiring practices.

However, I can see for people who are really dead set on working there, it can
be a harrowing experience.

------
notacoward
Humorous answer: Maybe I can't invert a tree, but watch me flip this table.

Serious answer: Companies that pull this crap deserve to starve and die.

~~~
westernmostcoy
What specifically are you objecting to? That specific question? Writing code
on a whiteboard?

How would you interview software engineering candidates?

~~~
gt565k
I think the best way is to give them access to a code base, give them 48 hours
and have them submit a pull request for a feature. That way you can see that
they can learn the codebase and implement the feature in their own time.
During the interview, you can discuss their code and the reasoning behind the
implementation details.

~~~
snom337
Which is fine and dandy until you get that one person that cheats by getting
help from someone else.

~~~
ruswick
As if people who interview for Google don't just look up the most common
interview questions and memorize answers before the interview...

~~~
snom337
Still I think that would become obvious pretty quickly. I've actually had
people start writing out a textbook algorithm that just solved the wrong
problem. And then completely stumbled when trying to explain how the program
would arrive at the intended result.

I usually ask questions until the person is out of his comfort zone, and if he
is completely clueless on how to proceed at that point it's a red flag.

------
markbnj
Number of times I have had to invert a binary tree in my 25+ year career: 0.
Number of times I have been asked to invert a binary tree in an interview: 0.
What I would do if I had to invert a binary tree: look it up.

~~~
ksk
>Number of times I have had to invert a binary tree in my 25+ year career: 0.
Number of times I have been asked to invert a binary tree in an interview: 0

Well, if you wanted to pull that card, it would have been nice to mention the
sorts of problems you've worked on in those 25 years.

>What I would do if I had to invert a binary tree: look it up.

Unless you're already good at algorithms, it would net you a mediocre
solution.

For e.g. You would only know that there are multiple ways to implement an
algorithm when you've actually done the work dozens of times and noticed that
some implementations won't be appropriate for you needs. Like with many
things, its about having experience, knowing whats a good fit, and knowing why
something similar isn't a good fit.

Certainly - every single time you choose an algorithm, and then decide on a
particular way to implement it - you could in theory, implement each algorithm
in 10 different ways and then choose the best one after benchmarking. But that
would be a huge drag on productivity. And if you had to choose 5 algorithms
for 5 different tasks then it quickly becomes a quadratic complexity time
sink. It would be far better to just know via experience. Its kind of like in
chess - the better players just KNOW that certain paths lead to less
favourable winning odds. Well, novices do take those paths and eventually find
out the hard way !

~~~
markbnj
>> Well, if you wanted to pull that card, it would have been nice to mention
the sorts of problems you've worked on in those 25 years.

Quite a range of stuff, unsurprisingly. I started on an HP3000 mainframe in
1976, if you want to go back to the very beginning, writing BASIC programs on
a teletype or one of the two early CRTs, and storing my programs on paper
tape.

Since then I've worked in DOS, 16-bit Windows, 32-bit Windows, 64-bit Windows,
Ubuntu, iOS, and Android, using Pascal, 8086 assembler, C, C++, C#,
javascript, Python, and Java. I've worked on applications in multimedia,
telephony, banking, insurance, pharmaceuticals, cosmetics, health care, and
I'm sure a few other things I've forgotten.

All of which will mean jack squat if, tomorrow morning, the most important
thing I have to do is invert a binary tree. But I'm fairly certain I would be
able to figure out what I needed to do, and I am fairly certain I could manage
to implement it well. It's what we're supposed to be able to do, and if you
think that having studied up on it so that you could pass a Google interview
means that, a few years down the road when you actually need it you'll just
whip it off the top of your head, then I think life may hold some surprises
for you.

~~~
ksk
Thanks for replying. I simply wanted to know what kinds of problems you worked
on. A binary tree can be inverted presumably on any OS and using most
languages. If you're going to claim that a basic binary tree operation has not
be necessary for you in your 25+ year career, you should have mentioned your
problem (!industry) domains. It was nothing personal.

>and if you think that having studied up on it so that you could pass a Google
interview means that, a few years down the road when you actually need it
you'll just whip it off the top of your head, then I think life may hold some
surprises for you.

That is a misrepresentation of what I said. I said that _RETAINING_ basic and
higher order CS fundamental knowledge is much more useful, in a way that
simply looking up an algorithm on wikipedia would not be.

~~~
markbnj
>> That is a misrepresentation of what I said. I said that _RETAINING_ basic
and higher order CS fundamental knowledge is much more useful, in a way that
simply looking up an algorithm on wikipedia would not be.

Sorry it was not my intention to misrepresent you. I was assuming that we all
agree that simply looking something up without having any fundamental basis
for understanding would not be of much use, and that we further assume the
person doing the searching is in need of a refresh, and not basic education in
the craft. In that context it is the idea that you might be called on to go up
to a whiteboard and trot out something you haven't done in three years, and
then be judged competent or not based on how successful the trotting is, that
gets people worked up.

------
el_fuser
Another instance where silicon valley favors the young... he probably would've
nailed this question if he'd been only a couple of years removed from school.

He also would've nailed it had he been given 10 minutes to do some research to
refresh.

Silicon valley (and the numerous companies that mock the interview style) are
testing for the wrong thing when they hire, then complaining about not being
able to find good engineers.

~~~
CydeWeys
You're given weeks to refresh your knowledge ahead of a Google interview. They
tell you the basic CS fundamentals that are going to be covered. Binary trees
are MOST ASSUREDLY on that list. They just don't have time during 45 minute
interviews to let the candidate go on the Internet to look things up they
should already have come prepared for.

Anecdotally, at a previous company, we tried an "open book" (i.e. you can use
the web) interview policy for a few interviews. It was a train wreck.

~~~
bitkrieg
Out of curiosity, can you elaborate why the open book interview policy failed?

~~~
eropple
At prior employers we've had very good luck with open-Google interview
policies. I mean, we'd watch what you're Googling, and if you're copy-and-
pasting we're going to drill you to make sure you actually _understand_ it,
but I expect to have a search engine when programming and I think you should
too.

I prefer not to ask code questions at all, though.

------
spiritplumber
A project manager at Google was upset that my 'bot literally ran circles
around theirs (it was 2010, Android based robots were just starting) and told
me that I was just a hobbyist and my project did not exist.

So I gave him one of the spare logic boards (open design anyway). And wrapped
my hand around his. And squeezed. And asked him, if it doesn't exist, why is
it making you bleed?

He watched impotently as the people who had been invited for the presentation
played with my robots and ignored his as two of his guys tried to get it to
work.

I finished the two projects I was doing with Google and did not call them
again.

(Before you downvote: Yes, there is some video, and I consider the small
amount of pain I inflicted that day a kindness compared to the much greater
amount of pain that an engineer is in danger of enduring if he says things
like "This thing that is in front of me, it does not exist", especially if he
works with big machines).

~~~
to3m
I think you need to work on your people skills.

~~~
eonw
or the other guy could work on his ego skills?

~~~
to3m
That can be dealt with when they post their side of the story.

~~~
eonw
agreed, i would love to hear both sides of this one.

------
bla2
Interviewing is stressful and all, but if the guy's reaction to not getting
hired is to flame on twitter, not hiring might've been the right call.

~~~
vezzy-fnord
I also somewhat laughed at the poster who stated "Apparently my GitHub wasn't
enough."

~~~
r0naa
Well, he is the author of numerous widely used open source projects. It is a
bit redundant (and useless) to give him a "homework assignment when he has
such an impressive portfolio that speaks for itself and of which you can
assess the quality.

------
topher6345
In my office, opinions are 50/50 on this.

Interview with Lazlo Bock on Google's hiring practices:

[http://youarenotsosmart.com/2015/06/08/yanss-051-how-
google-...](http://youarenotsosmart.com/2015/06/08/yanss-051-how-google-uses-
behavioral-science-to-make-work-suck-less/)

Some of the claims Lazlo makes:

As large organizations grow, their workforce trends towards mediocrity. Google
* takes special care to counter-act this effect. * researches their
hiring/interviewing practices just as much as their machine learning. *
publishes their methodologies:
[https://www.workrules.net/](https://www.workrules.net/)

The algorithm in question is discussed in Coding Interviews by Harry He.
[http://www.apress.com/9781430247616](http://www.apress.com/9781430247616)

I feel the original tweet conveyed a bad attitude, was emotional, reactionary,
and ultimately a bad career move on the part of OP.

In my younger days I suspect I would have done something similar. I'd like to
think I would see the experience as a learning opportunity and be able to
react with humility and maturity, but who knows? Hopefully I can think of OP
and not tap the tweet button.

~~~
mildbow
Wow.

Really? Pretty much everyone recognizes that google style interviews weed out
perfectly good people. What Max went through is just an example of one such
obvious case. It's very much a case of the google hiring algo failing. Lot's
of people would have no doubt that Max can cut it when it comes to iOS dev.

That's all it is. Now, if you are going to read "tweet conveyed a bad
attitude, was emotional, reactionary," into a perfectly human tweet, holy crap
you are judgmental.

>> ultimately a bad career move on the part of OP.

Not at all. I've done a _lot_ of interviews and basically _none_ of them
required us trawling twitter. I think it would have to be something pretty
heinous for me to _not_ hire someone based on their social media crap.
Definitely not something as mundane as this. This sort of hilarious cowardice
about expressing feelings just makes me angry. At what point do we stop acting
like these trivial, humanizing glimpses into a person are somethign that is a
bad career move?

------
shanemhansen
I had a big comment here, but I erased it. I think one story proves my point.
When talking to google engineers one thing I noticed was that they considered
youtube to basically be a joke. The reason why is that youtube has a messy
python codebase. I asked them what they worked on while they were at google.
They had rewritten an internal web portal for a support tool. From everything
I can tell it was literally a mysql crud app.

If this is how success and failure are determined at google, it's no surprise
how many of their products that people actually use come from acquisitions.

------
harel
I don't know if I would rant on Twitter, but I would be as frustrated as well.
Those 'tests' are very academic and I am not an academic person. I've not even
officially finished high school. This test will not properly judge how well I
can code or design software. I've been doing just that for 20 years now, and
launched a few start ups, but I would fail that interview at the door.

I interviewed once for Google (at their request) and failed. For some reason
they interviewed me for a networking position instead of a code one, so
questions about TCP internals were not really my forte. I was just launching
my second start up at the time and would have declined the job had I gotten
it. I admit it does sting a bit to be declined - not just for Google, but for
any position - even those you would decline yourself.

------
yongjik
As others said, much more than 10% of Google's engineers don't even own an
Apple machine. So, even if Google's Mac management team somehow uses Homebrew
to manage the employees' machines (which may or may not be true: I have no
idea, even though I used a Macbook in Google until recently for years), the
percentage of Google engineers using that software is nowhere near 90%. The
percentage of Google engineers _knowingly_ using that software is certainly
closer to 10% than 90%.

------
chubot
I think there is some validity to the general point, but I'm not commenting on
that.

Just quibbling: I don't think anywhere near 90% of engineers use homebrew?
Google development is done on Linux, and Homebrew is a Mac thing AFAIK. I have
never used Homebrew.

Android development can be done on Macs but I doubt they use Homebrew.
Certainly not for anything important.

~~~
devy
Re: "and Homebrew is a Mac thing AFAIK." -> FYI There is a fork of Homebrew
called Linuxbrew now. [http://brew.sh/linuxbrew/](http://brew.sh/linuxbrew/)
FYI.

------
pearjuice
It's funny because the guy actually thinks having built something popular
equals being a good software engineer. Wordpress, PHPMyAdmin and so forth are
all really popular but the code is shit and though it's used by millions of
people, a _real_ software engineer will shudder looking at its source code.

Now, I have no idea what the code quality of Homebrew is, but just because he
built something popular doesn't mean he should get a green light in every
company. If Google is looking specifically for top-notch software engineers,
they are probably filtering them very well with their practices.

Maybe they are only good on paper at that moment and don't have something like
"Homebrew" on their Github, their knowledge is sufficient to perform work at
Google. So why pick someone who has fame to his name, probably wants to get
paid accordingly and thinks he is a hotshot because of his Twitter and Github
follower count over someone who proved himself in an interview?

The first is not necessarily better than the latter.

------
malkia
And then you could've been just cool all about it:
[http://www.businessinsider.com/facebook-rejected-whatsapp-
co...](http://www.businessinsider.com/facebook-rejected-whatsapp-co-founder-
brian-acton-for-a-job-back-in-2009-2014-2)

~~~
matheweis
This. @brianacton's response was super classy.

------
lukaslalinsky
I strongly believe that the best kind of technical interview is to talk with
the person about things they have done in the past, go into details and see if
they are telling you bullshit. If the things are interesting, at least somehow
relevant to what the company is doing and the person knows what they are
talking about, it's a good hire.

One problem is that only experienced developers can do these kind of
interviews, because you need wide experience, be able to talk about various
technical topics and tell whether the other person is telling you stories from
their own experience or some quickly learned facts.

It's funny, but the best experience I had interviewing at Google and Amazon
was talking with the managers.

------
JamesBarney
This is especially ironic given how much Google has complained they need more
H1-B's because they can't find enough good devs.

------
sp332
Was it really because he couldn't do the problem, or was it that he didn't
handle himself well in the interview? At two different interviews I was given
logic puzzles just so they could watch how I went about trying to solve them.

~~~
sown
> At two different interviews I was given logic puzzles just so they could
> watch how I went about trying to solve them.

That's usually what they say, but I've found that if you don't solve the
puzzles, you don't get hired ever.

~~~
mrobins
That experience doesn't mean that's just what they're saying. It could mean in
those cases the person a) didn't solve them problem, and b) didn't demonstrate
an approach to solving they problem they were looking for.

~~~
esturk
OR c) didn't solve the problem fast enough

------
pan69
Personally I don't really care about Google's hiring process. It's unlikely
I'd ever want to work there anyway.

What does bother me is that other companies, who are not even in the same
league as Google, start to copy their hiring process.

I remember interviewing with a digital ad agency a few years back and I swear,
these guys thought they were Google. The number of academic trivia questions
that came up, it was ridiculous.

In a way, I think Google has done a lot of harm to the industry in general by
making others believe that everyone should have a hiring process like
Google's.

~~~
hiou
I've been there as well. I interviewed at a design agency a while back. I
nailed all of their puzzles pretty easily only to get there and realize I was
going to be doing Wordpress hacking and other CMS work from 2010. I left after
a few months because of how trivial I realized the work would be in the long
term.

On the exit meeting it was relayed to me that they were having trouble finding
people because no one could pass their tests and I was beside myself because I
couldn't understand how they would expect someone with that technical ability
to want to bang out Wordpress sites all day while there are 100s of people who
would love to do that job and be very successful without ever even knowing
what basic recursion let along the stuff they had in their test. Bizarre.

~~~
lucidguppy2000
Also - a big motivation for work is learning. Didn't someone say "never apply
for a position your qualified for"?

~~~
stuxnet79
I don't know who said that, and while I strongly agree with it in principle
... in practice it just tends to not work out like that. Employers want a cog
in a machine. They don't want you to 'stretch, grow or learn' on their dime -
no employer is willing to take that risk. Further, career progression in the
tech industry is commensurate with the degree to which you've been pigeonholed
in a particular skill or task. So a high salary is usually indicative, not of
the diversity of your skillset but how well you perform within certain narrow
parameters.

------
nqzero
i had a similar experience with ita software, later acquired by google. i'd
submitted a solution to one of their puzzles (which was actually very close to
their business) which exploited a symmetry in the data and my solution
produced results significantly better than anything else that they'd seen (per
the engineer that managed that puzzle)

interview was brutal - lots of whiteboarding very artificial problems totally
unrelated to the business and i just couldn't get excited about it and didn't
end up getting an offer

hiring is tough, these things happen

------
sjg007
You just have to know the basic data structures and some algorithms for them.
Liked list, binary tree, Hash map etc... In the worst case, set up the data
structure, then derive the algorithm. Do this in Java FWIW and make your life
easy.

This is like knowing math and/or stats and applying it to a word problem.

------
SubuSS
Actually my pet theory is this: Interviews for experienced folks are more
meant to keep them in their current companies rather than to filter the
incoming new ones. This acts as a gentleman's agreement between the giant
companies to keep their own talent pool semi-intact :) /s.

I mean imagine the amount of extra work someone has to put in to start
interviewing. Take a break from your current work, Prepare your CS basics
again, Prepare from interview question dumps online, read up / analyze
everything the new company is doing and form reasonable opinions, practice
white board coding / coding without an IDE, allocate time for any homework
projects given, Psych yourself up if you are introverted etc. The alternative
is just to stay in the current role and hope stuff gets better. 90% of the
folks I know choose the alternative over the dehumanizing process of
interviews. So many folks I know are good engineers get chewed up in
interviews (both in my current company and elsewhere) because the process is
pretty cooked. We are trying to see how this can be improved, but yeah - I
just keep going back to my pet theory :)

I do agree with one of the commenters here though: At one point your resume
should speak for itself. These are the kind of problems I would like LinkedIn
to be solving instead of finding ways to spam me with recruiter deluge.

------
mentat
It's interesting the amount of hate and either rumors of bad experience or bad
experiences directly. I interviewed for an SRE position last September and
they were clearly trying very hard to make it a good experience no matter the
outcome. I flubbed a couple of questions and they didn't make an offer, but
the impression that they cared about my experience as an interviewee lasted. I
wonder why my experience was so dramatically different from many here.

------
TheMagicHorsey
I've been invited to interview at Google three times. And they've declined to
hire me three times. The last time I interviewed there the quality of the
people that interviewed me was much lower than the earlier two times. I was
still rejected, but I felt much better about working somewhere else.

I'm sure Google is still a great place to work, but its reminding me more and
more of 1999 Microsoft. In fact the similarity is spooky.

------
exacube
Firstly, you're not entitled to any job you want just because you wrote
Homebrew. If you accepted an interview with Google, then you accepted the fact
that Google will judge you based on your problem solving skills, just like
every other person was asked.

Secondly, I don't think this is a hard interview question; it's certainly
fair. Did you expect to be asked knowledge-based questions that Google knows
you're already good at? Questions specifically geared towards you? Or
questions where Google can watch you solve a problem and be comfortable with
the fact that you are able to solve coding problems? Did you think Google
would hire you to write Homebrew? Or solve problems on teams Google has?

I think this person is just being unreasonable.

~~~
ciupicri
If 90% of Google's engineers use his software, it's reasonable to expect to be
hired for continuing to work on that software.

~~~
exacube
That may be somewhat true, depending on how crucial and dependent Google is on
Homebrew. But 90% of Googlers don't rely on Brew for work.

It is just a figure he made up to make a point about how popular his software
is. Using his software outside the context of our jobs is no means to justify
a hire. He should go through the same interview process as 90% (much higher
than that actually) of Googlers.

~~~
ciupicri
My impression was that he was talking about usage for business, not personal
purposes. As for the popularity, even if the 90% figure is made up, I was only
trying to explain/justify his point of view.

------
plg
just playing devil's advocate, but how do we know the reason for the no-hire
was the reason the OP thinks it was?

~~~
hebdo
It seems that almost everyone here knows better than Google how to hire
employees for Google. Given that you can see why it is trivial to see through
hours-long hiring committee decisions in just two seconds.

Edit: as pointed out by others, the hiring decision probably does not take a
few hours, but under an hour. Still, the point is valid.

~~~
nilkn
I'm pretty sure the hiring committees do not actually deliberate for hours on
one candidate. Maybe in very rare cases.

~~~
DannyBee
The most i've deliberated was 45-50 minutes on a single candidate in HC
itself. (often hours are spent reading packets and preparing notes before HC)

It's not because candidates aren't worth it, it's that if you can't come to
consensus in that time period, you are unlikely to be able to :)

------
myth_buster
Well, this thread escalated quickly! Am I wrong in my understanding that when
a company rejects they don't specify why and hence "rejected due to failure to
invert binary tree" may be a guess here?

------
adsr
"I never commit to memory anything that can easily be looked up in a book."
Albert Einstein

It seems like this tests a) how much you want to work at Google and b) how
good you are at memorize things.

------
zyxley
A pair of good articles on just this kind of thing:
[http://www.unlimitednovelty.com/2011/12/can-you-solve-
this-p...](http://www.unlimitednovelty.com/2011/12/can-you-solve-this-problem-
for-me-on.html) [http://sockpuppet.org/blog/2015/03/06/the-hiring-
post/](http://sockpuppet.org/blog/2015/03/06/the-hiring-post/)

------
happinessis
Nowhere near 90% of Google engineers even use Apple, let alone use this
person's software for it.

~~~
grahamar
As Google bragged in 2013 that it managed a Mac fleet of over 40k and with a
workforce of 55,419 in Q1 2015 (not just engineers, 2013 numbers were about
10k engineers), that's 72%+ of Google's workforce using Macs.

Homebrew is at least one of the best package managers for Mac. I would be very
surprised if it was not at least near the 90% mark...

------
cheradenine01
Don't we have Universities for this?

I mean - what's the point of spending 3-4 years in an Academic environment
that proceeds to then test and grade students on exactly how good they are, at
the time - then only to perform the whole process over again some number of
years down the road, with fuzzier results?

Seems dumb to me.

I've worked with people who could likely do very well on algorithmic tasks -
(of which most software projects require precisely zero) - but actually
_deliver_ something of use... not so much.

------
overgard
When I used to interview people (I wasn't a manager, but I was senior enough
to be entrusted to the role), I'd just ask about projects they had placed on
their resume (to get a feel for their contributions) and then the rest of the
interview would be focused on what the job was and how that matched with their
career goals, why they thought they'd want the job, that sort of thing. The
latter part was a bit harder because people are naturally defensive during an
interview, so they can't be like "well I want an entry level web developer job
so I can parlay this into something better in two years" (which is, IMO,
totally an acceptable answer), but you can generally politely get the idea.
Maybe I'm weird, but I just sort of think interviews should be more about
determining fit than giving someone a lie detector test.

I get the puzzlers or whatever for a phone screens (quickly weed out people
that are obviously unqualified), or if you're hiring someone junior who
doesn't have work experience, but if you're at the point where you're bringing
someone in you probably think they're minimally qualified, so it should really
be about determining if goals are aligned IMO.

------
mattbillenstein
I like the spirit of this, but he may well have not been hired for a variety
of other reasons besides this -- including how he attempted to solve the
problem or how he handled not being able to solve it on a whiteboard in an
interview.

I hate whiteboard programming questions and I don't give them when I interview
someone - I give them a laptop with 10 different languages on it, and some
data to munge -- I think it's a pretty decent thing for both parties.

------
russtrotter
Is it possible that technical impression was not the sole reason somebody
isn't hired?

------
benol
I, for one, agree with this kind of hiring process.

From my own experience - people that do well in such interviews are good
generalists. On their own they will start discussing performance improvements
and ways to parallelize the solution, it's a pleasure to have such an
interview.

It's about enjoying problem solving and willing to keep your brain fit. It has
nothing to do with memorizing solutions to some existing set of problems.

------
coldcode
I've always wondered if during an interview with Google you answered a
question with "I'd Google it" what the reaction would be.

~~~
CydeWeys
The response would be "I want you to come up with the answer yourself."

------
bkessler100
These interviews are biased towards new grads ...

GEORGE: You know what I do at the Yankees, when one of these old guys is
breathing down my neck?

ELAINE: What?

GEORGE: You schedule a late meeting.

------
mildbow
This thread is weird.

The people vilifying Max or saying "duh you didn't get hired, Google requires
awesome people" seem to have a totally warped sense of exactly what Google
engineers do day to day.

Blows my mind that there are so many people defending this (well-known and
pretty much taken as a trade-off) lapse in the Google hiring algo and instead
making it seem like Max's fault.

------
fallat
Google really does only hire individuals who are strong in theory.

Maybe we are jealous. We wish we had the brains of the people getting into
Google. I can say personally that I envy these people.

The fact that they don't mind being treated as numbers maybe says something
about these people too. They are cold. Their ego must be pretty big too if
they make it into Google.

Someone should do a study...hehe.

------
rbanffy
I don't think loudly (and impolitely) complaining about being rejected at a
job application can, ever, be the smart thing to do.

~~~
stuxnet79
It is not. IMO it's a pretty ballsy and idiotic thing to do. That's partly why
I am not too active on Twitter. I have a lot of controversial, unpopular
opinions that I wouldn't want a potential employer to get a whiff of.

------
greendesk
I remember a story from college graduation. A friend contacted an alumni from
the university. The alumni worked in the semiconductor business. One of the
questions he asked the alumni was: "How does he select a great employee?"

Alumni's response that it is exceptionally tough. He shared an anecdote about
one of his best hires.

The alumni wanted to test the interviewee's knowledge in different areas. He
asked a question on diodes - it might not have been diodes, but for the sake
of the story let's stick to diodes. The interviewee replied: "Hold on, I am
not one to know about it."

I have not worked at Google and I do not think I'd pass its interview process.
It is unlikely that I be diligent enough to make Homebrew. Nevertheless, I am
inclined to the idea, that being knowledgeable in all tested areas would not
reveal the personal fit necessary to make a great team.

------
doczoidberg
It seems that google wants to have code monkeys instead of creative software
engineers. This is a common problem of big companies. IMO it is one of the
reasons they get stuck with innovations. Of course also the interviewers don't
want to hire people which are smarter than they are because of their own
career.

------
grahamar
As someone who struggles to learn by rote as opposed to learning by practical
means and has been both hired and declined by the Google recruitment process.
I can't help but agree with his sentiment.

The recruitment process (at least for experienced engineers) should be little
more then "can I work with this person". The 6 month probationary period that
follows the hiring process should be used for "can this person do the job
well". But that's just my experience, and it seems to have worked well.

Regarding the same academic questions everybody gets asked in every
development interview, I feel Einstein said it best with "[I do not] carry
such information in my mind since it is readily available in books. ...The
value of a college education is not the learning of many facts but the
training of the mind to think."

------
tlogan
Google is about monoculture (certain type personality) - and from their
business perspective it seems that approach works. Why to change it?

If they try to invent something new or in different market they might need
different type of people but as of now ads business is cash cow and they would
be crazy to try change it.

------
dionidium
Without commenting on whether this is a good interviewing strategy, surely the
point is to sacrifice some potential good hires in favor of definite good
hires. In other words, you might be able to write pretty good code even if you
_can 't_ solve problems on a whiteboard, but, given a choice, why wouldn't we
just choose the people who can do that, _too_?

I think the _stated_ philosophy of interviews like this one is that a false
positive is worse than a false negative. Every single one of the responses to
that tweet either misses that point or sounds like little more than
defensiveness in the wake of a bruised ego.

You might _disagree_ with that interviewing strategy, but you're not
addressing it directly.

~~~
stuxnet79
More or less agree with this. I'm also a Google reject (didn't make it past
the phone interview). I didn't take the rejection personally. I don't see how
the interview process could be drastically improved. They get a lot of
applications and they need some way to filter - there is a standard and it has
to be met. With the sheer amount of applications that Google gets it's a
virtual guarantee that there will be a subset of people taking the piss
regardless of what the interview process is like.

I don't doubt that the engineers who manage to jump through all those hoops
are sensational. Personally in the end it just dawned on me that I didn't want
to work at Google that badly.

The whole Twitter exchange is a pitiful sour grapes circle jerk, and I'm
surprised that it's provoked such a massive response.

------
ajhc112
This guy sounds like a tool. Sure, he's accomplished, but his website and
linkedin are dripping with self aggrandization. "Splendid Chap" \-- cringe. My
hunch is that they didn't hire him because he didn't seem like a cultural fit.

------
timtas
How can we see if this technique works? There are two methods try to know
something: deduction and induction.

First a little deduction. Let's try to be explicit about the theory behind
this technique.

It's safe to assume that the job will NOT consist mainly of cranking out
binary tree inversions on whiteboards while being watched over. So obviously
we're hoping to make a correlation with something else. Assuming the candidate
was not tipped off and learned this particular puzzle, perhaps we are
correlating to an ability to rapidly create novel solutions of long-solved
algorithms without reference tools.

But is that what the new hire will be doing? Probably not.

We could continue down this path, identifying ever more removed correlations
until we get to something that the job actually demands. This probably
involves solving hard problems like naming things. [1] But by now our theory
stands on pretty thin ice indeed.

In any case, all of this deduction is theory making. It's not knowledge until
we attempt to falsify [2] it via induction. The human mind constantly induces
hoping to verify our deductions. We reason, observe, conclude and repeat.
We're good enough at it to survive, but that's about it. Lucky for us, science
came along. Today's technical hiring is at best alchemy.

A interesting company called TripleByte [3] is trying to apply induction
(first for YC companies). They specially shun on white board coding and puzzle
solving tests in general. I will be interested to see how they fare and
whether their learnings are adopted more broadly.

[1]
[http://martinfowler.com/bliki/TwoHardThings.html](http://martinfowler.com/bliki/TwoHardThings.html)

[2]
[http://en.wikipedia.org/wiki/Falsification](http://en.wikipedia.org/wiki/Falsification)

[3]
[http://techcrunch.com/2015/05/07/triplebyte/](http://techcrunch.com/2015/05/07/triplebyte/)

------
skizm
It is pretty well known there are a lot of false negatives in the hiring
process since it is so much worse to make a bad hire than it is to not make a
good hire. Sounds bad and it is, but no one has a better solution than try
again in a year.

------
icando9
IMHO, I don't think it requires any practice to be able to invert the binary
tree. It is so trivial that it only requires a very basic level of programming
skills. I agree whiteboard is generally broken, but for this particular case,
I don't think Google is doing wrong. We can think another way, if some company
hires people based on his reputation instead of the ability of doing actual
work, I don't think it will survive. In this particular case, you just didn't
show your ability of doing actual work, that's it. I am glad to see that
Google prefers ability of doing actual work to reputation.

------
philip1209
What's the due diligence like on the hiring side during an acquihire by
Google?

~~~
dguaraglia
In my very limited experience? None. They just trust the company they acquired
to have filtered you properly. They do ask for references (like academic
records and so on) but that was about it.

Without discussing too many details, I believe the issue with Google's
recruiting process is it was designed when the company was smaller and it
follows the philosophy that anyone that goes through the hiring process should
be ready to be thrown into any of the many Google projects and be able to
function immediately. That's not strictly true anymore.

You have some divisions that are extremely hardcore or require very good
knowledge of a particular field (think Google Cloud Platform vs. Android
Kernel vs. Chrome vs. Search, all completely disparate projects), but there's
also work for people that don't need to hold a PhD from MIT (think front-end
development.)

~~~
npkarnik
Hmm, it depends a lot on the size/type of company and reason for acquisition.
If it's closer to a acqui-hire where the employees of the "acquired" company
cease development on whatever they were doing and eventually just get staffed
on a Google project, then they will MOST LIKELY do technical due diligence on
each team member. It's common for only part of the team to get an offer to
join.

------
lmilcin
Good engineer you didn't hire is not much of a cost to the company (other than
resources wasted on hiring process and perhaps some bad publicity).

On the other hand bad engineer will stay at the company, lower standards,
damage morale and set bad precedent to other engineers.

Being engineer myself, I feel much more motivated working in an environment
where you can just assume, even before meeting, that the other person is
intelligent and motivated. You trust hiring process to filter everybody else
so you don't have to subconsciously distrust every person you meet.

This comes at the cost of situations like that.

------
Frenchiie
I dont want to be an ass but how do you not know how to invert a tree? Anyone
who knows how to write a tree and traverse it should be able to do this. If
you ran out of time coding it then that's different.

~~~
jbrukh
Not even. If you know what a tree is, and you've written a couple of recursive
problems on trees in your life, then you know most of them are approximately
5-6 lines of code.

If you're spending 45 minutes writing 5 lines of code, it is not definitive,
but certainly a red flag.

~~~
gaustin
Nobody in this thread has even been able to define what inverting a tree
means. (Reversing or mirroring? Sure.) My search for how to invert a tree led
to a bunch of fairly hairy academic papers.

If you have a definition, please elucidate.

------
randomsoul
An Indian eCommerce company wanted to test my mathematics while interviewing
me for a VP of Marketing role. I had to tell them I won't fit into their
company culture, let's not waste time further.

------
dj_doh
My 2cents here - I respectfully declined to answer any JavaScript/CSS
questions prompted by a recruiter.

Being a front-end guy, I proactively request for hiring manager or a senior
front-end engineer from the team.

------
philippnagel
What's the practical point of performing such an operation?

~~~
x3n0ph3n3
It's similar to reversing a sorted array, though I can't think of a reason I'd
ever do it.

------
beliu
We're trying a different approach at Sourcegraph. In addition to looking at a
candidate's prior work in open source if available, we ask them to complete
tasks that approximate the job as closely as possible (i.e., coding on a
computer): [https://sourcegraph.com/blog/programming-
interview](https://sourcegraph.com/blog/programming-interview)

Would love to hear people's thoughts and feedback!

~~~
oxryly1
Yours sounds like an approach that measures how well someone codes in a
vacuum, instead of how they operate on a team. It very much skews the
results...

Not to mention for a qualified professional candidate, it feels an awful lot
like you're asking them to work for free.

~~~
beliu
In addition to asking them to write some code, we also have each member of the
team interview them onsite to get a sense of how they'd interact as a member
of the team. The challenge does take a few hours, which is longer than a
typical phone screen or single onsite interview, but because it lets us focus
on getting to know the person onsite rather than go through a gauntlet of
whiteboarding interviews, we think it actually saves time for everyone and is
a win-win. Obviously, every candidate is different; we think of this not as a
rigid template, but a better default option than whiteboard interviews. Thanks
for your thoughts!

------
oh_sigh
The problem with google interviews and tech interviews in general is that it
is almost impossible to capture what makes a successful candidate in a couple
of mini interviews. They don't even pretend that what you do in the interview
is what you will be doing in an actual job there. Most of a developers time is
spent in meetings, understanding their problem domain, writing documents, or
reviewing other developers documents.

------
utuxia
I don't even bother responding to any of the Big 4 when the reach out every
few weeks. They all ask these ridiculous questions.

------
mparramon
Wrote a blog post about exactly this problem: optimizing interviews for fancy
algorithm solving, when the position's daily work is nothing like that:

[http://www.developingandstuff.com/2015/05/why-i-dont-do-
codi...](http://www.developingandstuff.com/2015/05/why-i-dont-do-coding-
tests.html)

------
gjc
Can someone please help solve the problem? I have created a bounty:
[https://www.bountysource.com/issues/21606252-please-solve-
bi...](https://www.bountysource.com/issues/21606252-please-solve-binary-tree-
inversion-problem)

------
k4rtik
Anybody noticed ‏an istx25 stalking each tweet-job suggestion and ultimately
getting busted[1]? :D

[1]:
[https://twitter.com/markmcerqueira/status/608914346706657280](https://twitter.com/markmcerqueira/status/608914346706657280)

------
treffer
Doesn't this contradict an interview with Senior Vice President of People
Operations

[http://www.wired.com/2015/04/hire-like-
google/](http://www.wired.com/2015/04/hire-like-google/)

------
lnkmails
This was years ago but a google interviewer asked me a make a complete copy of
a directed graph (i have to do cycle detection). I was given 45 mins total and
I failed. I cursed myself for not being good enough. I haven't forgotten it
yet.

------
zippy786
Google, if you have really smart people working for you then make a new
problem solving question for each person you interview! The current interview
standards highly promotes memorizing stuff which is pathetic.

------
atmosx
I wonder what an interview process at Google with Linus Torvalds or Theo de
Raadt would be. I take for granted that the interviewer would not had a clue
about their accomplishments.

Would they manage to pass the process?

------
ised
Personally, I'd prefer to work at a company where 90% used pkgsrc.

------
z3t4
At least he didn't get put off because his CV had the wrong font. It was
actually a technical question. They probably have binary trees that needs to
be reversed everywhere in Google :P

------
billconan
the tech interviews are so broken.

who does dynamic programming on a white board during a work day?

it's like you are recruiting an army, but testing people's gymnastic skills.
they should test street fight skills.

------
novaleaf
I don't know, inverting a binary tree seems like a pretty easy task. If I were
hiring a senior developer (to code as a primary task) I think it's a
reasonable fizzbuz.

------
aayala
Hiring/Interview process is broken and not only in Google

------
junkilo
Was hoping to gain some insight to improve interview cycles here but instead
just have agita.

Jobs come and go, great work is always great work, but friends are what I
remember most.

------
SQL2219
yep, hiring is broken.

[https://news.ycombinator.com/item?id=9689232](https://news.ycombinator.com/item?id=9689232)

------
eyeareque
Let's hope he makes a product that google wants at some point and then pays
him millions (or more) for it. (like whatsapp and facebook).

------
rconti
He sure has an awful lot of his self-worth wrapped up in whether he gets a job
offer from one specific company. It reminds me of being interested in a
particular girl in high school.

At a certain point, you learn that there are other jobs out there, and maybe
the one with the biggest name isn't the best one. I certainly wouldn't be the
least bit offended. Not when the market is flush with high-paying-jobs-a-
plenty, particularly for someone with his background.

------
skorecky
Probably could have just Googled the answer.

------
elif
I took my google interview as a gift from them to me. It showed me that I was
mistakenly interviewing to become a cog in a terry gilliam-esque corporate
machine, and that made me think hard about my path in life, and what i really
wanted out of a career.

------
pducks32
The best part is that someone important at Google say this and no matter how
they respond it's just funny.

------
hectorxp
change the license, add a clause saying google can't use it, and sue them
tomorrow

~~~
tbg
I know this was supposed to be a joke, but he can't retroactively change the
license for the current released version. Any license changes will only apply
to future releases.

------
sciencesama
i didnt understand can some one explain TLDR ?

~~~
ljk
guy made Homebrew, an OS X app, interviewed at Google; guy was rejected; guy
rant on twitter

------
jowiar
Last week I walked away from a Google offer that included a 70% raise. A large
portion of this was a rather dehumanizing interview process, along with the
realization that the process doesn't select for people I want to work with,
and weeds out most people who I do. I managed to do just enough in my
interviews to squeak through, but in doing so realized that it wasn't for me.

Walking through the cafeteria made me feel like I was back in CMU CS again, in
a bad way.

~~~
sshumaker
I think you may have left with the wrong impression. If you ask Googlers or
Xooglers alike, most agree that the people here are actually the best thing
about Google. Like anywhere else, there are some bad apples, but compared to
most other places the people here are on average more talented, nicer human
beings and more helpful. Certainly compared to your typical startup or other
BigCo.

In my nearly 3 years here, that is my experience as well. I've also spoken to
many engineers who have left who lamented the quality of their fellow
engineering talent at their supposedly 'hot' startup, compared to their former
team at Google. Or having to deal with way more unprofessional (or crazy)
management, prima-donna teammates, etc.

~~~
jowiar
As far as my specific interviewers are concerned, I liked 7 of the 8 as
individuals, which is great. What I didn't like was the company felt like a
monoculture. Same schools, same majors, same pre-education background.
Everybody looks the same, dresses the same, etc.

The process, on the other hand. Ugh. I have zero respect for Google as a
company after that.

It starts with the standard phone screen/day-long onsite/hazing ritual. Then
come phone calls with teams, and teams saying "yeah, we want you", and me
saying "sure, sounds good". The recruiter basically said "time for the higher-
ups to rubber stamp this, and here's the $$ to expect". Someone up the chain
said "well, we're not so sure, let's haul him back here for another round of
onsite interviews". Which I did, it went through the same process, and the
response was "well, maybe not you for this role, but lets set you up with more
teams".

All of this finally goes through, and I get an offer. Then there's a
negotiation that goes something like:

Me: I'd like 4 weeks to think about it while a couple of other applications
come back (keeping in mind they've dragged this on about 2 months longer than
it needed to be).

Google: You get 2.

Me: I'm at a conference week #2, but I'll do what i can to get a decision to
you Friday.

<Fast forward to monday of week #2>

Google: Have you made up your mind yet?

Me: I'd like to look at my options, and I'll get back to you COB Friday

Google: It's really important that we hear beginning of day Friday

<Fast forward to wednesday>

Google: Have you made up your mind yet?

Me: No. One of the options I was looking at is now off the table.

Google: So WTF are you waiting for.

Me: The other options

<Fast forward to Thursday>

<Phone rings while I'm at the conference>

Me: You can't pay me enough to deal with this.

Maybe no individual involved is a prima-donna, but the ego showed by the
company as a whole through the recruitment process is stunning. It felt like I
was dealing with the star quarterback who never considered that when they
asked someone on a date, they might get turned down.

~~~
hartator
What was their wording for "WTF are you waiting for"? This story felt like
abuse.

~~~
jowiar
The exact exchange:

Google: "Just checking in to see if you have an update for me? Can we set a
time to speak on Friday?"

Me: "I decided to pass on [OTHER OPPORTUNITY]. I let my manager know about the
offer last Thursday. I am out at a conference this week, and we're going to
discuss options on Friday.

Does end-of-the-day Friday work for you? 5? 6?"

Google: "I need to speak to you in the morning on Friday.

if you are passing up [OTHER OPPORTUNITY, misspelled] why are we waiting till
Friday. Can we talk now?"

------
michaelvkpdx
As goes the recruitment, so goes the employment.

If you wanted to work for an organization where everyone likes to show off
their skills to one another in the interviews, you'd have gotten the job, and
you'd be one of them.

The best interviews I find are like a first day of work (but unpaid). Your
experience and skills are established by resume and portfolio. The interview
shows whether you can work with the team and wrap your head around the org's
problems. If you're having to show off- well, that's how your work will be,
too.

Google's interviews convinced me, years ago, that there's no way I'd ever want
to work there. And that feeling hasn't changed one bit. Much like FB, it's an
org whose coding needs are really pretty trivial and the real work was done
and finished a long time ago (but there's plenty of need for debugging, egos
especially). If you want to work there and surf the gravy train, cool for you.

~~~
trustfundbaby
> Much like FB, it's an org whose coding needs are really pretty trivial

I was with you till riiiiiight there. Google isn't just a search company
anymore they're working on lots of very interesting _non-trivial_ things all
around the company.

~~~
discardorama
> Google isn't just a search company anymore they're working on lots of very
> interesting non-trivial things all around the company.

Right. And I really doubt that people like Andrew Ng or Geoff Hinton or
Sebastian Thrun were asked to invert binary trees....

------
comrade1
And Google engineers aren't the shit either. Their Java libraries are large
and unwieldy. They would learn something by taking an example from the apache
libraries - clean and straightforward, focused and small. I hate working with
Google code.

------
sagivo
I had very similar experience. This was one of the main reasons i decided to
create this:
[https://github.com/sagivo/algorithms](https://github.com/sagivo/algorithms)

------
Dewie3
Why is his profile picture the _attractions_ road sign as seen in Scandinavia?
:-)

~~~
jd3
Perhaps he's a fan of Susan Kare :-)

~~~
mymacbook
I don't get the message you're trying to send by this reply... and yes I know
who Susan Kare is.

~~~
jd3
Susan Kare designed the icon on Apple's command key. [0]

[0]:
[http://en.wikipedia.org/wiki/Command_key#Origin_of_the_symbo...](http://en.wikipedia.org/wiki/Command_key#Origin_of_the_symbol)

------
supergirl
big ego, looks like they made the right choice then

------
kzhahou
Max should add code in Homebrew to check if hostname contains
"corp.google.com", and exit with a message that Homebrew can't run inside
Google.

Petty, but fuck em. They don't want him, they shouldn't get the fruit of his
work.

------
smtddr
Disclaimer: GoogleFanBoy here, feel free to ignore or downvote.

So, I've interviewed with Google twice. Once was 3 years ago, the other was
like 2 weeks ago. They contacted me. The way I see Google's interviews is like
referee in Football _(soccer or "Futbol")_. Sure, you need a certain amount of
skill to play in the World Cup but you winning or losing can, and often enough
does, come down to a controversial referee call. You end up losing out to a
team that did a handball -
[https://www.youtube.com/watch?v=-ccNkksrfls](https://www.youtube.com/watch?v=-ccNkksrfls)
, but that's just how it is. What makes me like watching soccer so much is the
same thing that excites me about Google's interview process. Yes, there is
heartbreak and anger. Just like World cup fans get angry when their team loses
because they were denied a point for an off-sides call even when the player
was nowhere near off-sides.

\--- Is Google's interview process fair? Nope.

\--- Would I subject myself to their futbol-referee style of judging
candidates again? You bet.

\--- Do I think they should make their process more fair? Nope, let the drama
and __justified__ rant posts continue. Just like I want the unfairness in
futbol to stay as is. I was one of the people against putting the microchip
inside the ball to know for sure if it crosses the goal line. I want the drama
of a ref having to call it and sometimes getting it wrong.

I know people, especially on HN, love reliable & repeatable. I do too, except
when it comes to dealing with humans.

------
aaron695
Great, another self entitled engineer who thinks Google owes them a job
because they are sooooo good (Which, maybe they are good at some things)

But how about Google didn't give them a job because this is how they handle
failure, embarrass an entire company on Twitter to punish them.

