
A note to Google recruiters (and on Google hiring practices) - ajdecon
http://infotrope.net/2011/07/21/a-note-to-google-recruiters/
======
ChristianMarks
Reminds me of calls I receive from top flight hedge funds.

    
    
       "You'll be working with astronomically smart people who
       use crystalline cohomology to obtain the best 
       polynomial time  approximation algorithms for
       intractable problems. The engineer who did this taught
       himself calculus within ten to the negative sixty-seven
       seconds of conception."
    
       "Is that the work you have in mind for me?"
    
       "No. You'll be cleaning the group's digital bed pans."
    
       "That's OK. Perhaps you should recruit a Nobel Laureate
       for that role."

------
econgeeker
Here's the thing that I think some of the engineers in this discussion might
be missing: A company shouldn't consist of only engineers.

Don't get me wrong: I'm a software developer, and I'm a bit of a software
snob. I have trouble (though I've mostly overcome it) seeing Managers, CEOs,
marketing people, sales people, "designers", etc. as doing "real work" because
they're not engineers.

Maybe designers feel the same way about me. They should.

But the reality is, good companies need good designers, and with experience
I've discovered that designers can really blow your mind sometimes.

But the hiring process for a designer is not the same as the hiring process
for an engineer.

One area where I've personally been very dissatisfied with google is the lack
of customer support. I can't imagine asking programming questions to a
customer support person who was expected to help people with their adwords
account.

The person being interviewed here, and who wrote this blog post is one of
those "customer support" type people. Not pretending to be an engineer.

If you only hire engineers and your hiring process is engineer focused, you're
going to miss out on a lot of really good people, and you're going to have
non-engineering roles staffed by engineers who just want google on their
resume so they can go get an engineering job later.

And these are not the people you want helping others with their adwords
account.

(Of course I'm not familiar with the internal structure of google, so I'm
giving examples meant to be representative of the problem, but that might not
actually be true.)

------
birken
The people who do Google interviews do not spend any time looking at a
candidates past work or blog or skills because that is not what Google
engineers evaluate when it comes to hiring you. They are supposed to ask
technical questions and evaluate how a candidate answers those questions. That
is it... No analysis of their open source code, no mentions of an insightful
blog post they had written, just the information gleaned in the 45 minute
interview (at least in 2009, I don't know if this has changed since then).
Engineers actually took great pride in providing a good and welcoming
interview with thoughtful questions. There was even an internal forum where
people would discuss the merits of certain interview questions and ban bad
questions.

Recruiters however have a completely different job. They go around the
internet looking for candidates who look like they are pretty smart
(insightful blog posts, open source contributions, etc), however they don't
always have the deep technical ability to differentiate people who would and
would not be a good fit for Google. That is why you get into situations where
a recruiter excitedly encourages people to apply for a job, and then the
interview is upsetting for the candidate because it isn't what they were
expecting.

When interviewing people for my current job, I do a lot more of looking at a
persons blog or open source contributions if they have them when doing
diligence about potential hires, but I also expect them to perform, write code
and solve technical problems during the interview. I feel it does give me a
better overall sense of the candidate and allows me to make better hiring
decisions. However, at Google scale this just doesn't make sense, as when you
have tens of thousands of ultra-qualified candidates beating down the door to
work at your company, missing some people would have been good employees just
isn't that big a deal if that means your engineers can save a lot of time in
the hiring process.

~~~
econgeeker
"They go around the internet looking for candidates who look like they are
pretty smart (insightful blog posts, open source contributions, etc), however
they don't always have the deep technical ability to differentiate people who
would and would not be a good fit for Google."

I once created a LinkedIn account to see someone's profile. It was meant to be
a throwaway but I didn't delete it. The account had no activity, no
"insightful blog posts", no open source contributions, nothing but a single
job listing under a previous position.

Not being a real person, nobody contacted this account... except google
recruiters. And they did it persistently. It was right out of glengarry
glenross. They were very smug, which I thought was amusing because, well, they
were chasing a non-existent entity. (even if I didn't have my own startup, I
have no interest in ever working for google.)

When I didn't answer the first recruiter, after many emails, I was handed off
to another guy who felt this event was significant enough to send me, yet
another email about it. In it one of the things he said was: "I identify top-
tier engineers for Google"

Of course, when looking at his profile, his background is in recruiting, not
engineering, and his degree is in accounting, not engineering. (No disrespect
to accountants.)

I'm completely burned out on recruiter hyperbole, and absolutely have spent
the last conversation I'll ever have with a non-technical recruiter whose
trying to "evaluate" me. Here's how the last one went (before I started
refusing to deal with recruiters, which, by the way, produced better job leads
and better jobs.)

Her: Do you have oracle experience? (having not told me anything about the
job, other than it was a "coder" job.) Me: Well, I was writing java that
generated SQL dynamically to talk to an oracle database. The SQL had to be
dynamic because... Her: (interrupting) which oracle? Me: Uh, the one from
Oracle corporation. Her: What was the version number Me: (just because I'd
happened to see it in passing) 8i I believe. Her: OH, sorry, the client wants
9i experience. (9i, I later discovered had been released within the previous 3
months.) I'll keep you in mind and let you know if I find anything that
matches your level of qualifications. (From tone of voice, it was obvious I
wasn't "up to speed" in her eyes.)

Later I was awarded a patent as sole inventor for the technology I'd tried to
describe in her question.

Anyway, getting tired of constant emails from google recruiters, and irritated
at this non-engineers belief that he "identifies" "top flight" engineers, I
asked him what he looks for in a phone interview.

Here's a direct quote of his answer. Because this is obvious nonsense (he
can't evaluate any of these things from the perspective of an accountant) he's
clearly just playing buzzword bingo, and in the hopes of getting other
engineers past this fake "evaluation" to talk to real engineers, this is all
you have to say:

"The l things I look for when I'm having a phone conversation with an engineer
(at a high level): \- What big problems are they solving (large scalability
and storage issues, advanced algorithms, etc...) \- Involvement in complete
product development (are they shipping products or are mainly doing
integration) \- Technical coding, % of time they spend coding, languages
they're coding in. \- use of data structures and algorithm writing. \-
Educational background and motivation for making a change."

Note that "I got tired of being harassed by google recruiters" is probably not
a good answer for the last one.

From the original article: "I guess that’s why when I interviewed for my
transfer, I was told I was “not technical enough” to do the job I’d been doing
for 3 years already, supporting the Freebase community."

Google literally told this guy he was not capable of doing the job he was
already doing, and given that it was a startup, a job he had likely created
himself.

"There are plenty of fresh-faced kids from Stanford and MIT and whatever other
elite universities are on Google’s preferred list, who can solve stupid
puzzles and tell you the O notation of anything you want."

Well, when your founders were graduate students at Stanford, and they
implemented a hiring policy right out of school, it shouldn't be surprising
that they have an arbitrary filter like that, and a focus on identifying
personalities that are nearly identical to the founders.

Finding people like yourself is orthogonal to finding good employees who will
find the best position. In the worst case it can result in a monoculture where
literally every employee is blind to a solution that would be obvious to at
least somebody if you had more diversity.

I've not worked with google, so obviously I'm just giving my impressions based
on my experiences being recruited by them (and this has happened ore than
once, the LinkedIn example was just the most recent.)

~~~
nostrademons
"Well, when your founders were graduate students at Stanford, and they
implemented a hiring policy right out of school, it shouldn't be surprising
that they have an arbitrary filter like that, and a focus on identifying
personalities that are nearly identical to the founders."

IIRC, Google's hiring process is largely imported from Microsoft (which was
the reigning tech giant at the time of Google's founding, so naturally they
looked to them to see what they were doing right) and GE (where Google's SVP
of People Ops had previously been VP of HR).

------
KevinMS
It will be interesting to see how a company that hires with a strong academic
bias competes in the long run.

I'm not sure but I suspect Apple is the opposite, and look how they are doing.

Update: is this not a relevant comment? What would motivate somebody to down
vote it? I'm curious because I care about the quality of HN, and I don't want
to see it become something like reddit where up/down votes are actually
like/dislike votes

~~~
Kylekramer
You assume something that is pretty illogical with no evidence (Google may
have a stronger academic bias than most, but Silicon Valley in general has an
education bias, Apple included). Also, the concept that Apple is doing well
and they don't have a academic bias, so that must be correct is correlation =
causation. For example, I hear Google has a strong academic bias, and look at
how they are doing.

~~~
KevinMS
I would be shocked to find that apple had the same kind of comp-sci bias that
google had. They must have a huge number of developers who have been with that
company since the 80's and 90's, a time when much of the industry was being
created by people with very diverse backgrounds.

~~~
mhewett
The company most similar to Google in hiring bias is early Oracle. In the
mid-1980s they were hiring every Stanford graduate they could get hold of.

~~~
cHalgan
Oracle still tries to keep up with standard. Getting hired to work in 400
building (RAC, ExaData, etc.) is still much harder than getting into Google.

------
mak120
I recently interviewed at Google and got an offer. I live in Bangladesh and I
am pretty sure no one involved in the interview process ever heard the name of
my university or cared what my CGPA was. So, the part about coming from an
elite school does not make a lot of sense to me.

The interviews were intense but all the interviewers were very friendly. I got
stuck at several problems but was given a lot of hints. And even when I
completely missed an answer, the interviewer was nice enough to point it out
without sounding rude or arrogant - or making me feel like an idiot. I must
say this was unexpected since I did make quite a few mistakes.

The way I see it, knowing about the right tool to use is important and useful
in our day to day work. But the guys at Google often have to create the tools
themselves (or better versions of them) for the scale at which they work.
Also, I got the feeling they want their engineers to be aware about what
actually goes on inside the framework/tool/database etc. instead of just using
it like a black box.

------
jrockway
_True story: in my interview I was asked how I would extract entities from an
HTML page. I suggested using OpenCalais._

So you're interviewing for a job as a programmer for a search engine, and your
answer to a simple parsing / text processing question is, "I'm going to use
some proprietary black-box third-party API to do the parse", and then you
refuse (on moral grounds?) to elaborate on how that service could possibly be
implemented? What?

I could understand something like, "Oh, I did that last week, and we used the
OpenViagra API." OK, cool, but the follow up question is going to be, "but if
you had to do it yourself, how would you do it?"

This is a good question for many reasons: for one, it's a basic "how do you
handle parsing" question. Parsing comes up all the time in programming, and
it's good to know if the candidate knows about regular expressions, parser
generators, parser combinator libraries, etc. It's not about "do you know how
to get HTML entities", it's about "do you know about parsing".

There's also something weird about relying on third-party APIs for simple
programming tasks. Sure, if you need to know your current location, you have
to depend on a bunch of orbiting satellites with precisely-set atomic clocks.
But if all you need to do is /&([^&;]+);/g, then write that one fragment of
code and move on with your life. The simplicity is well worth not having to
set up a TCP connection, wait for it to be established, generate a request,
send it over the network, wait for a response, time out and throw an error if
you don't get one, parse the response, and finally return the answer to the
calling code. Think of all the bugs you're going to have to fix with this
approach!

I'm going to start asking this question, just to see where it leads. If the
answer is more than one sentence, it will give me valuable insight into how
the candidate solves programming problems. If they answer, "well, I refuse to
do that", then that's valuable insight, too. All in all, a great interview
question!

So anyway, technical interview questions are not about getting things done,
they're about thinking through problems. Parsing HTML is a solved problem, and
of course you're going to delegate to a library. But tomorrow, you're going to
have a very similar problem to solve that is more nuanced and difficult to
explain in 30 seconds. And that's what the question is really getting at; if
you can parse HTML, you can parse the weird config file format you invent
tomorrow.

Google's interview process makes me want to work at Google!

~~~
nostrademons
Side note: /&([^&;]+);/g won't actually parse character entities in HTML
correctly. There're a number of corner cases in the HTML5 spec for historical
reasons, and this is one of them. In _some_ cases, it's legal (well, it's a
parse error, but the parser must return the specified entity) to leave off the
trailing semicolon. Except in attributes, where it depends on what the
character following the last character of the entity is. The particular cases
are enumerated in a table that is over 2000 lines long.

