
Google's “Director of Engineering” Hiring Test (2016) - josephscott
http://www.gwan.com/blog/20160405.html
======
geofft
This was posted previously, in October 2016:

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

An actual Google director of engineering pointed out that these are
individual-contributor SWE/SRE questions (and I can attest I got very similar
questions as a new college grad).

As I commented previously: "Reading more closely, it sounds like they are not
interviewing him for a director of engineering position; it just sounds like
he thinks his current role, CEO-who-writes-code of a very small software
company ([http://www.gwan.com/about](http://www.gwan.com/about)), qualifies
him for a director-of-engineering-level position. He's probably being
interviewed for an SRE team lead or thereabouts."

Also, a ton of this conversation makes a lot more sense if you make the
assumption that the interviewee is misremembering the questions:
[https://news.ycombinator.com/item?id=12702726](https://news.ycombinator.com/item?id=12702726)
(Which is a very gentle assumption, if the interviewee also mistakenly thought
they were being interviewed to be a director of engineering.)

In which case, screening out someone with an inflated sense of their own
experience and overconfidence that the stupid person on the other end of the
phone is stupid is _exactly what this process is supposed to do._

~~~
waisbrot
> He's probably being interviewed for an SRE team lead or thereabouts

OK, but incorrect/inflexible quizzing about tech questions is inappropriate
full stop. If this was an interview for SWE summer intern it'd be a badly-run
interview.

> exactly what this process is supposed to do

You can't ensure that there will be no hurt feelings ever, but ideally the
candidates you fail don't go around talking about how poor your interview
process is.

> make the assumption that the interviewee is misremembering the questions

In your post you imagine slight differences that might make the questions more
reasonable. I think the main problem here is the responses to the answers. For
a non-engineer quizzing someone, the response to an answer should be "OK" and
then you note down the answer and show your notes to an engineer at the end.
This solves both the "that's not what's written on my sheet" problem and also
allows the interviewee to form a more nuanced impression of your recruiting
process.

~~~
geofft
> _incorrect /inflexible quizzing about tech questions is inappropriate full
> stop_

I don't disagree with this, but (to the best of my memory - this was in 2011),
when this initial phone screen was presented to me, it was presented with some
amount of "We want to figure out what you're good at so we're having the right
people interview you for the right roles." Which is to say, I suspect that him
failing out halfway through this screen was because of combativeness /
personality, not phone screen performance per se.

> _You can 't ensure that there will be no hurt feelings ever, but ideally the
> candidates you fail don't go around talking about how poor your interview
> process is._

I think I disagree with this though - there are certain people who are going
to be predisposed to complaining about things that don't go their way, and you
want to make sure you fail them as early as possible. At a company small
enough that its strength is the CEO's coding abilities, a curmudgeon with
significant raw technical talent can do very well. At a Google-sized company
they just can't.

~~~
socrates666
They can, actually...the culture needs to learn to adopt them is all.

Having real talent and having to basically navigate terrain of those with less
skill than you and yet, oddly enough, more power, is very frustrating. These
people can knock orders of magnitude off development cycles, and make subtle
decisions that affect your product years in to the future.

If anyone feels even remotely insecure because of your prowess you are shot
down. I was pushed out of Microsoft just for accomplishing a task that was
supposed to be impossible "because a senior engineer said so." In other words,
I did my job (I wasn't aware it was supposedly impossible) and then a
management chain became incredibly uncomfortable and dumped me.

You might say I'm the problem...I point to the stack of clowns that said it
couldn't be done and go...yeah sure.

~~~
geofft
> _These people can knock orders of magnitude off development cycles, and make
> subtle decisions that affect your product years in to the future._

These people can also _introduce_ orders of magnitude into development cycles,
and make subtle decisions that affect the product in negative ways years into
the future. I seem to have made a career out of cleaning up after these
people, and I have no sympathy for them. An amazing research project or tech
demo isn't an amazing sustainable project.

> _I was pushed out of Microsoft just for accomplishing a task that was
> supposed to be impossible "because a senior engineer said so." In other
> words, I did my job (I wasn't aware it was supposedly impossible) and then a
> management chain became incredibly uncomfortable and dumped me._

When I've seen this, it's usually because the task can be done 90% in a
straightforward way but 100% is impossible, and the person doing the task
thinks that doing it 90% counts, possibly because they're unaware of how
important the the remaining 10% is, and no amount of explanation will convince
them they're seeing the problem wrong. Then they should be let go, not because
they did the task, but because they're unable to understand requirements and
wasting both the time of others and their own time.

... all that said, there's a very good place for this type of person: small
businesses. That seems to be where the author of this article _is_ , right
now. He's got some weird ideas about how computers work, that are probably not
right, but maybe they are right and he's a genius and we're all years behind
him. He's built a product around those ideas. If he can sell the product, more
power to him. If he can't, and the product is meeting 90% but not 100% of his
customers' requirements, they just don't buy and go to a competitor. No
awkward conversations about firing, no wasted time trying to get their
existing hire to perform instead of hiring people who can do the job, etc. And
the burden of getting him to learn how to understand requirements is entirely
on him and not on anyone else.

------
andrew_
Tossing my hat in the ring with a similar experience. Was approached in 2003
because of an app I had written that got attention, and was told that Googlers
wanted to speak with me about the app. What followed was three calls with
gate-keepers of sorts, between which there was zero knowledge transfer from
call to call. None of them inquired about the app and all of them asked
questions so unrelated to the app that they might as well have been
interviewing me for a position writing Sanskrit. On the last of the 3 calls I
asked the interviewer when someone was going to inquire about the app, to
which the person replied that they had no idea what it was and that they were
told I had applied for a position. Though they couldn't tell me what that
position apparently was. I kindly requested they not contact me again.

I'm no all-star, I don't think I'm special, and I was still pretty green back
then. But that experience permanently put me off from any interest in that
company. It would seem Google HR / Recruiting hasn't improved in all these
years.

~~~
mindfulplay
To be fair, if any company hired you based just on your app, it would be
unfair to you and the company. Most software companies thrive because of
generalist SWEs who need to demonstrate consistent performance.

It might be that the app was a foot in the door but might not be applicable
past that initial point

~~~
waisbrot
I mean, you maybe wouldn't just send an offer letter to someone who wrote an
app, sure. (But depending on what they wrote, maybe you would. Something
reasonably large and open-source, where they ended up incorporating a
substantial amount of code from other contributors?)

But if someone's got 30kloc sitting there, why wouldn't you look at that body
of work instead of starting from scratch with "please write FizzBuzz on this
whiteboard"?

~~~
vlovich123
Because reading someone else's proprietary code exposes the company
potentially to liability? Not just claims of IP theft, but there would have to
be legal vetting that you have the right to show that code in the first place.
Also, I have no way to confirm how much of the code you wrote yourself.

------
DannyBee
So, as part of my job, I have been the hiring manager for directors for Google
(3 in the past 6 months), and recruit quite a bit.

This was a simple phone screen, and it seems the recruiter was not given a
good set of questions.

However, I actually doubt it was really a director of engineering screen,
despite this person's experience level (maybe it should have been, but ...).

I say this because I know a lot of the leadership recruiters, (it's a separate
thing from regular SWE/manager recruiting), and I know how the process works.
They don't screen candidates this way normally precisely because it doesn't
make sense. (Whatever you may think of Google's regular non-leadership
recruiting :P)

Instead, they ask question directly relevant to what the hiring manager
wants/needs (IE i give them the questions to use), and in most cases, do just
enough to know whether it would be a waste of time for the hiring manager to
talk to them. At which point, a hiring manager like me talks to the candidate
and decides whether to bring them in for onsites.

This particular set of questions seems closer to standard non-leadership SRE
questions.

~~~
fjsolwmv
I thought Google hires into a general pool, and hiring managers don't "own"
candidates like Amazon HMs do.

~~~
Eridrus
It's probably different for leadership candidates simply because there are far
fewer available roles.

------
eitally
> Recruiter: that's not the answer I have on my sheet of paper.

This is the problem. Google hires as such ridiculous volume (onboarding >5000
people last quarter, and on average growing at ~10000 employees (FTEs) per
year) that the process gets abstracted into whatever Google thinks can be done
algorithmically. This makes almost no sense for most roles, including any type
of specialist as well as middle/senior management, and you end up with
situations like you faced.

If it makes you feel better, it's equally frustrating for hiring managers, who
just get input from recruiters that so-and-so failed the phone screen. I'm at
the point where I tell my recruiters to let me do the phone screens myself
whenever they come across what -- on paper -- looks like a strong, viable
candidate. <banghead>

~~~
itissid
Reminds me of the time a TSA person at the airport asked a programmer at the
port of entry to answer some canned CS questions from wikipedia and expected
the exact answers...

~~~
cordite
Could you find the source for this?

~~~
KboPAacDA3
[https://www.wired.com/2017/03/immigrant-says-customs-
quizzed...](https://www.wired.com/2017/03/immigrant-says-customs-quizzed-
prove-can-code/)

------
_Marak_
Google hiring has been fubar for years now.

I think many of us here have been contacted ( unsolicited ) by Google for job
interviews in the past.

My Google interview story ends with me stopping the 8th interview ( 4th
technical interview ) half-way in due to the frustration of listening to my
interviewer loudly reply to text messages on his phone while I'm trying to
write very complex source code into a shared Google Text Document using no
other development tools.

At one point the 8th interviewer asked me if I had ever used Github before.
Considering Google cold-contacted me on my public Github email address and
half my resume was Github projects it was obvious this guy didn't even look at
my resume...

~~~
s17n
I make it a point to not read resumes unless I'm supposed to be asking
questions about their contents, to avoid bias.

~~~
crispyporkbites
Is this sarcasm? You just make your entire hiring call on talking to the
person without looking at their career, academics and skills?

~~~
psyc
I doubt it's sarcasm. I've often lamented that as a 30-year 'veteran' I'm
still often treated as though I'm probably incompetent, until proven otherwise
beyond a reasonable doubt. Some people do ignore my CV. I know that some
people believe this is _right and necessary_ because you can't trust anyone. I
believe it's a travesty in this industry, and if I am treated this way, I'm
walking straight out the door and into my next opportunity.

~~~
GlennS
How _do_ you interview someone more experienced than yourself?

In the last set of interviews I had to do, I've ended up doing the role of
talking to people about the technologies listed on their CV and asking them
detailed questions to find out just how well they really know them. This just
because I happened to be the person in our company who knew a little bit about
most of the things that the people we were interviewing claimed to be good at.

Sometimes you have a really nice technical conversation with them and discover
that they're clever and knowledgable. Sometimes you uncover a blagger trying
their luck. Sometimes a bit of both. So, it's a useful part of the interview I
think.

So very recently we interviewed someone with 30+ years of experience, more
than any programmer at our company (only 3 developers), and much more than
myself (8 years).

So I went away and did a little bit of research about the technologies he'd
talked about: COM and Corba and JBoss and other artefacts 80s and 90s, and
tried to ask some questions in as respectful a way as I good, and I hope he
wasn't too annoyed. In the end he was great (actually I found his enthusiasm
and attention to detail pretty inspiring) and we hired him.

I can definitely see how a person would be annoyed by that sort of probing
though, especially when the interviewer doesn't know what they're talking
about.

But, what's the alternative?

~~~
mempko
The alternative is for our field to have a strong organization that vets it's
members, like any other professional field such as lawyers and other
engineering disciplines. That way, before you even meet the person, you can
assume a level of competence and can get into much deeper questions faster.

~~~
ThePawnBreak
And then all the high-paying jobs will go to people who went to MIT and
Stanford, and if you're great but couldn't afford more than community college,
tough luck, because your credential is the same as other people who barely
finished high school.

~~~
s17n
I think that would probably already happen if it weren't for the fact that
there are more high paying jobs then there are MIT/Stanford/etc grads.

------
jroseattle
We experienced the same type of issue with my company, and decided to try to
address it.

First, our problem statement: filtering phone-screens by recruiters is
resulting in poor experience, false positives, etc.

We thought about potential causes, but instead opted to look at the logistics
of the call: recruiter runs process, gets responses, and then returns to
engineering with feedback.

It was a vacuum filled with innuendo, unspoken assumptions, you name it.
Collectively, our recruiting operation was an echo chamber.

So we asked if we could have recruiting calls recorded and/or transcribed.
Candidates had no problem agreeing to it -- the recruiters were reluctant at
first. (You can probably guess where this going...)

We recorded/transcribed maybe five calls, and that's all that was necessary.
We saw dramatic improvement, and we owe most of that to the Observer Effect.
We maintained the same throughput of candidates, but we saw more ideally-
suited candidates pass through as well as heard better experiences from
candidates.

I'd suggest most any operation try this.

~~~
jvreagan
Love the idea, thanks for this!

------
pinewurst
Another data point - I had a very similar Google recruiter "test", being
disdainfully dismissed because I couldn't/wouldn't regurgitate the same
incorrect template answers they had. I've since terminated any approaches by
Google recruiters as being a waste of my time and emotional energy.

~~~
warty
According to their recruiters, I "need to learn Java and algorithms" to get an
FTE phone screen.

~~~
danpalmer
I had this when I applied as a grad. I wasn’t clear what they were looking for
so I asked if they were looking for algorithms and language agnostic
programming ability, or whether they were looking for Java and Java standard
library knowledge. They wanted the latter, just Java. I didn’t continue my
application.

------
jason_slack
One of my interview questions:

Interviewer: What is the difference between a mutable and immutable string?

Me: A mutable string can be changed. A immutable string cannot be changed.

Interviewer: Nope, think mutations. Mutable string can be mutated.

Me: Mutated? Altering DNA?

Interviewer: If you don't know this there isn't any sense in asking more
difficult questions.

Me: Floored.

~~~
itronitron
I hope you didn't list String expertise as one of your technical skills.

~~~
jason_slack
Explain?

~~~
itronitron
It is a joke, as so many interviewers complain that people lie about their
technical skills and experience, if you listed String as a technical skill and
the interviewer thought you didn't know what a mutable String was then they
would conclude that you lied about your skill set. Hopefully you can see the
humor. I feel your pain so can understand why you might not think it is funny.

~~~
jason_slack
I thought it was a joke but then I talked myself out of it :-)

Yeah interviews have been rough this time around. Before this I hadn’t
interviewed in 10 years.

------
wyldfire
> Recruiter: that's not the answer I have on my sheet of paper.

When I got a similar screening from GOOG, the recruiter confessed upfront to
having these technical questions scripted and seemed much more flexible than
this particular one.

> 7\. what is the name of the KILL signal?

The question might have been "what is the default signal sent by 'kill'?" The
answer to that question is SIGTERM and not SIGKILL. The recruiter may have
asked it wrong, the question may have been written vaguely for the recruiter
or the interviewee may have misunderstood/misheard the details of the
question.

~~~
geofft
Also, if you can't have enough of a conversation with someone who's unfamiliar
with the "kill" command to figure out exactly what signal they have in mind
even when they're using the wrong words, and without getting upset at them or
deciding that they're beneath you, you're not qualified to be a director of
engineering.

~~~
jerf
That is true, but on the other hand, if the person reading the script stands
on the wording of the question, as soon as they read the "correct" answer
you've lost. There's now no recovering, because "obviously" now that you've
heard the right answer you're just spinning to explain away your failure.

(As with others, I will stipulate that accuracy in this report may not be
100%, but I'm not necessarily willing to assign it 0% either, especially as
I've encountered people like that myself.)

~~~
geofft
So the trick is to not answer the question immediately if you're unsure, but
ask to clarify. Which, again, is a good skill in life (as an IC, and certainly
as a director of engineering). If you're reviewing your coworker's code and
they got something wrong, asking "Can you clarify what you meant here" will go
over ten times better than "You're wrong" (and a hundred times better if
they're not in fact wrong). Maybe this is a bug in human cognition, sure, but
at a Google-sized company you can't get anything technical done without
interfacing with buggy humans on a regular basis.

"The KILL signal? So you're calling the kill function with KILL as an
argument, or typing kill dash KILL, or...?" would have cleared up the
confusion immediately, because even a screener unfamiliar with the material
would have said "Oh, that's not what I'm asking."

I do strongly believe that the questions _as written down_ are not as reported
in this blog post, because there are tons of other sources who have written
about being asked this question in an initial screen, and they all phrase it
as "What is the signal that the kill command sends."

------
zeroxfe
This is the pre-screen, very likely conducted by a poorly-trained (or
incompetent) recruiter. IIRC, there is a ton of room for response variety in
the answers, and the screeners are trained to handle them (obv. very difficult
to do well.)

The pre-screens are act as first-pass filters before the actual interviews
(conducted by engineers.) Google does many hundreds (if not thousands) of
these a week, and this false-negative is an unfortunate casualty of the
process.

~~~
onion2k
_Google does many hundreds (if not thousands) of these a week, and this false-
negative is an unfortunate casualty of the process._

Yes, and it's worth remembering that _Google_ are the unfortunate casualty
here. Being rejected as a false negative sucks as a candidate, but ultimately
there are plenty more developer jobs around if you're actually good. As a
business rejecting the right person could cost hundreds of millions of dollars
in lost revenue, mistakes, and bad PR.

~~~
Bjartr
Google believes the opposite, that hiring the _wrong_ person could cost that
if they have a negative impact on the teams they work in so they prefer false
negatives over false positives.

~~~
freyir
This happens because companies are unwilling to fire employees, even
incompetent or toxic employees, for fear of lawsuit.

~~~
quacked
The lawsuits happen because people don't have real savings due to high cost of
living/lifestyle inflation and reliance on employer benefits. If losing your
job wasn't such a potential death sentence, I think it would be easier to fire
people.

------
nimbius
ive had 3 google interviews, one on-site, and I can say without a doubt that
its not only demoralizing but a complete waste of time. Reading their own
outline of the hiring process and watching the youtube video, I was instructed
that "goofy" google questions weren't asked anymore. No less than 5 minutes in
the meeting room and I was met with "how do you build a datacenter on the
moon?" followed by "how many cans of beer can you fit in a school bus?"

My latest phone screen about a year ago started off with a technical recruiter
handing off from Mountain View to a recruiter in San Diego, then passing me
back to a technical screener in mountain view who couldnt remember his
questions. The follow-up technical review came from Boulder Colorado and
focused on C programming and Linux dynamic libraries for a SRE position.

All in all I hope they get their hiring process sorted out. The most
disparaging and frustrating thing is hearing "just keep trying! everyone has
to apply at least N times before they get hired." The fact that this sentiment
exists at all speaks volumes to the management climate.

~~~
mirceal
how many cans of beer can you fit in a school bus parked inside of a
datacenter on the moon?

------
organicmultiloc
I interviewed at Google a million years ago and got the same sort of "trivia
list", which was surprising to me. I passed most of them and everyone seemed
excited about me while I was there, but then I started criticizing the
interview process and (more importantly) Google Finance as being pretty bad,
and this really upset everyone.

I could tell they weren't used to ever being criticized, pointing out how the
interview process had effectively zero behavioral aspects or problem solving
questions, as well as all the gaps between one of their products and the
competition, and they did not give me an offer.

The funny part is they incorporated much of my feedback into Google Finance
years later. It's still a mess, but hey at least they made some progress.

~~~
ionforce
> then I started criticizing the interview process and (more importantly)
> Google Finance as being pretty bad, and this really upset everyone.

Not rocket science, everybody. Who knew that people don't respond well to
being criticized by strangers! Nobel Prize.

~~~
eli
I'd love to hear thoughtful constructive criticism during an interview. But
unsolicited negativity would be a bit of a flag.

~~~
Retric
Seems like a complete wast of time in an interview. If you join then sure
mention it, and if your rejected you can send an email or something but it's
not constructive during an interview.

~~~
danpalmer
We interview specifically for people who can give and take constructive
criticism. There are points in our interview process where giving a rational
and constructive critique of our product would be a very good thing for a
candidate. These are skills we value highly as they help employees improve
faster.

We also do check for negativity in candidates though to balance this. Critical
feedback can be given effectively without needing to be rude or unpleasant.

------
DrNuke
Google hat or not, monkeys are still monkeys, but this case shows a problem
that is very common to all the employee positions, from the very bottom to the
very top: all monkeys must watch, hear, talk and jump to get their peanuts.

------
outside2344
What that list should really have in it is:

1) A female employee complains of harassment: what do you do? 2) What is an
effective devops approach for an Android app? 3) How do you build a culture of
teamwork across teams versus a zero sum culture.

------
lisper
My Google phone screen circa 2013 went something like this:

    
    
        for (i=0; i<NUM_QUESTIONS; i++) {
          Interviewer: [Technical question]
          Me: [Answer]
          Interviewer: That's right!
        }
    

Followed by:

Interviewer: You do understand that the position you have applied for is a
managerial position, and that you're going to be dealing with schedules and
budgets and not anything technical. Is that really what you want to do with
your life?

Me: Um, no, not really.

Interviewer: OK, well, have a nice day then. Good bye.

~~~
ScottBurson
?? But you had worked there before, right? Didn't they remember you?

~~~
lisper
> you had worked there before, right?

Yep. :-)

> Didn't they remember you?

If they did, they hid it well.

------
koolba
This is so good I can’t tell if it’s literal or a parody. The part about
inodes in particular.

~~~
geofft
The interviewee's answer to the inode thing is simply wrong. An inode _is_
metadata (or "attributes", sure): it's not an index or an identifier. I think
the interviewee is thinking of the _inode number_ , which is a related but
different thing. The interviewer was right.

~~~
psyc
[http://www.linfo.org/inode.html](http://www.linfo.org/inode.html)

I swear this is about the 20th time in a week I've seen a good comment (the
parent) in the gray. Unless I'm imagining things, this has been happening with
extremely noticeable increasing frequency. I've held off saying anything about
it for days while it keeps happening more and more.

------
neurobashing
I got the same test for an SRE gig just a couple years ago. Amazon fizzbuzz'd
me on the first coding test before I even went on-site. I know both have very
stellar hiring reputations and employ a ton of smart people but from my "man
on the street" experience, it felt more like a test of answering the right
questions than a test of skill.

the best tech interview I've ever had was at a company that didn't make me
write a line of code, instead preferring a lengthy conversation about coding.
On reflection it was a far more grueling test of knowledge than "implement a
hash table in C, you have 35 minutes".

------
charleslmunger
Plenty of discussion on the first time this was posted:

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

~~~
minimaxir
That was posted in 2016, so this submission qualifies as new content. (it
doesn't feel like over a year though!)

------
qooiii2
Google asked if I would do a phone screen a few years ago for an SRE position,
and I thought that process was hilarious. In my case the questions had nothing
to do with my background (microcontroller firmware for sensors) and it was
only by incredible luck that I could answer them. For example, I had just read
about some data structure the day before.

The recruiter didn't spend much effort telling me what the job was or why I
should consider leaving my current great position for it. I said, "no thanks!"
when I found out what an SRE actually does.

It seems like Google's interview process is designed to measure how much a
candidate wants to work at Google. This is probably okay for them, but it's
going to result in them overpaying for good people.

------
sidlls
What an absurd test.

However I'm more concerned that a "Director of Engineering" position has these
sorts of questions as a phone screen. Especially at Google, which has no
shortage of applicants for IC positions who would actually be doing this work
in any healthy and sane engineering organization. Does "Director of
Engineering" at Google actually mean "Software Engineer"? Is this like in
Finance where everyone is a Vice President of something?

------
ebikelaw
Whatever you are about to say was likely covered in the existing 1000-comment
thread
[https://news.ycombinator.com/item?id=12701272](https://news.ycombinator.com/item?id=12701272)

------
pfarrell
In my experience and from what I've gleaned from the outside, recruiting at
Google consists of shoveling as many bodies into the pipeline every week to
allow the top few to get picked for an onsite interview where it doesn't
matter if they say no to everyone because there are always more applicants
next week.

After getting through phone interviews and getting flown out to SF for an
interview at youtube, I made the mistake of thinking I was like 95% of the way
through the process. At google (and I suspect a few of the other
megacorporations), getting to onsite interviews means you now in the lottery
with similar chances.

------
w8rbt
Same experience here with the trivia questions. They called me out of the blue
about 10 years ago and said they wanted to interview me. So I said OK. Later,
during the interview, the questions were largely trivia. How do you remove a
file using the rm command when the file is named -f?

I was like, what sane person would name a file -f? Anyway, after I got over
the shock of the question... you can ./-f, use the absolute /path/to/-f or --
-f and maybe other ways too.

~~~
rorykoehler
Surely the correct answer is you Google how to do it!?

~~~
jstimpfle
These questions are supposed to work as a proxy for experience. Everybody can
google the answer to trivia, but if an applicant doesn't know the answer by
heart that's an indication for lack of experience.

~~~
rorykoehler
I still google things i know how to do that i don't use often because it's
quicker to copy and paste than to try remember details that are vague in my
memory. The example given is exactly one of those cases.

Even Jeff Atwood tweeted that he does this the other day.

~~~
jstimpfle
We all do it. There is no contradiction with the meaning of "Proxy". It's not
a requirement that you know the answer to _all_ of these questions.

------
tluyben2
I have no idea at all why people want to work for these kind of companies if
that is the entrance criteria; especially with that kind of seniority and
being abused like that. Was Norvig doing these tests I wonder? I do think
people overestimate the importance in their life of working for a company like
that.

------
pbnjay
I had a similar experience in 2013, which while I passed the screen it only
ended up matching me to SRE roles. I have PhD in CompSci so that was pretty
disappointing so I did not bother scheduling an onsite.

My more recent experience was a lot more positive, the screen is much more
conversational and coding-based and not a test of wrote memorization of CS
trivia.

I don't know if this is due to changes in the past 5 years or the recruiters
being from different teams.

------
trevor-e
Unrelated to the main point of the article, but I really hate when people
point out "been programming for XX years, since I was 6 years old!!" Years of
experience does not equate to being a skilled programmer. I could play
basketball for 40 years and be way worse than Lebron James was in middle
school. Experience is important for other reasons.

~~~
wolco
Translate the above to NBA coach. Very few high school coaches exist.
Experience matters not raw strategic skill.

------
nateburke
I had the opportunity to speak with someone who was on the hiring committee at
google when the company scaled from ~5k employees to ~20k employees. This was
the committee of people in charge of designing the interview funnel though I'm
not sure if it was for engineering, specifically, or the whole company.

He said that there were two very large compromises that had to be made in
order to hit those growth numbers:

1\. Near-total reliance on gpa and school prestige for entry-level position
initial resume screening

2\. Relaxation of membership controls on the internal pool of people at Google
qualified to administer the "is googley?" culture fit interview

I would not be surprised if "allowing non-technical people to pre-screen
technical people" is a similar growth-forward HR compromise made, resulting in
the OP's suboptimal experience.

------
bonestamp2
It's like answering riddles for a troll under a bridge.

~~~
hpcjoe
Paraphrasing from Monty Python's Holy Grail ...

"Answer these questions three, and a GOOG employee you shall be!"

------
hpcjoe
I had, literally, the exact same test. Only really missed the bit counting as
I brute-forced it (phone screen after all). Was interviewing for a similar
position. Was not advanced after on-site. Had a mix of good and bad on-site
people. Interviewer quality, viewpoint, attention all factor in, and in about
1/2 the cases, I had a strong vibe from them that they were disinterested in
the process/person.

I could comment on whether or not I thought their process actually produced
superior results or not, and how they would measure. I'll say it is at least a
small step up from their previous brain teasers.

Hopefully, they will continue to refine their processes.

------
throwaway84742
Many people don’t know this but quicksort is actually _quadratic_ in the worst
case, and it’s pretty easy to hit the worst case. Quadratic complexity is
pretty bad for a sort.

------
tzs
> There's an array of 10,000 16-bit values, how do you count the bits most
> efficiently?

I would have said that I would multiply 10000 by 16. Oh well, no Google job
for me I suppose.

~~~
poxrud
I find that the solution to a lot of these trick interview questions is to use
a hash table or some kind of a look up table. Even the famous google mock
interview video uses a hash table in the solution.

The solution to this question is to use a 256bit lookup table. You'd need to
precompute the lookup table that will give you the bit count of every possible
bit combination in a byte. Then traverse your 10,000 long array, use your
lookup table to count the bits and add them to your total.

~~~
tzs
Assuming that they want the number of 1 bits (the question asked for the
number of bits, not the number of 1 bits--hence my answer), it is not obvious
to me that a lookup table is the fastest.

Given an unsigned 32-bit value, v, this well-known bit hack [1] counts the
number of 1 bits:

    
    
      v = v - ((v >> 1) & 0x55555555);
      v = (v & 0x33333333) + ((v >> 2) & 0x33333333);
      count = ((v + (v >> 4) & 0x0F0F0F0F) * 0x01010101) >> 24;
    

If you can treat the 10000 16-bit values as 5000 32-bit values, applying the
above 5000 times might be as fast or faster than applying the table lookup
method to 20000 bytes. It will depend on precise details of the particular
computer on which it is run.

[1]
[http://graphics.stanford.edu/~seander/bithacks.html](http://graphics.stanford.edu/~seander/bithacks.html)

------
AboutTheWhisles
A lot of these were the recruiter having no understanding of what they were
asking, but the bit counting is just nonsense. A lookup table requires an
extra memory access that by its nature is incoherent.

Contrast that to being able to read the memory straight through and having it
prefetched, then using the popcnt instruction:

[https://www.felixcloutier.com/x86/POPCNT.html](https://www.felixcloutier.com/x86/POPCNT.html)

~~~
zeusk
> A lookup table requires an extra memory access that by its nature is
> incoherent.

Pedantic but, the LUT would also remain in the cache if there wasn't some
issue with cacheline contention.

Although, I do agree that POPCNT + prefetch and unrolling will do much better.

~~~
AboutTheWhisles
I thought the same thing, although I've tried LUT approaches to other problems
like gauss curves and the results were much slower than I expected. The LUT
may stay in the L2 cache, but whatever was going on, there was actually a big
discrepancy between looking values up and just calculating the gauss curve
equation even though it had exponents on floats.

------
compumike
(Disclosure: I'm an engineer & interviewer at Triplebyte)

These false negatives are avoidable with a better-designed screening process.

This "exact match" issue is why we use multiple choice questions (pick from 4
choices) for initial technical screening. If you know what you're talking
about, the format is far more forgiving to all of the cases described in the
post, as you can rule out obviously incorrect answers. If you don't know what
you're talking about, your odds of doing well are are stacked against you
after a few questions.

Once you're doing a video interview with one of our engineers, we know what
makes sense, can ask follow-up questions, and if you plausibly know more than
we do about a topic, can make a note to look things up or ask our teammates in
#interviewers.

(Note: we're hiring remote engineers to grow our interview team:
[https://news.ycombinator.com/item?id=16815444](https://news.ycombinator.com/item?id=16815444)
)

------
wyldfire
> Me: on which kind of CPU? Why not let me compare my code to yours in a
> benchmark?

While I agree that this is the right answer, questions regarding "Big-O" are
trying to find out whether or not you can evaluate the complexity of an
algorithm. If you can, you have some hope of writing different useful
benchmarks that could be compared, where sometimes you can see orders of
magnitude of improvement. If you can't, you might be just blindly tweaking the
code to get 1-5% improvement from compiler flags, assembly optimizations, etc.

In practice this recruiter might be bad at their job by binding themselves so
rigidly to the script.

~~~
SilasX
Well, I've been in this scenario before, and have resorted to that. I was this
guy [1]. (Interview question in link, I had written a solution.)

The interviewer stubbornly insisted that the run time was n^2 because it had
an inner loop. (Never mind that the inner wasn't looping over pairs with the
bigger loop, but just the bits within that element.)

I went through a number of heuristics to convince him otherwise: what if you
doubled the list, how would that analytically affect the run time? What if the
elements were bigger? (as you can find from the reddit thread)

Disturbingly, I asked him what he would need to see to convince him that the
_code I wrote_ was O(n), and he said, "no inner loop", which reveals a
profound misunderstanding of both the issue at hand, and how to resolve
disagreement. At that point, I resorted to saying, well, let's run the code
with increasing input size and see how it scales (which would give valuable
information about its actual scaling behavior).

Then he refused, left the room, and told the director to veto me from the rest
of that day's interviews.

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

~~~
wyldfire
> Then he refused, left the room, and told the director to veto me from the
> rest of that day's interviews.

"Bullet dodged" \-- he did you a huge favor.

------
ksk
I sense a little bit of CS ego in the interview. "Let me show you how you're
not even qualified to take this interview" is never a winning strategy in any
business scenario. Being able to read a person, and giving them an appropriate
response is an important skill. After the first couple of responses it was
pretty clear that the recruiter was only interested in cookie cutter answers.
If you don't want to work at Google why even take the interview? And if you
do, why would you care if a recruiting agency paper pusher asked you some dumb
questions?

------
maxk42
This pisses me off so bad:

Quicksort does NOT have "the best big-O". It's big-O time complexity is
O(n^2). Big-O refers to the _worst case_ time complexity. Quicksort will on
_average_ take (n log n) time complexity, but that's not its big-O, that's its
big-Theta. Some try to skirt this by saying "if you randomize the order of the
data first, it will be sorted in big-O of n log n" but again, that's the
_average_ time complexity, not the pathological case.

A lot of CS books teach this wrong. Please stop being wrong: O(Quicksort) is
O(n^2)

~~~
bmcfeeley
Big-Theta is not an average case, it is a special form of Big-O and Big-Omega
wherein the worst case is also the best case from a complexity perspective.

This is sometimes true in sorting since comparison based sorting cannot be
improved beyond n*log(n) except in specific cases for specific domains.

You are absolutely on the money about worst case being O(n^2) though for
quicksort.

~~~
maxk42
I stand corrected. Is there a notation for "average" complexity?

~~~
bmcfeeley
Not that I'm aware of! As you've seen, I see Big-O abused into shorthand for
"on the order of" to the effect of "average case is O(nlog(n))"

------
nfRfqX5n
my interview process spanned 5 months between all of them. really wasn't fun
trying to have a convo and answer questions while the interviewer types down
every word you say. seemed very robotic.

you get almost no feedback for spending all of that time, so you don't really
know where you went wrong or how to improve. i understand they can't say
anything due to the possibility of a lawsuit, but they should be able to
figure something out with that

------
bootloop
Interesting. My Google Interview started with 1h interviews with two Software
Engineers (who were working on Google AdWords) They asked mostly data
structure questions and gave a short exercise which I had to solve.

The first engineer had obviously lack of exp and interest in this process, the
second one was a lot more pleasant to talk to and I felt a lot more
comfortable. (Unrelated to my actual performance which was properly not good
enough in any case.)

------
jschwartzi
I would have hung up about halfway in when the recruiter said there was a best
sorting algorithm. That is patently false, and the best algorithm depends
heavily on your needs at the time which is where engineering comes in. Whoever
wrote that test didn't seem to understand what engineers do, but what makes a
competent engineering organization.

------
utopcell
I would have gently ended the interview the moment he mentioned using 64-bit
lookup tables to count bits 8 bytes at a time.

------
CodeSheikh
Yes this guy might have an inflated complexion of a self-claimed all-star but
to be honest Google and all big tech companies have really frustrating
recruiting process and most of the time interviewee's frustrations go unheard.
So this guy took the only approach that he could think off, is to take his
plea to the internet.

------
axaxs
This is nearly exactly the same set of questions I was asked for an SRE
position. My favorite of which, was 'what is not in a linux inode'. That was
the full question. My answer was sarcastic, and it didn't land well. Who
interviews the interviewers?

------
richmarr
This would be better implemented as a multiple choice test... at least that
way there'd likely be no quibbling over whether an inode is "metadata" or an
"identifier"

But of course they wouldn't implement it in such a way.

------
urda
I'll repost this again:
[https://news.ycombinator.com/item?id=12701858](https://news.ycombinator.com/item?id=12701858)

This is a bullshit article, why did it frontpage _again_ ?

~~~
scottydelta
it might be a bullshit article but the horrible experiences of so many people
in this thread cannot be bullshit.

------
pfarnsworth
This sounds like an old post. Google recruiting was really terrible 10 years
ago but these days it’s just bad or okay sometimes. I would be shocked if they
asked potential directors of engineering these questions today.

------
rurban
I got the same. I found it hilarious how stupid the first rounders can be. But
looking at the code this company produces and how management works confirms
the bias.

------
4684499
Silly question maybe, is there any chance they do this on purpose?

~~~
paulcole
Zappos has high-level candidates be interviewed by lower-level employees. This
is a test to see how they interact with and treat another person who's not on
their "level."

Wouldn't be surprised if this is something similar. Acting like the smartest
and most important person in the room is rarely a good look, even if you are.

------
oldgun
Seen this piece before, still funny to me.

> Thought: I guess that's what happens when AI bots discover recreational
> drugs.

That's why engineers should be interviewed by engineers.

------
icedchai
This is a basic phone screen, not a "director of engineering" specific thing.
I had a similar screen for an SRE position.

------
booleandilemma
It’s obvious from this interview that Google is looking to hire a robot.

If they were looking for a human they would have used a captcha.

------
LordHumungous
The recruiter asked me a lot of these same questions when I was applying to an
SDE position

------
s2g
I'm just wondering why this guy wanted to work for Google at all.

------
theDoug
This again?
[https://hn.algolia.com/?query=Google%27s%20%E2%80%9CDirector...](https://hn.algolia.com/?query=Google%27s%20%E2%80%9CDirector%20of%20Engineering%E2%80%9D%20Hiring%20Test&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

------
Molaxx
It seems Google is more sensitive to false positive than false negative
because of their very good compensation and the relative high demand for
Google jobs + the unbalanced high costs of a false positive. At their scale
they can afford playing the stats and not be bothered with individuals.
Further more any promising rejected engineer will be asked to try again every
six months which alleviate the false negative problem. seems reasonable from
this perspective.

------
SA500
This has been posted before. Standard questions from a recruiter. The fact he
wasn't able to work out how to play the game at this stage suggests he
probably would have been cut out for the job anyway...