[http://www.whatwg.org/specs/web-apps/current-
work/multipage/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/tokenization.html#consume-a-character-reference)

The example is particularly instructive: &notit; is parsed as &not; followed
by "it;", but &notin; is parsed as a full entity.

So yes, even for HTML entity parsing (which wasn't the question she was being
asked), the correct answer really is "use a library".

~~~
jrockway
Here's the meat of my point. The correct answer when writing software is "use
a library". The correct answer when answering an interview question is code
with minimal dependencies.

~~~
paganel
>Here's the meat of my point. The correct answer when writing software is "use
a library". The correct answer when answering an interview question is code
with minimal dependencies

Which can be paraphrased as:

"Here's the meat of my point. The correct answer when building a wooden shack
is "use a hammer". The correct answer when answering an interview question
about building wooden shacks is to make the hammer first".

~~~
phuff
Which can be paraphrased as:

"Performance under modern software development interviewing practices has a
very low correlation with on the job performance."

------
voyvf
I lucked out; when a Google recruiter contacted me, I had just gotten a job
(had been doing contract work for a year prior.)

I'm pretty happy not being Google material - I have no degree, and I'll be the
first to admit that there are many Comp. Sci. graduates who can code circles
around me. I think that's awesome - I've reaped the benefits of the work of
many others before, and from the looks of it will continue to reap them (I'm
looking at you, PyPy team. Keep up the wonderful work! Let me be lazy, and not
have to write an extension in C or C++. :D)

The most advanced work I've done thus far would be writing out a somewhat
decent decision-tree system in C++ (I know, mind-bogglingly advanced! (: )

There's plenty of room in the mediocre to almost-above-average scale.

~~~
lawnchair_larry
PyPy is amazing, and actually a relevant counterpoint (vs Unladen Swallow) to
"the Google way."

------
cies
i'd have answered:

1) i would generally not implement that myself -- i like ruby-land's nokigiri
for this -- but

2) i can think of some ways how to implement that if i had (time+incentive) to
do so:

2a) - i could use regexps (easy to code)

2b) - i could write a litte parser (potentially much faster)

3) in case you want me to write the algorithm i will pick the regexps for sake
of brevity

~~~
drats
Someone's down-voted you without explanation, which is rather poor form.
Entities in this case means extracting the text of the page - with nokogiri
for example, or a variant of readability to get just the article - and then
extracting things that are named in that text.

I used a modded version of readability and a simple entity extractor in python
on the article and got: 'Sudoku', 'Search', 'Google', 'SRE', 'Stanford',
'Freebase', 'OpenCalais', 'SWE', 'Metaweb', 'MIT', 'Wrong', 'HTML', 'Developer
Relations', 'Interest', 'DON', 'True', 'CPU'.

A great introduction to all this is the O'Reilly book Natural Language
Processing with Python (free online[1]).

[1]<http://www.nltk.org/book>

~~~
zwily
I would have assumed they were asking about HTML entities. Like &amp;, etc.

~~~
nostrademons
A bunch of people assumed that, but it doesn't make sense given Skud's
background at Metaweb and her reference to OpenCalais.

------
cpeterso
My friend works at Google. The interview process is far from efficient, yet
the people involved genuinely felt the inefficiency was a good thing, some
sort of initiation to test candidates' perseverance.

From first contact to offer letter took about three months. He had four phone
interviews, a video chat interview, two email questionnaires, and two
recruiters before he met a human being.

Google is also unusually fixated on GPAs. My friend has a BA from UC Berkeley
and an MS from another school. Because his undergrad GPA (from 20 years ago!)
was not 4.0, the Google hiring managers wanted to know how many hours per week
he had worked during his undergrad to account for his 3.5 GPA.

------
nightski
Have we really reached a point in industry where asking a candidate to go
through the process of problem solving is frowned upon? Where "I don't need to
solve that because I have Google!" is really the right answer? I mean the
question seriously wasn't that difficult. What if there isn't an open source
library to cover your every need? Are you screwed?

Critical thinking and problem solving are important in any position. If you
are unwilling to perform this simple task then I would probably not want you
on my team either, no matter how many blog posts you had written.

I am sorry but extracting html elements is not crazy algorithms, hardcore
theoretical computer science, or nearly as "academic" as everyone is
screaming.

~~~
redcap
The author talks about being asked a question regarding web elements when he
was leaving the Search team for the Developer Relations team.

A commenter talks about being asked algorithm questions despite being
interviewed for a sysadmin role.

Another commenter talks about telling the interviewers that she is not a coder
and then is asked a bunch of coding questions despite interviewing for a
testing position and having written a book on testing and having years of
domain experience.

If you are just wanting algorithm people then surely they're going to be
lacking in other areas (e.g. Google Wave, designed by algorithmers).

The objections raised here seem to be along the lines of that the questions
are not related to the jobs people are interviewing for. This has two impacts:

\- people are not being asked questions about their domain (it seems
incredibly stupid not to ask questions about testing if the interviewer is a
tester)

\- you will cut down on the diversity of your staff if you just want
algorithmists (which means that you are more likely to produce more Google
Waves).

~~~
nandemo
Well, to be a very good software tester you do need to code. I wouldn't have
thought this to be controversial. Yeah, there are activities that don't
involve programming, like plain manual testing, test planning and management,
etc. But test automation and making code testable require programming skills.

------
skrebbel
A story like this gives me the impression that even if you want to clean the
floor at Google, you need to know when to mergesort and when to bubblesort[1].
Why does Google find this important? Why do people who will not do programming
at all need to know (relatively) low-level software optimizations?

To be sure, if I'd ever apply at Google (which I doubt), I'd probably apply
for a programming position and totally expect such questions. I'm asking about
the non-programming jobs.

[1]: not too far off though:
[http://web.archive.org/web/20050208031623/http://preacher.st...](http://web.archive.org/web/20050208031623/http://preacher.stc.cx/cleaningalgorithms.html)

------
radley
It's actually funnier when non-Google people try to give the Google interview,
but can't articulate the questions well enough to elicit clever solutions...

~~~
mkrecny
I had a one such really bad interview with google - I'm pretty sure the
interviewer was not a Google engineer, though she claimed to be (weird).

Here's the interview:

<http://www.mkrecny.com/entry/7/>

------
djtumolo
I interviewed there for a Product Manager position, and it was by far the most
technical interview I've ever had, and like the OP said, featured a lot of
computer science type questions. I know very few product managers that would
have done even as poorly as I did (I have a cs degree, but its been a while
since I've really used it). If I could have changed anything, I would have
loved to have been told that I would be asked CS questions in the interview.

------
cletus
Has it been two weeks already (since, you know, the last thread complaining
about Google's hiring processes)?

You can know a library that does exactly what the question wants, if anything
that's a plus, but you should roughly know how something like that actually
works.

Our process isn't problem-free. We gets hundreds of thousands of applications
a year. Who else has that scale of a recruitment problem?

There are a lot of myths about our interview process. Take this post: he says
he doesn't have a degree from an "elite university". Neither do I and neither
do most of my coworkers.

Having no degree at all _is_ a problem but not an insurmountable one.

As for us allegedly not being interested in your open source contributions,
nothing could be further from the truth. Recently the guy who did Firebug just
got hired to work on Chrome developer tools. Do you really think his Firebug
work had nothing to do with this?

As for what team you'll be working on, you as a candidate have a lot of power
in that regard. You can specify you're only interested in working on something
in particular or you can simply communicate some preferences. Those
preferences affect the allocation process.

Our predilection for simple coding problems and requiring a certain level of
algorithms knowledge is nothing new. What constantly surprises me is how many
people I see go through the process that obviously haven't just picked up a
copy of Skiena's book and brushed up on the fundamentals.

I can understand the motivation of people not to go through the process a
second time. I was in the same boat. It can be a frustrating process. It's
imperfect. Occasionally I'll hear people say they will never go through it
because of what they've heard.

As Homer puts it, "trying is the first step to failing".

I'll leave you with three recommendations for anyone interested in applying
here:

1\. Go through the first half of Skiena's algorithm book (the last half is
applications, which, while interesting, isn't as crucial). If you're not
comfortable with graphs and dynamic programming, sorry but you just haven't
prepared;

2\. Practice some code problems on a whiteboard; and

3\. Go through recruitment with a referrer. You're MUCH better off with a
recommendation from someone who already works here. Even if they don't
necessarily know you (and thus can't provide a strong reference), they can
chase up what's happening with your application with the recruiter and
probably get more information than you, as an external applicant, can.

EDIT: let me add a fourth piece of advice:

Treat your career at Google, if you're fortunate enough to have one, as a
marathon not a sprint.

If you're really unhappy on whatever project you end up on or with the team
you're with, that can all be changed. A lot of effort is made to make people
happy. So you can express your concerns and disappointment with your manager,
your manager's manager, HR or whatever is most appropriate.

Additionally, the ramp-up time at Google can be significant. 3-6 months.
Possibly longer. Another approach is to do what project you end up, learn our
tools, build system, processes, etc. In that time make connections to other
teams. Find out what else is going on and what you're interested in doing.

There is an awful lot of internal mobility that's possible.

~~~
NY_Entrepreneur
Never heard of a book by Skiena, so at Amazon found it and looked at the table
of contents.

Google should be ashamed to be very impressed with that book! The topics that
are just computer science are not very good, and the topics that are good are
not really computer science and are covered poorly in the book.

One way and another, for nearly all the topics in that book, I've worked much
more deeply with the topics from other sources.

E.g., there is just one, short section on linear programming. Gee, that's part
of optimization! I've worked in linear, non-linear, linear integer, multi-
objective, quadratic, network linear, and dynamic programming! I've published
peer-reviewed original research in non-linear programming.

Network linear programming is especially important: (1) the simplex algorithm
becomes especially efficient, and astoundingly large problems can be solved
astoundingly quickly (e.g., see the work of W. Cunningham on 'strongly
feasible' bases), (2) if the arc capacities are integers and the problem is
feasible and bounded, then there is an initial basic feasible that is integer
and the network simplex algorithm will maintain integer solutions to
optimality, (3) network simplex is also a good way to solve a wide variety of
matching problems. In particular, a large fraction of practical integer linear
programming problems are in fact such network flow problems or closely related
so that a network flow formulation and the network simplex algorithm yield
integer programming at no extra cost!

In particular, seeing integer linear programming, there is no good reason to
rush to claim that the problem is in NP-complete. Instead, if only via network
linear programming, often in practice there is good news.

E.g., there is a short section on hashing, but a discussion on hashing should
discuss both extendible hashing as in

Ronald Fagin, Jurg Nievergelt, Nicholas Pippenger, H. Raymond Strong,
'Extendible hashing—a fast access method for dynamic files', "ACM Transactions
on Database Systems", ISSN 0362-5915, Volume 4, Issue 3, September 1979,
Pages: 315 - 344.

and also perfect hashing. Extendible hashing is a very nice idea; we used it
in one large project that resulted in a high quality commercial product.

For "If you're not comfortable with graphs and dynamic programming, sorry but
you just haven't prepared"

If Google wants people to know dynamic programming from Skiena, then Google is
"not prepared"!

The glory of dynamic programming is how it handles uncertainty. Then it is
essentially the discrete time case of stochastic optimal control and Markov
decision processes. The Markov assumption, e.g., via conditional independence,
is important. There is a lot to the subject, e.g., the certainty equivalence
of the linear, quadratic, Gaussian case, multi-variate spline approximation,
scenario aggregation, dynamic programming approaches to the knapsack problem,
the technique of doubling up number of stages, and more. There are some
theoretical issues, e.g., measurable selection.

The interview I had from Google just asked my "favorite programming language".
Apparently the answer had to be C++. Due to the semantic mud hole of
Stroustrup's book, the terrible threat of memory leaks, the nonsense of
'cast', 'the heap', and 'the stack', the brain-dead exceptional condition
handling, the really weak compiling of string operations, the clumsy and slow
design of arrays, the far too simple design of structures, the brain-dead
rules for scope of names, etc., no one who takes solid software very seriously
should have C++ as a 'favorite'. Moreover, the question of a 'favorite'
programming language drags the discussion into the old mud hole of religious
arguments about programming languages any organization serious about computing
should long since have known to avoid. A good answer is that all the common
programming languages suck; some suck in unique ways; some suck for certain
purposes; and overall some suck more than others. Once I didn't say C++, the
interview was over. Good riddance.

Apparently the Google interview process is looking for only not very well
informed candidates with excessively narrow and elementary qualifications.

The people running the interview processes seem not very well qualified and a
bad influence on the future of Google.

~~~
stiff
_The topics that are just computer science are not very good, and the topics
that are good are not really computer science and are covered poorly in the
book._

You know that after reading only the table of contents?

 _One way and another, for nearly all the topics in that book, I've worked
much more deeply with the topics from other sources._

You worked much more deeply the topics in a book that you didn't read or even
see? And that's an argument for what? What relevance this has to anything?

 _E.g., there is just one, short section on linear programming. Gee, that's
part of optimization! I've worked in linear, non-linear, linear integer,
multi-objective, quadratic, network linear, and dynamic programming! I've
published peer-reviewed original research in non-linear programming._

Good for you, I guess. Again, what relevance this has to the discussion?
Because you did research you now want everyone to spend at least a year
learning optimization? You want all books to cover only advanced optimization
and not the basic stuff? You want Google to hire only people who took a
graduate-level optimization course? Doesn't make much sense.

It's hard to read this combination of arrogance, self-promotion and name-
dropping, which in the end hardly adds up anything to the discussion.

Also, the book by Skienna isn't the "official Google knowledge base", it is
just a book people recommend because it happens to be an easy way to prepare
for this certain kind of interview, I guess it started with Steve Yegge
recommending it on his blog for this purpose. I don't understand what's at all
the purpose of discussing its contents, when it doesn't have any relevance to
the topic. From what I understand they simply ask you some basic algorithm
questions at Google and I guess that's pretty natural.

~~~
NY_Entrepreneur
My main point in response to the post from the Google recruiter is that
Google's recruiting process is messed up, say, arrogant, inwardly directed,
process oriented, too narrow and particular, bending over backwards to find
silly reasons to reject people, and with irony, actually not "prepared".

My evidence is (1) the emphasis in the post on Skienna and the contents of
that book, (2) the claim about lack of knowledge of dynamic programming meant
not "prepared", (3) the common complaints about the Google process emphasizing
tricky questions, and (4) my experience where, with irony, if they like the
topics in Skienna, I certainly should have done well in the interview but
didn't.

"You know that after reading only the table of contents?"

Sure: I know nearly all the topics quite well. For the depth of coverage of
the book of each of the many topics, can conclude that the depth is shallow
because of the wide variety of topics in the book, a 'catch all', the few
number of pages for each topic, and the lack of more table of contents outline
details for the topics. E.g., in linear programming also need to discuss slack
and surplus variables, artificial variables, feasible, infeasible, unbounded,
bounded, optimal, basic feasible solutions, the simplex algorithm with reduced
costs, a pivot rule, entering variables, leaving variables, convexity, extreme
points, degeneracy, cycling, and performance. So, for much on linear
programming, will need more than one entry in the table of contents.

"You worked much more deeply the topics in a book that you didn't read or even
see? And that's an argument for what? What relevance this has to anything?"

It says (1) I'm qualified to claim that that book is a poor means of
preparation for a good interview in an appropriate recruiting effort and (2),
with irony, if Google actually likes the topics in that book, since I know the
topics well, I should have done well on the interview but did not due to some
Google recruiter's religious worship of C++.

"Good for you, I guess. Again, what relevance this has to the discussion?"

Again, the "relevance" of my knowledge of the topics in the book means that I
have some qualifications to comment on the relevance of that book for
interview preparation. My points here are that (1) Google should not be
recommending a particular book, since really there are many sources including
many much deeper than that book, but, perhaps, recommending a list of topics
instead and (2) they should not be asking about dynamic programming.

"Because you did research you now want everyone to spend at least a year
learning optimization?"

Heck no: I'm saying that mostly software developers should not be studying
optimization and that a Google interview should not be asking questions about
optimization at the level of that book. Mostly they shouldn't be asking about
optimization at all. If, in some particular case there is a good reason for
knowledge of optimization, then ask about the subject in a serious way.

Again, the claim that someone needed to know dynamic programming at the level
of that book or was not "prepared" is absurd. At the level of that book, f'get
about dynamic programming.

"You want all books to cover only advanced optimization and not the basic
stuff?"

You won't find anything like good coverage of the "basic stuff" about
optimization in that book. It's a very old story: There was a chemistry book
that wanted to introduce group representation theory because it plays a role
in molecular spectroscopy important for identifying chemical molecules. So the
book had a few pages on group representation theory. They had a mess. The
chemists came to the math department for some help. I ended up writing my
honors paper on group representation theory. The lesson is, people in field B
should not write short introductions to topics in field A. Instead, if want a
short introduction to field A, then get it from someone actually in field A.
It's important. Otherwise too often end up reading junk as in that chemistry
book.

That book is awash in topics in applied math outside of computer science. The
chances that the content is good, even for its short length, are slim to none.

There is a pattern in computer science: It keeps trying to borrow from other
fields and, then, makes a mess out of the content of the other fields. A big
example is how computer science borrowed 'machine learning' from statistics
and made a mess.

More generally, nearly none of the profs in computer science are qualified to
write about math at all. Sorry 'bout that.

"You want Google to hire only people who took a graduate-level optimization
course?"

No. Except for a position that is clearly in optimization, Google should just
f'get about optimization.

"It's hard to read this combination of arrogance, self-promotion and name-
dropping, which in the end hardly adds up anything to the discussion."

What I "add" to the discussion is that Google is making a mess of their
interviews. The "name dropping" is to establish my qualifications for saying
that Google should mostly just f'get about optimization. The "arrogance" is
Google saying that lack of knowledge of dynamic programming means not
"prepared". Then there is the irony: Apparently Google is not "prepared" in
dynamic programming in any meaningful sense.

For your last paragraph, the original post did make Skienna look like the
"official Google knowledge base" for job interviews.

"From what I understand they simply ask you some basic algorithm questions at
Google and I guess that's pretty natural."

No: The original post implied that a candidate should have reviewed the first
half of Skienna including dynamic programming, and my view, from good
knowledge of that material, is that, then, Google is doing poor interviewing.

~~~
dill_day
You are probably a very smart person, but your replies in this thread read
like the epitome of academic pedantry, verbosity, pomposity, etc... the `my
claim is (1) (2) and (3), my qualifications are these, my blah blah blah' --
Google is an engineering company; maybe you are better off working somewhere
else?

~~~
pnathan
Calling writing pedantic is another word for "I like sloppier thoughts than
these".

Precise and verbose writing is a hallmark of writing by someone who has put
thought into the subject.

------
throwaway878
I passed the software engineering intern interview process but wasn't matched
with a host (I assume because I applied late). I then reapplied for the fall
and am back at the host matching stage.

I have lots of high-quality programming experience, a MS from Stanford, and am
now wrapping up a PhD. 4.0/4.0 GPA.

If you work at Google and want a fall intern who will work his ass off for
you, please email me: stevebanders@gmail.com (not my real name - will reply
with my real name - don't want it associated with this post :)

My recruiter recently indicated that I should try to reach out to Googlers as
it might help draw attention to my application.

Edit: For the past two years I have been building search interfaces and
programming tools. However, I'm flexible - happy to work on just about
anything!

~~~
javert
The fact that people in the host-maching process at Google have resorted to
begging on Hacker News, points to the abysmal state of that process.

~~~
carbonica
Did you notice that you were responding to a MS+PhD applicant? Placing him is
going to be orders of magnitude harder than placing someone working on their
bachelor's.

If Google wanted to have him churn out features on Google Docs for a couple
months, they could, but that'd be an _enormous_ waste of a PhD.

~~~
throwaway878
Maybe, but I'd be happy to do it! I can always parlay the experience into
something larger.

~~~
jjm
If Google doesn't hit you up, dude I would surely look at some startups. In
fact, I believe Fresh Plum is looking for some really good people!

------
yaroslavvb
This approach can go both ways, I was hired despite just having a Bachelor's
from a 3rd tier US university

------
roldon332
I also was rejected after 'failing' a technical interview. What was annoying
to me is that I told the recruiter that I am rusty on my CS theory. I wish he
has just said; "We are only interested in people that could do very well on a
senior CS final exam right now"

------
motters
I can sympathize with the algorithm pop quiz tests. I've done a few of them in
various interviews over the last year, and I have to say that in every case
they bear precisely zero relevance to any software engineering that I've done
in the last 15 years. In one recent case I've even had an interviewer standing
and pointing over my shoulder at pieces of paper. It was pretty farcical, and
somewhat intimidating. In the real world, this isn't what writing software is
about.

~~~
paganel
> I've done a few of them in various interviews over the last year, and I have
> to say that in every case they bear precisely zero relevance to any software
> engineering that I've done in the last 15 years. In one recent case I've
> even had an interviewer standing and pointing over my shoulder at pieces of
> paper.

That's when I would have gotten out of the room and said "thank you, I don't
think we'd be a good match" :)

~~~
motters
Something similar did in fact occur.

------
thadeus_venture
Frankly, even a developer relations position can be a technical position. I
personally think a developer relations person who does understand the inner
workings of the code base he represents, or at least demonstrates the ability
to understand it given time, will be much better at his job than someone who
doesn't. So really, I agree with Google here in their decision.

There are a number of jobs at google that although do not involve writing
code, are closely coupled with the technology google is working on - developer
relations actually being a very good example. I think they are keeping the bar
high in these instances for valid reasons. I'm sure there are positions where
technical background is less crucial, graphic design comes to mind, but that's
to be judged on a case by case basis. Everybody wants to work there, so they
can demand very high standards, but in most instances i've heard about the
standards are not incorrect, just high.

EDIT: And probably another reason is they simply want to keep the particular
technical culture throughout the company.

------
flocial
Every interview process sucks. I interviewed and got a job at a company that
modeled their hiring on Google's asking me puzzle type questions. I can do
really good with those. Doesn't say a thing about my coding skills. I feel
sorry for the companies that model their process on Google's, especially the
small startups because you need the exceptional engineers that fall through
such cracks to really boost your business.

It's not so much the rationale of this interview process, reading the response
from other Googlers seems to show that this selection process does a good job
of maintaining a cultural fit for those that make the cut. The problem is that
it seems to make enemies of people without a hardcore technical background
when a simple review of their background would help both sides from pain.

------
roldon332
I was surprised at how CS Theory oriented they are in hiring. My technical
interview went like a CS final exam. I don't expect that I will apply to
Google again. If I was interested in CS Theory I would have got a masters in
CS. They have to weed people out somehow though.

------
chubs
I would have thought the easiest way to land a job at google these days would
be to start a blog, become a 'thought leader', start a few important open
source projects, etc, that kind of thing.

~~~
kenjackson
That gets you an interview. Blogs let you know you're a good writer, but
that's about it. Open source contributions can say a lot, but may not.
DarkShakira's work, for example, probably darn near gets him a job. 99% of
what I see on GitHub probably doesn't.

~~~
nostrademons
Though ironically, not a Google+ account. ;-)

(Side note: who's DarkShakira? A search for [darkshakira github] yielded only
this comment.)

~~~
kenjackson
Spelled his name wrong:

<http://news.ycombinator.com/user?id=DarkShikari>

He's lead dev on x264. Very impressive contributions. I have trouble believing
Google would push back much if they oould get him working on WebM.

------
poink
Can't you just tell them to stop contacting you? Works for me thus far.

------
null_para
Little bit off-topic; at least you get interview call from GOOG. I've never
had that privilege of interviewing with Google. Though I've always applied for
their design positions. And I was always referred by someone working at Google
(and that too stellar recommendations). I've interviewed with all the biggies
(including some of the hottest companies) but never with Google.

P.S. By the way, I have undergrad in CS too

~~~
rosser
I think part of the problem with Google's hiring process is the attitude
you're demonstrating here, where somehow even just _interviewing_ with them is
some sort of "privilege". Yes, I know they have to deal with a stupendous
number of applications, and much of their process is a direct result of that
sheer volume, but so long as people walk around with that kind of attitude
towards them, they're given all the excuse they need to be imperious about it,
to boot.

~~~
null_para
Agreed. By the way I remember talking with Google recruiter when recently I
was in school (one of the west coast elites) doing my masters; he told me the
best way to get into Google is via internship. I was interested in working at
startup for internship and told him the same. He bluntly told me that its
impossible for me to get a job at Google then.. :)

P.S. His prediction was true and I never interviewed at Google. However, I got
job offer from one of their biggest rival :)

