Google's "Director of Engineering" Hiring Test - <AUTHOR> http://www.gwan.com/blog/20160405.html <comment><USER4> FWIW: As a director of engineering for Google, who interviews other directors of engineering for Google, none of these are on or related to the "director of engineering" interview guidelines or sheets.

These are bog standard SWE-SRE questions (particularly, SRE) at some companies, so my guess is he was really being evaluated for a normal SWE-SRE position.

IE maybe he applied to a position labeled director of engineering, but they decided to interview him for a different level/job instead.

But it's super-strange even then (i've literally reviewed thousands of hiring packets, phone screens, etc, and this is ... out there. I'm not as familiar with SRE hiring practices, admittedly, though i've reviewed enough SRE candidates to know what kind of questions they ask).

As for the answers themselves, i always take "transcripts" of interviews (or anything else) with a grain of salt, as there are always two sides to every story.

Particularly, when one side presents something that makes the other side look like a blithering idiot, the likelihood it's 100% accurate is, historically, "not great".

<comment><USER5> So you're saying Google's recruiters don't tell what position they are interviewing for and that they found a 20+ years experienced engineering manager holding patents on computer networking _under-qualified_ for an ordinary site maintenance position. Well, that sounds like a dumb recruitment process.

<comment><USER6> > they found a 20+ years experienced engineering manager holding patents on > computer networking under-qualified for an ordinary site maintenance > position.

To be fair, I've interviewed people at previous companies that had patents and 15 years at IBM on their CV and completely failed even the most basic system / coding questions. (fizzbuzz style).

There are a lot of people that read great on the CV but then it turns out that they mostly kept a chair warm and organized meetings over the last decade without actually retaining any technical knowledge.

Not saying that was the case here, but it happens and it's probably worth checking people on their stated qualifications.

<comment><USER7> Perhaps that suggests you're giving them the wrong interview.

<comment><USER8> I agree. Why the hell would you ask someone at that level basic questions like fizz buzz? It's absurd. I also tend to shy away from asking coding questions in interviews, they don't tell me much about aptitude for critical thinking and culture fit. Skills can be taught but culture is much harder. ... But I'm not saying to throw in some questions that don't prove that they are actually competent, just be casual about it.

<comment><USER9> I think coding questions are really important. You see their logic flow. Now stupid coding questions (in a list, find all the number pairs that add up to another number in the list) are terrible. They're complex and even good programmers need time to think about them. Fibonacci is one that people expect, so they look up all the variations and you get people who are good test takers (would ace a GRE/MCAT) but not good designers.

You want a simple question that isn't common, but that shows how they break down a problem under stress. Example: you have an input with paragraphs at 80 characters. Write a function to return the same paragraphs wrapped to 40 characters. You cannot break a word and must maintain paragraphs.

Great design questions: a word problem (You have an autoshop with, staff and customers. Customers can own multiple cars. A staff member gets assigned to a car with a work order...) .. draw an ER diagram. This is actually a pretty low stress question. It should be straight forward. If someone draws a terrible ER diagram with lists in tables and no normalization, or unnecessary relationships (or you have to keep asking them to label 1-to-n/n-to-1 relationships and they struggle), you know they're not going to be good at designing database schemas.

Another great general knowledge question: "A user types in a web address into a web browser and hits enter. Describe what happens. Go into as much detail as you can." This gives people a change to elaborate as much as they can. People can talk about DNS, HTTP, load balances, HTTP request/response, cookies, load balancers, web apps vs static content...

Questions need to be geared to the job. You don't ask someone to draw an ER diagram if they're being hired to rack servers and setup VMWare. Likewise you don't ask a web developer to write a function to do matrix multiplication.

<comment><USER10> I often ask the web browser one and find it quite illuminating. Best answer so far started with something like "Well, there's a microswitch in the keyboard if it's a decent one, and a circuit that debounces the input - err, is it a USB keyboard or a PS/2 one? Hmmm... How long do I have to answer this question?" THAT is the guy you want to hire...

<comment><USER11> Last time I got that question, I started with nerve impulses.

<comment><USER12> Still not enough: If you wish to explain a web-request, you must first invent the universe.

<comment><USER11> "Describe an HTTP request? Tricky.... What's the mass of the electron in this hypothetical?"

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing.

It's a bit strange to have someone non-technical interviewing a techie. You end up with stupid discussions like the one about Quicksort. If you point out qs is one of several things with the same big-O, you'll probably also get it "wrong". But the real problem is that a guy who is just reading off a sheet can't give any form of nuanced feedback. Was the guy blagging the sort algo question? Did he know if in detail? Does he know what the current state of research on that area is? There's no way to know that if your guy is just a recruiter, but I'm sure even a relatively junior coder would be able to tell if someone was just doing technical word salad.

I wonder what would happen if ordinary people recruited for medical doctor jobs? Would you be comfortable rejecting a guy who'd been in medical school for 10 years based on his not knowing what the "funny bone" is? Wouldn't you tell your boss that you felt a bit out of that league? It's amazing you can get someone to do this without them going red in the face.

<comment><USER14> I knew all these answers too, because I was a developer in the 1990s.

There is absolutely no purpose to knowing off the top of your head how long an ethernet address is, or even what system call will retrieve an inode (his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth). The top Google search result for each of these questions has the answer. Knowing these things isn't part of being a practicing programmer; knowing how to find out is.

<comment><USER15> But what if Google is down and you are tasked with diagnosing it?

<comment><USER16> If they are trying to hire for a position that will somehow be on the line for what happens when _all of Google is down_ , I for real hope that they get some higher-power questions into that interview.

But, obvs, the answer is that you Bing it.

<comment><USER17> This is the funniest thread I've ever seen on HN

</comment></comment></comment></comment></comment><comment><USER18> Without actually hearing the transcript verbatim, it's hard to give much enlightened perspective here, but there's a lot of "hur hur, dumb recruiter" responses here. What I will say, in general, is that figuring out what the "right" answers are here for what is obviously a technical phone screen by a non-technical person with answers on a piece of paper is also part of the challenge. This is a Director of Engineering interview. Understanding context & navigating "real people", having soft skills etc. is meant to be part of the job description. Feels like this gentlemen couldn't turn the hardcore engineer off who's technically right about everything but yet never seems to get anyone to listen to him.

Giving the hexadecimal representations of the 3-way handshake... really? You may have gotten a dumb recruiter and you may think you're smart, but from my perspective, you answered the questions in a pretty dumb way given the context of non-technical recruiter, very obviously reading answers from a sheet of paper.

I've done two of these before and I've often said "Oh well, it might be down on your sheet at this thing" and the recruiter goes "Ah, yeh, that's it. Tick" and moved through 3-4 questions that in theory I might have gotten wrong. If you take the "be a dick" routine... Congrats. You won the moral war. Best of luck with your next job.

<comment><USER19> "Dumb recruiter"? What?

Nobody's calling the recruiter dumb. Everybody is calling the _process_ dumb. A process that puts somebody that cannot answer these questions, in charge of asking them and evaluating the answers.

Having the candidate evaluate the competence of their recruiter is not part of the interview process. What the hell.

<comment><USER20> I believe in the phone screen Google uses non-technical people to ask technical questions (as engineers are a scarce resource) so they're only able to handle "right or wrong" but you can probably work your way around that by being nice - this guy seemed to be being an ass...

<comment><USER21> I've had two phone screens with them and both times they were very technical people. Then again it was some time ago and with the bigger scale they may have changed it up.

It is unfortunate, but as mentioned above, you need to just play the game until you get to the real part. It's like when I call customer support, I gotta play along with the non-technical people and get them to bump me up the chain to someone technical when I need advanced help.

The unfortunate truth is that it's unreasonable to dedicate precious engineer time to screen millions and millions of people, they'd get no actual work done. So the first layers has to be like this. You just play along for the first step, and after that it'll get much much more interesting, trust me.

This guy seemed like the kind of person who loves showing off his knowledge and having the last word on everything. Honestly this kind of people, as knowledgeable as they are, usually do poorly in a work environment.

<comment><USER22> >I've had two phone screens with them and both times they were very technical people. Then again it was some time ago and with the bigger scale they may have changed it up.

Just to clarify, at least for the SRE hiring process, you first have a single technical phone screening with a technical recruiter (not an engineer) which is literally on the phone. At least it was for me, no webcam or anything. It's a pretty short and back-to-back question/answer type of conversation similar to what is told by the article (although the article strikes me as odd and does not match my experience). After that you have a couple (or more if need) of "phone" (read: hangouts with webcam and shared doc) interviews with actual engineers and those are more technical and require you to write code as well. Then you'll be moved to on-site interviews.

(This is for Europe at least, I imagine it'd be similar in other areas but can't know 100%).

<comment><USER23> You're exactly right. I was asked some of these exact questions yesterday. The guy should have realised what he was dealing with, the recruiters don't claim to be technical, and the questions are flagged as being straight forward pre screen questions.

</comment></comment></comment></comment></comment></comment><comment><USER24> I've been at Google for five years as a SWE and I've been interviewing for 3 of those. I'd fail this pop quiz.

This strikes me as bizarre and inconsistent with all the practices I'm aware of. The idea that we'd ask anyone this stuff, let alone director candidates, strains belief.

<comment><USER25> The only way this makes "sense" is if you already have the candidate (or pool of H1-B candidates) you want in mind, but have to prove you opened up the position to the general public first.

<comment><USER26> I know some companies do this, but this is Google. There's no incentive for them to hire H1-B's if a equally qualified American citizen is available, since they are going to pay equal salary.

<comment><USER27> They don't have to offer the same salary, just salary in the same range. That range can be pretty wide ($20k+)

Employees on an H1-B visa have drastically less job mobility than US Citizens. This creates a power advantage for the employer.

>but this is Google

Google has, in the past, illegally conspired to prevent other companies from recruiting their employees. This lowers wages and reduces employee mobility. Clearly there's incentive because they have literally broken the law in the past to achieve these results.

<comment><USER28> > Employees on an H1-B visa have drastically less job mobility than US > Citizens. This creates a power advantage for the employer.

Yet Google pays the lawyers needed to get you a Green Card as fast as possible.

<comment><USER27> Yet a Green Card does not give an employee anywhere near the same level of job mobility as a US Citizen.

<comment><USER29> A green card allows you to live and work in the US without employer sponsorship. There is complete mobility, on par with a US citizen.

<comment><USER30> It's not as bad as previous poster states, but it's not quite as simple as you make it seem either. A green card holder forfeits their residency if they leave the US for "more than 6 months", or if border patrol people feel like they've abandoned their residency for any reason. This doesn't affect most employees, but if you're a consultant working on-site in another country for extended periods, or simply travel often, you have to do way more work to get everything cleared. And even then, there's no guarantee you won't run into problems.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> Wow, I had almost the very same set of questions for a junior SRE role! The difference is: I graduated ~1 year ago and therefore have a lot less experience than this guy.

It was kinda funny, the recruiter called me to "go through some of the questions to see what I will encounter in the actual interview". I remember, when asked about what Unix function accepts connections on a socket I could just answer "dunno", because I never used or did that. Even more funny if you consider that they actually came across my profile and called me initially and there is just no place in my CV where I claim such "low-level" knowledge. I also remember that Inode question, "What is stored in an Inode?" \- Again "idk" and the answer the recruiter gave was "metadata". Yes of course metadata, goddammit, what else? (Can an answer really be that simple???)

After the interview I felt quite devastated because I did not expect that I had to come up with a solution to process an array with the size of 10,000 in a call with the recruiter. I wasn't (and I'm still not) sure if this was only preparation or an actual interview. In the latter case, I was sure that I failed. Surprisingly however, I was invited to an actual engineering interview some time later.

<comment><USER32> Maybe they wanted to test your personality and if you generally have a clue. Admitting to not know something is usually no deal breaker as long as you get the important ones right and show the right attitude.

</comment></comment><comment><USER33> The meta-question is, "Do you have the social savvy to give the conventional answers when being judged by someone who doesn't know what he is taking about?"

<comment><USER34> Yah I get the feeling you're supposed to "act stupid" so you can get to the next interview.

Definitely not an idea way of getting candidates - you are selecting for people who know how to manipulate screens (and thus increasing the risk of getting a bad candidate), or rejecting otherwise knowledgeable people who just don't have the time/inclination/"social savvy" to pretend to be stupid.

<comment><USER35> Why not? Especially in a managerial position, you will occasionally need to build a rapport with people who are convinced they have good technical knowledge, but don't. Being able to talk to them productively instead of picking fights _is a skill worth selecting for_.

If you can't figure out that the first person who's interviewing you has answers on a sheet of paper and you're supposed to parrot them until you get to the second person, how are you ever going to figure out that the first person you're selling to has some business requirements on a sheet of paper and you'll never get to the second person until you parrot those?

"Oh, we're not actually using Docker, we're using rkt, which is a compatible reimplementation of --" "I'm sorry, I've been told Docker is a requirement. We can't use your Cuber Netty thing until you support it. Bye!"

<comment><USER36> Have an up-vote. This is the most plausible explanation. They're testing his social skills and how he deals with people who are less technical than he--not testing his technical knowledge.

EDIT: To add to this, I've seen this tactic before on an interview. Interviewer asked me a pretty softball technical question, I nailed it, and then he said, "No, you're wrong, it's [OBVIOUSLY INCORRECT ANSWER]." He was clearly trying to gauge how well I handle someone who thinks they know what they are talking about, but actually do not--which can a surprisingly large number of people in the office.

<comment><USER37> The most plausible explanation is the guy failed the interview, felt bad about it, then wrote a version of it to make him look good and Google bad to punish them.

<comment><USER38> I find the thought more plausible that Google had 100s or 1000s of candidates and they weren't willing to interview all of them directly because most are usually crap, so they let some incompetent contractor do a pre-screening.

<comment><USER33> I really wish our industry could create some generally trusted benchmarks of skill that we could take once and then be done with. As things are, we have to prove basic programming skill with every employer. You'd think this wouldn't be necessary with more than a decade of experience and several degrees in computer science from eminent institutions, but apparently it is. I'm fine with employers asking very particular questions about the domain of work, but we shouldn't have to prove sanity all over again every time.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> Hahaha, that is funny/tragic. Outsourcing hiring a director of engineering to a moron with a cheat sheet! Your answers were great, though, and indeed on the systems I have tried the popcount() computation with the bit shifts you suggested is faster than using an 8 bit lookup table. (however the SSE4 popcnt ([https://en.wikipedia.org/wiki/SSE4#POPCNT_and_LZCNT](https://en.wikipedia.org/wiki/SSE4#POPCNT_and_LZCNT)) is faster still).

<comment><USER40> While I think these things are super interesting trivia, I really want to ask the question: "Why does a Director of Engineering for Google need to know this?" That is not only a rather unusual question (within the scope of daily tasks for a programmer, these tend to be an important minority for a project), but it's one that's best settled empirically and within the context of your execution environment.

There are a lot of different answers to the question depending on where you're doing it and how you want to impact the machine.

It's a bizarre question to pose to Director level, because the proper response even for a technical director should be, "The answer to that changes quickly, we should measure and check what our environment's latest capabilities are and if they are reliable."

I mean I'm all gung ho to program stuff, but I think that'd be a massive misapplication of my time with that title in my current job, and given my other responsibilities I'd only do it more slowly than someone with dedicated focus.

</comment></comment><comment><USER41> I had almost exactly this same engineering test when google interviewed me in 2006. It was terrible, and left a bad taste in my mouth. Given the complexity of the work I was doing at the time, the entire thing seemed ridiculous.

<comment><USER42> The inode question gave me flashbacks to my interview with Amazon. They wanted me to explain what a hash function is. I kept giving answers for about 3 minutes explaining hashing, common algorithms, reasons to use it and places it applies.

Recruiter: "I was looking for you to say it's a _fingerprint_ "

So I guess I was wrong, because despite explaining them in decent detail, I didn't use the one keyword.

<comment><USER43> On my phone screen a Google recruiter asked me "how much is 2^24", and I knew the answer by heart and answered immediately.

So he asked "how did you figure this out so fast?". I told him I didn't, I just remember all the "important" powers of 2. He said "well... that's not what I was looking for, I wanted you to calculate it, but... I guess a candidate who memorizes powers of 2 is a positive sign?". I passed.

<comment><USER44> haha, I got that question too, in stead I worked in MPLS for over 5 years, I know by heart that MPLS label has 20bits which translates to 1 million labels, times 2^4 that is 16 million. The recruiter asked me how I figured it out so fast, I explained to him, that recruiter had no idea of what I was talking about. I did not pass.

<comment><USER43> Well, I answered the rest of the questions perfectly and exactly like he expected, so it might have helped.

</comment></comment></comment></comment></comment><comment><USER45> They asked me the same questions back in 2012. I was applying for a Java developer position.

The person asking the questions said right from the start that he is not technical (he was a psychologist) and that he had a cheatsheet in front of him.

I passed that telephone call and failed the process later on another call (on the lightbulbs and the 100 floor building)

Really surprised to see that 4 years later they still do this.

<comment><USER46> This is really weird and should not be happening. I am a software developer and do a lot of interviews including phone interviews.

These kind of questions are not expected, but I would say the lightbulb one is not super horrible as long as it is the discussion that was valued and not the answer. I have gotten weirder questions for sure when interviewing.

<comment><USER47> I didn't hear about the light bulb drop question until this thread, and was surprised how in-depth it can go.

Can you really "fail" an interview on a question like that? I assume the person conducting the interview is reviewing your process of coming to an answer rather than getting the most correct answer - right?

By most correct I found this article that broke down the question/answer: [https://pointlessprogramming.wordpress.com/2011/03/11/2-ligh...](https://pointlessprogramming.wordpress.com/2011/03/11/2-light- bulbs-and-a-100-story-building-solution/)

<comment><USER21> In theory, that's basically the idea of most questions asked during interviews (except maybe very basic CS ones). The idea is that they will look at how you approach the problems. If you already know it and spew out a memorized answer, it's much less interesting to them than if you've never heard it before and you approach it with a clever way (even if you don't get the answer).

But yes, in practice, YMMV.

</comment></comment></comment></comment><comment><USER48> I can see both sides here. Google does want to make sure even higher up technical hires have good technical skills, which I think most developers would agree is a good idea.

But their way of measuring this (the standard way) is bad, because it ignores the nuance a more experienced person has (seen so clearly here).

On the gripping hand, I can't help but feel the candidate did demonstrate a big failure to communicate, which is an important skill in itself.

For example, listing SYN, SYN-ACK, ACK in hexadecimal is great for showing off, but is legitimately a bad answer to the question – as evidenced by the lack of understanding in the questioner. I also think some social graces might have got them further (e.g. "Oh yeah, sure. Quicksort is O(N log N on average, and is generally a reasonable sort to chose, but I wanted to mention some other factors that are worth considering").

At the end of the day:

\- it's a hoop. Jump through it and get a fish, or don't.

\- calibrate for your audience! This is a very important technical skill (and this test was unintentionally correct in its result IMHO).

<comment><USER49> Completely agree with you. Seems more like a personality mismatch, than a lack of technical skills.

Seems like both parties were at fault here:

\- The interviewee for being a little brusque about his answers, and despite understanding the _intention_ of the question, giving potentially off-putting, difficult answers to check over a quick phone call.

\- Google recruiter for seeming to ask questions she/he was a little out of her/his league to ask. If you don't understand the nuances in and around the questions you're asking, you are not qualified to evaluate someone's responses.

Wouldn't worry about any one particular interview, there are too many great opportunities in tech right now to let any one bad interview let you down!

</comment></comment><comment><USER50> It is scary if this is how Google hires engineering directors. Passing this test would select all the bad candidates! Answers to many technical solutions are "it depends". If you have a director that "knows" the right answer, they won't be very likely to encourage their engineers to experiment and find the best solution to the specific problem at hand.

<comment><USER51> A brilliant professor of mine liked to say "The Answer of the Engineer: it depends".

<comment><USER52> That is nearly the answer i give to every questions. But when i asked for more detail no one likes it. They all simply want "answers".

Well much like most things in life, there is no such thing as concrete answer.

<comment><USER53> I keep pushing the message that getting a "correct[tm]" answer to a technical question is probably not the answer you should be looking for. Problem solving skill trumps rote knowledge every time.

I recently wrote a somewhat lengthy post on the subject, after realising how bad some companies are at this: [https://smarketshq.com/notes-on-interviewing- engineers-a4fa4...](https://smarketshq.com/notes-on-interviewing- engineers-a4fa4383968a)

</comment></comment></comment></comment><comment><USER54> Is this for real? Does Google really hire interviewers that stupid? The list of questions is really dated. They're all pre-1990. The answers are dated, too.

A Linux inode is the file system's representation of the base info of a file, from which the file's data blocks can be found. It also carries file metadata, but its real function is as the root of the file's block index tree. The format depends on the file system. The internal identity of a file is an _inode number_ , not an inode. What you get from 'stat' is the file's metadata, which mostly comes from the inode data structure on disk, but isn't necessarily in the same format. The formats were the same back around UNIX V7, but there have been some changes in the last few decades as file systems improved.

If you need to count bits in a word, the first question is whether your CPU has hardware to do that. NSA always liked population count instructions, which are useful in cryptanalysis, and that's why most supercomputers had them since the 1960s. Now they're finally in Intel x86 CPUs with SSE4.2 (added around 2006), which has a "popcount" instruction.[1]

A MAC address _for Ethernet_ is six bytes. There are other hardware layer systems, and Google probably uses some of them. Fiber Channel fabric uses only a 3-byte address, for example.

Hash tables are not O(1) lookup. It's an exponential as the table fills up. It's near O(1) only with a near-empty table. There's a space/time tradeoff on how full you let the table get before you expand it.

Quicksort is average O(N log N), but the worst case is much worse, which is why nobody uses pure Quicksort any more. You can beat O(N log N) with a distribution sort. The first sort to do that was SyncSort, the first patented algorithm. It's a distribution sort with self-adjusting buckets.

Who wrote this interviewer's answer sheet?

[1] [http://wm.ite.pl/articles/sse- popcount.html](http://wm.ite.pl/articles/sse-popcount.html)

<comment><USER55> > Hash tables are not O(1) lookup

In terms of algorithmic time complexity, it is O(1)

<comment><USER54> No, as the table fills up, you start to get clashes, where two keys hash to the same value. There are various ways to handle that - rehashing and trying again, linked lists - all of which take you below O(1). See [1].

[1] [https://en.wikipedia.org/wiki/Hash_table#Collision_resolutio...](https://en.wikipedia.org/wiki/Hash_table#Collision_resolution)

</comment></comment></comment><comment><USER56> Site is down. Does anyone have a mirror?

Edit: [http://webcache.googleusercontent.com/search?q=cache:rPrtrh1...](http://webcache.googleusercontent.com/search?q=cache:rPrtrh15wsMJ:www.gwan.com/blog/20160405.html+&cd=1&hl=en&ct=clnk&gl=us)

<comment><USER57> Those hex codes should come in handy XD

</comment></comment><comment><USER35> _7\. what is the name of the KILL signal?_

 _Me: SIGKILL which #define is set to 9._

 _Recruiter: no, it 's "TERMINATE"._

 _Me: SIGTERM (15) is different from the KILL signal (9)._

 _Recruiter: that 's not the answer I have on my sheet of paper._

You know, I think I've been asked this question on a Google phone screen - <USER2> I think the question is specifically "What is the signal that the `kill` command sends?". The answer is in fact SIGTERM, not SIGKILL; if you want SIGKILL you need to specifically say `kill -KILL` or `kill -9`. If you insist that it's SIGKILL, you're just technically wrong. And if you can't understand the question, you're missing very important skills; this sort of confusion will cause actual production problems.

<comment><USER58> Good catch, and a good indication that the author is paraphrasing and not exactly getting all the details right.

(I don't doubt this happened, but we're only hearing one side of the story)

</comment></comment><comment><USER59> Frankly, this reads like a post from /r/ThatHappened. For those unfamiliar, it's a subreddit to share social media posts from people telling obviously made up stories with the purpose of making themselves look good (e.g., brave student stands up to intolerant teacher, receives standing ovation from peers).

The interview may have happened and the questions may be accurate but the story is very exaggerated to make the person look good (and the interviewer look bad).

<comment><USER60> This definitely fails a basic "smell test", I don't think the author has the most honest intentions at all.

</comment></comment><comment><USER61> I'm not going to go into specifics (I like my job and want to keep it), but the versions of these questions quoted in the blog, especially where the questions seem stupid and wrong, are not on accurate representation of actual SRE prescreen questions. It's possible that the recruiter somehow garbled them, or perhaps the blog's author is misremembering them after a stressful and frustrating conversation. But if you read this and think Google asks really dumb questions, I think if you saw the "real" questions, you might come away with a different opinion (especially if you understand the nature of prescreening vs. an actual interview). A hypothetical example, let's say the complaint is about the following exchange:

R: What's a potato? A: It's a vegetable that grows in the ground. R: Wrong. It's brown. A: Potatoes come in different colors, and they are vegetables that grow in the ground. R: Wrong. It says on my sheet that the correct answer is brown.

when in reality the question was "What color are Russet potatoes?" I don't know what happened here. Something, unfortunately, went off the rails.

<comment><USER62> Well I had the first call with a recruiter this Monday about a Google SRE-TPM role, and I got the exact same questions – granted, presented as a warm up.

<comment><USER61> If you had literally the same questions, worded the same, there's something horribly broken (or you got the same broken recruiter). I think you're remembering similar questions (e.g. they asked the one about the potato) but the details make a huge difference.

<comment><USER45> Scan the whole comments section now and you will find multiple people saying they got the exact same questions (I am one of them)

<comment><USER63> You mean, when they asked about quicksort, they used the precise wording in the blog post? Or was it worded in a different way, say, closer to the versions posted elsewhere on the internet? The difference is important. I do not believe the recruiter asked "Why is quicksort the best?", I think they asked a different question.

</comment></comment></comment></comment></comment><comment><USER64> Hmmm...

* A link to his LinkedIn profile

* A direct downlink to his resume (well, an HTML file for his LinkedIn page; same purpose)

* Talking about how his skillsets are a "rare mix".

* A "transcript" showing how he's smarter than the recruiter for a Google DoE position

* Taking on a big company in a post bound to go Viral

Yeah, this feels less like a blog post, and more like an attempt at a viral cover letter.

<comment><USER65> This guy has been at it for years. He isn't dumb but he doesn't seem to adapt to the world well.

</comment></comment><comment><USER66> That's not so surprising with Google, I'm afraid.

I had the exact same questions (apparently for SRE-SWE prescreen), but a slightly more intelligent recruiter (who had actually chased me for 2 years before I agreed to interview, so they were a bit more invested than the OP's guy). I went on to a phone screen and then on-site interviews, and then the hiring committee. The HC decided that coding/algo was strong, but that they needed a stronger "signal" re system design, and to my surprise, scheduled me two more sys design interviews (I did a total of 7 on-sites). I prepared by reading all the Google, Facebook, and Amazon systems papers and did 6 mock interviews with Gainlo, where interviewers all gave pretty good feedback (which led me to believe I wasn't a total idiot). When I went to my final Google interviews, I thought I did pretty well except for a couple of TCP/IP questions related to checksums and congestion control. I found those odd because all the prep materials that recruiters sent me listed knowledge of TCP specifics as optional, and this isn't my area of expertise anyway.

Oddly, one of the interviewers also seemed surprised that I wasn't a TCP/IP guru (--I bet that now he's telling his buddies stories about a candidate who couldn't do the SRE equivalent of Fizzbuzz or something similar.)

A week later I get the rejection and a long survey containing a link to the job for which they applied on my behalf. It was an SRE position that required deep knowledge of TCP/IP and various other network protocols.

My actual areas of expertise (for the last 10 years) are 3D graphics and computational geometry.

Lesson learned: always check the description of the job that overly eager recruiters apply for on your behalf. Had I known, I would've studied all about TCP/IP and prepared for that level of detail. All that time I thought that I was applying for a general SWE track, and I simply expressed interest to be matched to teams specializing in infrastructure and distributed systems later.

<comment><USER67> > My actual areas of expertise (for the last 10 years) are 3D graphics and > computational geometry.

If I may ask, what put you off your former field so that you decided to move to the server-side world?

<comment><USER66> Nothing in particular. I was just looking for a bit of a change and to gain more rounded experience. Being pigeonholed into one specific area (3D/CAD/CAM C++ development) for many years isn't that great for future career prospects, especially in a market where most mainstream job titles seem to be split into a front-end or a back-end development category, and my experience doesn't seem to put me in either...

</comment></comment></comment><comment><USER68> I had a very similar experience with them (around Java and Python dev questions) a few years back. Completely turned me off applying to Google, or replying to the numerous pings I get whenever they want to expand headcount in Europe.

(I'm not going to mention other companies here, but I also had enough "technical" interviews of this kind to make me wonder if people actually know how to recruit outside their - often quite narrow - perception of what their area of expertise actually is.)

Makes me quite sad, really, because there is zero assessment of experience, talent and know-how in this kind of interview (and whiteboard interviews can be ridiculous in their own right, too, but that's not the point here - it's just that they appear to be the next step in this broken appraisal).

</comment><comment><USER69> if this is Pierre, I remember some controversial discussions years back. Some links:

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

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

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

<comment><AUTHOR> I am not him, if you ask this.

<comment><USER69> I was referring to the author of the blog post. As far as I know there is just one person authoring GWAN web server.

(funny thing the site is down, maybe given the traffic brought by HN, and I assume the web server hosting the blog is GWAN :-) )

<comment><AUTHOR> yes, it is gwan :)

</comment></comment></comment></comment><comment><USER70> Ha ha re:

> 10\. what is the type of the packets exchanged to establish a TCP > connection?

> Me: in hexadecimal: 0x02, 0x12, 0x10 – literally "synchronize" and > "acknowledge".

> Recruiter: wrong, it's SYN, SYN-ACK and ACK; if Google is down you will need > to know this to diagnose what the problem is. We will stop here because it's > obvious that you don't have the necessary skills to write or review network > applications. You should learn the Linux function calls, how the TCP/IP > stack works, and what big-O means to eventually qualify if you are > interviewed at a later time. Good luck, bye.

That's embarrassing.

<comment><USER71> Surprising they wouldn't have given the recruiter a list of alternate acceptable answers.

Almost feels like the recruiter was conspiring against you, but why?

<comment><USER72> I feel like someone that's not unusually unintelligent should have been able to make the connections between SYN and synchronize or ACK and acknowledge. I don't know why people are defending the recruiter. The process is dumb, but so is an interviewer that asserts himself as an authority when he has to read from a sheet of paper. I don't expect him to be a technical expert, but I do expect him to know when he needs to consult a technical expert about a particular candidate's answers. If this is an accurate representation of his interviewing skills, he needs a new job.

</comment></comment></comment><comment><USER73> "There's an array of 10,000 16-bit values, how do you count the bits most efficiently?"

multiply 10,000 by 16. There are 160,000 bits

<comment><USER74> My sarcastic reply is to your very reasonable answer is:

On the x86 architecture, integer multiplies take more cycles than a comparable solution that uses bit twiddling so you're just WRONG!

You are the weakest link, GOODBYE!

<comment><USER73> I get that but I am proposing to hard code the answer since I already know it

</comment></comment></comment><comment><USER75> Most people, at every level, are _terrible_ at interviewing and hiring, and in fact a surprising number are conscious of that fact. As a candidate, you just have to know this going in, and expect to be made to jump through a lot of irrelevant/stupid hoops. Eventually you find someone who is adequately amused by your performance to give you a chance and hire you.

I don't think the recruitment industry is going anywhere anytime soon. I just wish there were some worthwhile recruiters in it (out of the dozens and dozens of recruiters I've dealt with, I've met one who is semi-competent (which is to say, not fully competent)). This is an area I'd love to try to startup in, I don't think any of the startups I know about are doing it right.

</comment><comment><USER76> Is this for real? Wow. Reads like someone spoofing the real Google interview.

For "Director of Engineering" they have a technical illiterate (nothing wrong with that, in other contexts) check for literal matches of answers? the mind boggles.

(I'm really having a hard time believing this is for real)

<comment><USER75> Believe it. The depths of corporate absurdity know few bounds.

<comment><USER4> On what data are you basing this?

<comment><USER77> There's no reason to sealion this, but here's a recent article that talks about exactly this topic: [https://aeon.co/essays/you-don-t-have-to-be-stupid- to-work-h...](https://aeon.co/essays/you-don-t-have-to-be-stupid-to-work-here- but-it-helps)

</comment></comment></comment></comment><comment><USER78> This reads as an indictment of the entire hiring culture of the tech industry, which it is. Hiring is one of the most important things any company ever does. It's also one of the biggest opportunities to attain a competitive advantage. And it's one of the most difficult tasks that any developer will ever participate in. And yet, consistently there is a lack of seriousness when it comes to hiring, and a reliance on bad, counterproductive cargo cult practices. It's not just embarrassing for this industry it has a big impact on the quality of life of developers and the quality of developer talent at companies. If you want to hire good people you need to put a lot of resources into it. And that means you can't just hand off these sorts of important tasks to interns who don't know what they're talking about. Hiring, even at the phone screen level, is not like comcast customer service, and any company that treats it that way is setting themselves up for failure.

</comment><comment><USER14> These would be stupid questions even if they weren't being administered by a non-programming recruiter.

</comment><comment><USER79> FWIW: I have interviewed twice at Google for Dir. Eng. jobs, both times going the distance. (Once rejected after a few weeks, once received an offer two months later, too late to accept.) In those interviews, I was never asked a seriously hard technical question, let alone an annoyingly academic and trivial one such as those in this post. Rather, I felt like they did a pretty solid job of understanding how I would engage with the organization and perform in the role.

Though the lack of technical rigor was not surprising in evaluating me for a administrative & support position, the lack thereof in the onsite portion was something I sent explicit feedback about afterwards.

</comment><comment><USER80> The Google interview process is a disaster.

Incompetent HR is apparently the norm. When I finally got to my ( 8th? ) interview there, I was asked by a very senior manager whether or not I had ever used Github before.

Considering Google cold contacted me based on the specific email address and projects I make available on my Github profile, it was kinda was confusing. Ohh yeah, he also asked me what CSS stood for.

I ended up stopping the interview early myself.

</comment><comment><USER81> As a person who's taken this exact same test: 1) it's a pre-screen from an in- house recruiter. If you have 37 years of experience with computers and 24 years professional experience and any references/reputation, they should have skipped you straight to an phone interview with an engineer. 2) Were you recording the interview? Because if it's an accurate transcript the recruiter should be fired.

I assume question 7 was actually "give the Big-O of Quicksort", if you refused the recruiter might have assumed you didn't know it and were trying to BS through the interview. If the recruiter was too stupid to ask, once that person is fired you'll get a new recruiter. Google is (was?) notorious for contacting the same candidates every six months regardless of previous interviews.

<comment><USER82> > they should have skipped you straight to an phone interview with an > engineer.

When a family member of mine used to be an admissions officer at a small tech school, "unsuitable" (mentally ill, ppl who seemed like they would never get in, be able to pay or complain and tarnish the reputation of the school) used to come in often. They were given a screening test which was waived for all "normies."

This is how _power_ works. It is not _fair_. With communication media like the internet, we're starting to perceive it. The real challenge will be re- architecting our society to be more fair and clean up from the aftermath of our unfairness.

</comment></comment><comment><USER83> A friend of mine was offered a similar position and had a similar interview. Annoyed by the questions and the "my solution is the only right one because I have to stick to this script"-attitude he asked: "So what do you want me to do at Google, how can I help you" the recruiter could not really answer and ended the call shortly after.

<comment><USER84> It's a freaking psychological profile test dressed up as "tech screen". Your friend's personality was effectively filtered.

IMO, the very first step in entering googleplex/facebook is accepting that it is OK to lend your talents to build a global _surveillance & propaganda platform_. These tests seem to be probing for other desired characteristics as the next step.

</comment></comment><comment><USER85> Having been through several goog interviews I find it hard to believe that the interviewer would dismiss his highly technical explanations/rebuttals in that way. Seems more likely this is his interpretation of the tone of the interview, rather than a transcript.

</comment><comment><USER86> I think the candidate made a simple mistake: the interviewer is always right. Your job in an interview isn't to be right or to teach the interviewer. Your job is to make the interviewer like you foremost, and second make the interview think that you're qualified. And of course no one likes being corrected or told they are wrong. In my opinion, it is better to do well on an interview and decide after the fact that you're not interested, than to do a poor job on the interview because you couldn't help yourself correcting the other person.

For instance during one interview I was being asked questions about a particular topic, and I started to guess that the interviewer didn't understand 100% the topic he was asking about. Rather than correcting him, I simply tailored my answers to what I thought he was looking for, not what was right. I passed the interview and got a job offer, whereas if I had corrected the interviewer the results may have differed.

<comment><USER53> > _the interviewer is always right_

That is an awful sentiment, and I find myself in violent disagreement with you.

A good number of my enjoyable interviews have been with candidates who clearly knew more than I did, and could expand from an interesting detail to a short ex-tempore lecture on the topic. I cherish each of those.

An interview where I, as an interviewer, learn something is a fine thing indeed.

<comment><USER87> > That is an awful sentiment, and I find myself in violent disagreement with > you.

You find yourself in violent insistence that the world is the way you wish it was, rather than the way it actually is.

<comment><USER53> In that case I am shaping the world around me.

Any company who maintains that their interviewers are always right is telegraphing that they treat their workforce as mindless cogs in a machine.

Every time I encounter a candidate who thinks differently than I do, I treat him or her as a potential source of inspiration. Occasionally I learn something, and occasionally they do.

</comment></comment></comment></comment><comment><USER88> Is this common for higher level positions at Google? I've gotten a similar kind of phone screen, but for an entry level software engineer position, and getting a few "wrong" was not a big deal. It's just so they can avoid setting up a real interview with someone who doesn't know the basics.

If the call actually went like this, it seems like you just hit a new/not very good recruiter.

<comment><USER4> "Is this common for higher level positions at Google?"

No, and in fact, it's so far outside the norm i'm not even sure what to make of it. Like I said elsewhere, my best guess is that he was really being evaluated for a much lower level TL/M position in SRE or somewhere.

(The detailed linux questions are usually a giveaway that SRE is involved)

</comment></comment><comment><USER89> This reminds me of the infamous Nigerian emails. They are so obvious for a reason - avoiding false positives - [1]. Cannot fit this same scheme in a Senior position recruitment at Google though.

[1] [http://uk.businessinsider.com/why-nigerian-scam-emails- are-o...](http://uk.businessinsider.com/why-nigerian-scam-emails-are- obvious-2014-5?r=US&IR=T)

<comment><USER90> > This reminds me of the infamous Nigerian emails. They are so obvious for a > reason - avoiding false positives

Unrelated to the main topic but I wonder if email providers could effectively fight those scammers by having chatbots automatically reply to their emails. That would make a bunch of false positive to sort through and possibly make the whole thing uneconomical for the scammers.

</comment></comment><comment><USER91> You would think that someone posting prescreen questions in anger would at least bother to edit the transcript so that they gave the right answers.

An inode is not an identifier. This super-awesome-knowitall has not bothered googling "define inode" before posting this.

If this really is the transcript then not only did you answer questions wrong, you also argued with the recruiter.

I have worked with people who used to be the best where they came from, who are not used to being wrong. This guy did not handle it well.

If this really is a true transcript, with internal monologue, then Google has avoided accidentally hiring someone arrogant who can't accept being wrong, or is at least not open to being wrong.

The reaction -- posting prescreen questions in anger in retaliation -- only reaffirms that Google did the right thing.

</comment><comment><USER92> This right here is why Google hit the wall and stopped innovating. Which is sad because they seem to be trying _really_ hard.

<comment><USER93> So much this. They would have missed Einstein & co.

</comment></comment><comment><USER94> I've been hit up by Google recruiters many times. I'll never interview there. The last time one of their recruiters hit me up he pretended it was for a Google X company, and then pulled a bait and switch on me, sending me a bunch of form e-mails on "interview prep" and how to expect their process would take 6 weeks minimum.

No thanks. I'm not about to put myself through a 6 week interview process at 32 years old to go work for an ad company. I'm passed the point in my life where I care and need to justify myself by trying to get a big tech company job. Already done the big tech thing.

It's not all its cracked up to be.

</comment><comment><USER95> Isn't a Director of Engineering meant to be an interface between engineers and the rest of the organization? Perhaps this was more like a smoke test for the political insight such a role calls for, not the ostensible test of technical skill it was presented as. After the first couple of wrong answers, people with the right social skills to manage others and represent their interests to the broader organization would stop striving to prove their technical chops, clarify what kinds of answers the test is looking for, and adjust their subsequent answers accordingly.

<comment><USER96> I have been in similar roles (Software Architect , CTO) where I had to explain to non-technical, but impatient (or pissed off) people (CEO, VCs) technical concepts and judgement calls.

But I _knew in advance_ they were not technical.

Also, a CEO would not challenge my explanation of what algorithm to use for sorting, be real :-)

<comment><USER95> You can know the technical level of your audience and adjust your explanations accordingly, yet still completely fail to achieve your intended result because your focus on what you want has blinded you to your misunderstanding of what they want.

</comment></comment></comment><comment><USER97> This hiring test makes me cringe. How is this any better than taking a multiple choice test in college? These questions asked should invite back-and- forth conversation like the author is providing, especially when the company is seeking out highly qualified candidates.

</comment><comment><USER98> Early in my career I got asked a question about database reporting on sales items and totaling the number by a given date. This was one of the hardest questions I was ever given because I had to "write" the sql out over the phone and was not given a schema so I had to make one up as I went. I was then asked how I would go about writing one that included $0 sales days. At the time I didn't know the answer to this -- just that querying for something that doesn't exist is not straight forward in sql. I explained that I didn't work much with reporting so I had not encountered this solution before and gave a list of possible answers:

* Generate a complete list of dates in memory and see which do not exist. * Create a temporary table to match it up that way. * Do post-processing on the report. * Research prior art.

I was not offered the job.

Years later I was given the task of creating a "data warehouse" to enable easy reporting by business analysts so they could stop bothering the engineering team. So, it being the first time I had done this, I read up on different techniques. I solved the problem the previous interviewer proposed by have a table of dates with attributes on them (is weekend, is national holiday, day of week, etc) and all dates foreign key to this table.

However, because I couldn't think of this solution within a few minutes -- despite it not being in my background -- I did not get the original job from years before.

In many ways, I'm thankful the original interviewer passed upon me. I was able to get a different job that valued being able to think of creative solutions AND being able to research prior art so we don't invent a badly designed wheel over and over again.

I suspect the author of this article will experience the same feeling with time and it is a real shame companies are valuing root memorization and keyword matching over real problem solving skills.

</comment><comment><USER99> To be charitable here: is it possible that this person did not work for Google? Historically, I've known third-party recruiters play fast and loose with their affiliation with the company they're recruiting for. This literally could have been any recruiter in the Valley trying to feed candidates to Google.

<comment><USER45> No, I have been asked the same questions by a person with @google.com email address that clearly said he was a psychologist and not a technical guy. His Linked in info at the time was Google Recruiter.

</comment></comment><comment><USER100> What the heck is a "Quicksort big-O score"? I've never heard anyone use the noun score when talking about complexity analysis.

<comment><USER101> I assume they want the average O(n log n), but who the heck knows given the script from above.

I get the feeling this: [http://bigocheatsheet.com](http://bigocheatsheet.com) would come in handy

<comment><USER102> Big-O technically means "worst case", which for Quicksort is O(n^2), although usually (in normal cases) it runs better than that. Other sort algorithms can guarantee not worse than O(n log n).

<comment><USER103> Depending on how the pivot is picked, Quicksort can actually be implemented in O(n lg n) worst-case time.

EDIT: I was going to link a proof for this but it's surprisingly hard to find. IIRC, the idea is to use the median of medians algorithm ([1]) to pick the median for the pivot, and deal with values equal to the pivot by alternatingly placing them in the left and right partition, or alternatively just keep them in a third partition in the middle.

[1] [https://en.wikipedia.org/wiki/Median_of_medians](https://en.wikipedia.org/wiki/Median_of_medians)

</comment></comment></comment></comment><comment><USER104> _> Recruiter: that's not the answer I have on my sheet of paper._

That's not an interview. That's a waste of your time and an insult to your intelligence.

This reminds me of the time Google rejected the creator of Homebrew because he couldn't invert a binary tree: [https://twitter.com/mxcl/status/608682016205344768](https://twitter.com/mxcl/status/608682016205344768)

</comment><comment><USER105> Mediocre people can't evaluate exceptional people. What mediocre people think is knowledgeable can't be exceptional knowledge, by definition. If you want to find exceptional directors of engineering, you need an exceptional person worthy of being director of engineering to evaluate them.

 _In seeking victory, not going beyond what everyone knows / is not skilled.

Victory in battle that all-under-heaven calls skilled / is not skilled.

Thus lifting an autumn hair does not mean / great strength.

Seeing the sun and moon does not mean a / clear eye.

Hearing thunder does not mean a keen ear.

So-called skill is to be victorious over the easily / defeated.

Thus the battles of the skilled are without / extraordinary victory, without reputation for / wisdom and without merit for courage._

\- Sun Tzu Ch. 4 (Denma translation)

</comment><comment><USER106> This is also the test for the Technical Program Manager position. You must prepare rigorously to get through the initial conversation with a recruiter. The recruiter I spoke with seemed more open to me explaining why my answer was different than the recruiter OP dealt with.

</comment><comment><USER107> Here's the good news: Google will get the directors of engineering they deserve.

</comment><comment><USER108> I had this almost exact same Google phone screen, in 2010, for an SRE position. I'm 100% certain this is not a director-level test. I thought it was incredibly simple.

The second interview (phone interview with an engineer) was challenging. The third was on-site, and I failed, but was still a good experience. I'm a "small startup" type anyway.

</comment><comment><USER109> I realize they have enough applicants not to care, but constantly reading this kind of thing about Google makes me never want to apply to work there.

It sounds like they took the worst parts of a startup, graduate research lab, corporation and bank and put them all together, but they have enough advertising $ that it doesn't really matter.

</comment><comment><USER110> The problem is Google doesn't need you. Google gets onefinity applications per day. If they shave %90 percent of cold applicants this way then they will not hurt for more applicants. A company that large will gain it's best participants by reference.

\</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-----

my interview with google was very short.

them: what is 2 ^ 37?

me: can I use a calculator?

them: no

me: then we are done here.

<comment><USER11> Did they want an exact answer? Getting closeish without a calculator is not too hard: 2^30 is about a billion, so 2^37 is about 128 billion.

</comment></comment><comment><USER111> The standard Google phone interview.

I got almost the exact same questions. My interviewer seemed more capable though.

I also wasn't as technically correct as this gentleman so my slightly less correct answers were more "right".

As sad turn of events given that I would have loved to answer the same way as he did here, these are much better answers than mine. But this is just technically recruiting, it's a crapshoot at best. It's much better to just take jobs at places that don't insist on trivia competitions.

</comment><comment><USER112> Hehehe - that's really funny. Why did they even need a "body" behind the test? If all the person is doing is reading from script - it could have been just web based.

</comment><comment><USER113> I have interviewed many people, in large and small companies, and saw how interview processes get built in the wrong and right way.

First, here's two reasons why interview processes suck. One, is that no one wants to help recruiting, or HR, do their job. Helping them is an errand and is done in a robotic way. You end up with an idiotic checklist that is a shame to great engineers. Second, is when the team finally realizes idiots joining the team are hurting the team - they will go about and have more motivation to support the recruitment process. Then, when you let a group of people devise such a task you get: an average process designed to leave out the human parts (shift bytes in array) and fit each person's interview style, or a crazy idiotic processes made by people mentally jerking off to each other (implement raft. in assembly). A team can be a company or an actual software development team.

The right way to do it, is this. I believe a single person, who cares about developers, who is passionate about developer experience - should build his/her team's interview process. He/she can take feedback from the team, but that person should eventually build the process and make the calls.

In this specific case I want to believe there is an accurate answer, and a correct answer, and they wanted the correct answer, or at least to see him negotiate his way to the correct answer even though it is subpar (although his accurate answers are impressive). That being said, I'm giving Google credit here. There is a small chance it might just be one of the first options I've described here.

</comment><comment><USER114> terrible interview questions, that's why only technical people should be giving technical interviews. Most answers to questions are more nuanced than a straight quantifiable answer they have on a sheet of paper.

</comment><comment><USER115> I had a somewhat similar experience when I was doing an on-site interview for an internship at a different large tech company.

There were multiple interviews with short (15-minute) breaks in the middle. Most people asked a mix of technical and behavioral questions, but one of the interviewers did things a little differently.

After we briefly introduced ourselves, he immediately asked me a technical question. I usually talk through the problem and ask for clarifications, he mostly gave me non-answers. I was asked the same question by another company a week or two earlier, so I started writing out code on the whiteboard. At a few points I asked whether or not I should handle an edge case, and every single time he said "yes".

When I was done writing all of the code, it took up pretty much the entire board. He asked me - "Why do you have so much code on the board?" and I responded "because I'm handling a lot of edge cases". As I recall that was pretty much the end of the interview.

I'm generally pretty good at interviewing, so I took whatever he threw at me and just thought he was a little off. It's not hard to imagine someone who isn't great at interviewing or has imposter syndrome doing worse in that interview just because of the way the interviewer acted.

</comment><comment><USER84> I would agree with "metadata" answer being correct.

"Each inode stores the attributes and disk block location(s) of the filesystem object's data." [1] A file's "attributes" are independent of its storage. One could also argue the notion that a FS object's ACL are attributes of the file.

[1]: [https://en.wikipedia.org/wiki/Inode](https://en.wikipedia.org/wiki/Inode)

<comment><USER87> Except that anybody who actually does understand what an inode is and what it's for would say exactly what OP said.

<comment><USER116> No, because OP is describing an _inode number_ , not an inode.

</comment></comment></comment><comment><USER117> What always bothers me with most interview questions is the focus on hard technical stuff that's very easy to acquire and forget and easily relearned. I much more care about a candidates capability to write code that's maintainable. The hard challenges we are facing in our jobs are rarely hardvore technical issues but usually just being able to keep going at a fast pace without drowning in the legacy code we wrote last week.

<comment><USER118> Beyond even that, Google is in sore need of some creative people with business sense. They continually create and cancel products. And the products they create in general just dont fly. Besides email, search engine and ads, they just fluster about confusedly.

</comment></comment><comment><USER119> The interviewee give the right answers but in a more precise and more low- level - even pedantic way.

Clearly he know's much more about the questions than the interviewer but he's mistaken the nature of the interview.

This really is a preliminary phone screen and he should have recognised the interviewers lack of experience early and just played the game.

I'd be be tempted to not go ahead with him just for his lack of emotional intelligence.

</comment><comment><USER120> For those doubting the interview, I was asked many of these same questions for a mid-level role by the recruiter just a couple of months ago. It's real. Passed the phone screen, but decided not to continue.

</comment><comment><USER121> Why would a person interviewing for a director position let a recruiter do a tech screen? Wouldn't it at least be respectful for the hiring manager to do this evaluation? Something is very off here.

Or does Google use the same "we have a generic interview and if you get through we will then decide which team to place you in" crap for director level hires as well?

<comment><USER122> Google almost certainly receives many thousands of applications for the position. It sounds like this particular "prescreen" may be badly designed, but after a prescreen you'd certainly expect to talk to more technically- literate and -competent people.

</comment></comment><comment><USER123> This well illustrates the problem with "CS Trivia" style interviewing. It's billed as "exploring your background and how you think, not quizzing you for specific answers," but almost always devolves into an adversarial ego- measuring contest to see who can recite the most trivia from memory.

Much of of the content is minutiae that a working software engineer doesn't ever need to know and would just look up in the rare case where they did (how many bytes in a MAC address? Seriously?).

It's particularly bad when, as here, the candidate knows more than the interviewer does. The interviewee gives exact, nuanced answers while the interviewer only knows approximately correct answers that don't quite match. The interviewer then feels that their ego is vulnerable, that they are facing a serious potential competitor for social status at the company. They then summarily reject the candidate's correct answers as a defense mechnaism.

</comment><comment><USER124> I took this exact same test for a SRE (site reliabilty engineer) position at google earlier this year.

I failed in the same way the author did but the recruiting person helped me so much that i could proceed to the next level.

Obviously she was aware that this test was broken and that candidates would occasionally pass it by sheer luck.

Other later interviews were equally broken in the same ways.

</comment><comment><USER125> The irony of "Director" roles is that they're supposed to provide "Direction".

This requires gently pushing Engineers out of their comfort zones and into new territory.

Often a Director's specialized knowledge comes at the expense of defying conventional norms.

Filtering for candidates that can answer CS trivia will just get you Directors that know trivia.

</comment><comment><USER126> wow, thats especially terrible. The engineering interview pre-screen I had at Amazon was better than that. Can't imagine why a company would do this for ANY technical position, much less such a senior one.

I did have an HR pre-screen one time where they sent me a SQL literacy test (did not specify sql dialect). One of the multiple choice questions had all correct answers, in different sql dialects, with no "all of the above" option. I corrected the test. I did not get a call back.

</comment><comment><USER127> Google and all the other mega-tech corps do a similar tech phone screen where they're reading off an answer sheet. (powers of 2, sort these functions, linux kernel calls, etc).

Sounds like you dodged a bullet, this sort of thing speaks volumes to how the company is run internally and how you'd be treated there.

</comment><comment><USER128> Mirror: [http://webcache.googleusercontent.com/search?q=cache:rPrtrh1...](http://webcache.googleusercontent.com/search?q=cache:rPrtrh15wsMJ:www.gwan.com/blog/20160405.html+&cd=1&hl=en&ct=clnk&gl=us)

</comment><comment><USER129> Perhaps they are looking for a pointy-haired-boss type rather than someone who actually knows his thing.

<comment><USER87> Sorry, you got too many right, you're not right for this role!

Actually, come to think of it, I did have an interview experience like that, just a few years ago. At the time, my title was VP of engineering, but for a small startup. A bigger company was interested in hiring me for a VP-level (or maybe director level, I can't remember) position, and phone screened me. After about ten minutes of talking, he said, "are you sure you wouldn't be more interested in our technical architecture team? You sound like a good fit for our technical architecture team".

<comment><USER129> Thing is, mortals like I know very little about workspace psychology compared to large scale operations such as Google. I have an inkling of an idea because I was repeatedly subjected to the same problematic environment too many times in my 10 year career as a simple software developer with no lead titles.

Off the top of my head:

There is always someone incompetent getting paid more than you. I think this means they are willing to spend money on someone else so you work harder to reach his/her status like a horse going after a carrot it will never reach.

There is always some kind of boss who will not indulge in technical details in order to understand how long a project would really take before pitching the idea to a customer. This is their way of "getting things done" or "making hard things a reality".

</comment></comment></comment><comment><USER130> He seems to be pretty proud of GWAN, but it doesn't appear to have stood up well to HN traffic.

<comment><USER131> Could be his software sucks, or could be that he put it on a single node somewhere on a tiny VPS and he hit some sort of limit by his provider. Not fair to draw any conclusions imo.

</comment></comment><comment><USER132> Have had similar phone screen experiences for various roles, and _sometimes_ the screener seemed to understand that I had a lot more knowledge/experience they did, and trusted my explanations, because I'd talk to them some more and explain the answer (their answer) in more detail back to them. Some of them may have thought I was completely BSing them, but a few seemed to grok I was more than qualified based on the answers and put me through.

Also took a computer-based test at a recruiter once, re: PHP, and it was... 20 questions. One of the questions was _wrong_ , in that the syntax of the question as posted was incorrect. Pointed that out, and got a "thank you, we'll call you" kick out the door.

</comment><comment><USER133> A "technical" recruiter asked me "how comfortable are you with 'tomcat' programming language". I said I am not at all comfortable with "tomcat" programming language because I have to invent one. He was furious and hung up.

</comment><comment><USER134> Once in an interview for a web developer role I was asked to list the layers of the OSI model.

As I rattled off the layers the guy looked super surprised and asked how I remembered them and I said "pretty dicks never touch shitty people's assholes."

Needless to say, I got the job.

</comment><comment><USER135> When I interviewed at Google for a Ads Solutions Engineer, I had some of these questions asked as well. (I got an 8/10 and was pushed to the next round).

I assume they have a massive list of questions (for various positions and have a minimum cut off - 7/10 I'm assuming as a few of my friends who got 6/10 and were not moved forward) and are asked to all applicants without consideration of experience/skill/previous work as well explained by Max Howell[0]).

[0] [https://twitter.com/mxcl/status/608682016205344768?lang=en](https://twitter.com/mxcl/status/608682016205344768?lang=en)

</comment><comment><USER136> Are they hiring a reference manual or a director of engineering?

</comment><comment><USER137> But can he invert a binary tree?

</comment><comment><USER138> He failed in the first sentence:

> I started coding 37 years ago (I was 11 years old)

they wrote him off right there

</comment><comment><USER101> The Google person's response to the answer in question 5 would have pretty much ended the call with "can I talk to an actual engineer as you are doing poor keyword searches on my answers". I do admit to hearing the "I will stab you" voice in my head on that one[1]. This reflects really badly on Google.

Plus the answer on question 8 is the best worded answer to using big-O improperly I have seen.

1) [http://www.urbandictionary.com/define.php?term=I%20will%20st...](http://www.urbandictionary.com/define.php?term=I%20will%20stab%20you)

</comment><comment><USER139> If this is true, then it's not surprising as usually the person asking the question is not up to speed on the details of the question being asked.

I recall a question, which was how do you stop a socket from overflowing?

I said what do you mean? If you write to a socket and it fails to accept the write it will fail. Sockets do not have any option to stop this.

Naturally I failed the question yet I asked for the correct answer and was told the answer is simple, just use a cache.

Nice answer, excepts sockets do not have caches.

Correct Answer: Add a cache to the socket to stop them failing but that was not the question.

While that answer is obvious, it was not the question asked!!

</comment><comment><USER140> I would have stopped you half way through. You obviously know enough to move on.

</comment><comment><USER141> Sometimes I wonder if this approach has hurt Google's ability to innovate.

<comment><USER142> Nah. Having 57,000 employees did that.

</comment></comment><comment><USER143> Interviewing is a two way street. You have to be high enough in the food chain to be able to reject companies. Otherwise, you are going to just face such meaningless things over and over.

</comment><comment><USER144> I'm surprised when people are surprised that Google's interview process is obnoxious. That's pretty well established by this point, both by Google employees and others.

<comment><USER145> There's literally quite a few people in here, including Googlers, that can't believe Google asks these questions.

(I don't necessarily believe the interview went down as reported, but the questions and the interviewer using a sheet with approved answers definitely are genuine)

</comment></comment><comment><USER36> Knowing the right answer, or when "it depends", is not the expectation. You need to get inside the mind of the interviewer and figure out what he/she thinks is the right answer is, or guess what's probably written on the answer sheet. Think: "What answer would a know-it-all 23-year-old Stanford graduate give?" That, and not necessarily the right answer, is what will get you the job offer.

This is also called "cultural fit".

<comment><USER146> I was with you until the end. Instead of cultural fit, I would call it "a stupid way to hire".

</comment></comment><comment><USER147> Well, I had a similar experience in my last (out of 9) interviews for a SWE position, and that interviewer was simply not accepting answers other then his, even though they were sometimes better. Welp, I will start again my interviewing marathon at Google next week, hoping that this time I meet the right interviewers (which is the only way you can actually get in, not by knowing stuff).

</comment><comment><USER148> I interviewed with Google about 10 or so years ago for a manger post. I was not selected after 3rd phone interview.

Potential job was about predicting number of servers required or something like that. I was recommended by a friend's friend who apparently worked there. Google contacted the day they saw my resume and did two quick phone interviews verifying my basic background.

In the third interview which was highly technical, they asked a bunch of techie things including what an inode was. Whatever answer I gave about inode was apparently OK, as the interviewer proceeded to ask me how I would repair a faulty inode.

Since I did not know the answer, I honestly said I do know and joked that I would "google" for the answer. My pathetic attempt at humor did not sit well with the interviewer and was told that I did not pass the current interview.

Fixing inodes or other hardware/software problems is certainly something that needs to be done, but I did not buy the interviewer's assertion that everybody in Google knows how to fix inodes. For making predictions about server needs, failure rates are just one factor to consider and the time needed to repair them.

Whether a prediction manager needs to know the low level details of fixing inodes is questionable in my mind. I just assumed that Google interviews a staggering amount of people and reject a large portion of them for the smallest of reasons (like how astronauts are selected). It also seems they hire people for one thing, but that does not preclude them in deploying them in totally different positions. Otherwise there was no reason to ask me techie questions.

What surprised me was how fast they moved, how upfront they were about overall interview process, and how they asked about non essential questions from my perspective.

</comment><comment><USER149> I had very similar intervies at Palantir and Yelp, albeit Yelp was understandably just a quick phone screen with a recruiter. However, the "trivia" interview at Palantir came from a forward deployed engineer on the DC based team I was interested in working with and one of my last hour long, onsite interviews of the day. Seemed like a big red flag at the time.

<comment><USER87> > the "trivia" interview at Palantir ... Seemed like a big red flag at the > time.

Besides the bigger red flag that it was Palantir, you mean.

<comment><USER149> No, at the time Palantir was mine and a lot of other people's too choice at Berkeley. They spent a ton of money on recruiting my class and I went there for dinner/lunch several times.

</comment></comment></comment><comment><USER150> Well, I think it's clear that the author is qualified to move beyond this stage of phone screening. So, the interviewer was at fault for not passing him, mainly due to a lack of technical knowledge imo and possibly and incomplete cheat sheet.

That said, I question how he's phrased some of the question/answer pairs. For instance, this is a phone interview so the questioner can't capitalize KILL in the signals question ("what is the name of the KILL signal?"), which makes me wonder how the question was actually phrased. It does strike me that SIGTERM is what the 'kill' command will send by default, which could have been the intent of the question.

He obviously still should have passed though, all of his answers indicated a good knowledge of the subject, and that's even if you consider them to be ultimately incorrect. I guess it's possible that op's tone didn't ingratiate him to the interviewer, but that's impossible to say with the information we have.

</comment><comment><USER151> These are pretty much the questions I got asked on the recruiter screening interview for SRE/SWE.

But I kind of agree with the sentiment of "uhg, srsly, are we still doing this?". I answered a few of those with "not sure, I'd Google that". The recruiter's reply was "but what if Google's down". Well, there's always Bing.

</comment><comment><USER152> I've seen a lot of these types of blog posts on here, about interview practices at the large tech companies. Because of these posts, I have no interest at all in seeking an interview with Google, Facebook, or Apple.

Maybe these types of interview practices are designed to reduce the applicant pool by scaring people away from even applying.

</comment><comment><USER153> Pretty sure Google's interview questions are under NDA.. Brave!

<comment><USER154> This sounds like a phone screen--i've never signed an NDA for phone screens or at any stage of the interview process for that matter.

</comment></comment><comment><USER155> I think the person interviewing in this article should have seen the person doing the interview was looking for short answers. It is not a perfect interview process but I am not shocked he did not get it as you can see his annoyance as the interview goes on.

He could have answered, "because Quicksort is N * lg(N)". Instead he opted to have a long answer about it depends how the algorithm is implemented. It either shows he is completely unfamiliar with big-O or he chose to give a annoyed answer. He could have also answered that there are a family of algorithms such as merge sort which are also N * lg(N).

A bit skeptical of the transcript as well. Knowing a MAC address in bytes off the top of your head? Almost every other person would first think okay how many HEX characters is it, and how many bytes in a HEX. But he has this knowledge immediately?

</comment><comment><USER156> The process seems geared towards hiring people right out of school since they'd have no expectation that such a candidate would be able to answer such questions.

Am I right in thinking that it's easier to become a Googler by starting a company that gets acquired than by submitting to such a broken interview process?

<comment><USER58> _Am I right in thinking that it 's easier to become a Googler by starting a company that gets acquired than by submitting to such a broken interview process?_

No, not at all. At least it used to be so that when Google acquired a company, they ran all your engineers through their interview process, and if more than half didn't make it, they stopped the acquisition and the deal was off.

The justin.tv/Twitch people blogged about how this effectively made them a billion by stopping an early acquisition until they were worth much more.

(Or at least that is what I remember reading - I can't find the article right now, so maybe it wasn't Twitch)

</comment></comment><comment><USER63> I would like the original blog poster to state for a fact that the questions they posed are exactly the ones that were asked. In particular: the quicksort one. It doesn't jibe with my memory of how the question was asked (it was more like "what is the running time of quicksort").

</comment><comment><USER157> That's pretty similar to what I was asked over the phone in an interview for API support (I forget exactly what the title was) for Google Maps, I believe. I got the SYN, SYN-ACK, ACK answer; questions about sorting algorithms; and stumbled a bit on random Linux questions, even though I use it daily as my desktop OS and have administered various Linux web servers for years without issue. I guess I use the man pages too much. The recruiter didn't cut my phone interview short, but did tell me that the technical interview was going to be WAY harder and that I needed to study my Linux, low-level networking, and algorithms. It was a good interview experience to have, but left me feeling like I'd never have the knowledge to pass a technical interview there.

</comment><comment><USER71> New theory: maybe it was a psychological test, to see how you would react in a difficult situation.

</comment><comment><USER158> Did anyone bother to read up on this 'business' of his? I just spent some time in the Wayback Machine[1], and it strikes me as pretty odd: unbreakable encryptions systems (which are not disclosed), NSA backdoors everywhere and general paranoia.

</comment><comment><USER159> _Recruiter: wrong, it 's SYN, SYN-ACK and ACK; if Google is down you will need to know this to diagnose what the problem is. We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. You should learn the Linux function calls, how the TCP/IP stack works, and what big-O means to eventually qualify if you are interviewed at a later time. Good luck, bye._

Whether he got interviewed for the wrong position by mistake or not -- how can Google begin to think that putting technically illiterate people in charge of "vetting" obviously highly senior people... could ever possibly be a good idea?

<comment><USER160> Hiring on their scale is generally unsolvable - anything goes.

</comment></comment><comment><USER161> I do some interviewing for my company sometimes. HR people suck at it, but they don't ask any forms of technical questions.

So it'd be strange to have such deep questions asked by a non technical person for such a high position.

Secondly, I was interviewed by Google once. The interview was great (even though I failed it).

Third, during this interview, I signed a kind of non disclosure.

On the other hand: I was also interviewed by Microsoft. The interviewer was non technical, and asked at least two tech questions (the difference between a struct and a class in C++, and what volatile meant). And, finally, Roy Osherove has a similar tale about Google.

</comment><comment><USER162> This is hilariously depressing. Makes me never want to bother with the big guys.

</comment><comment><USER163> This is 75% similar to a phone screen I passed (somewhat surprisingly, in hindsight) in 2003-2004. I don't think this is a director-level test, it's just a coarse engineer-track filter.

</comment><comment><USER164> Have any current Googlers here had an experience where they knew someone personally, could vouch for their skills, but still could not get them in, due to them not passing the interview process?

</comment><comment><USER165> This is what happens when a non-technical person conducts a technical interview.

Though I'm surprised this happened for a Google interview. Their recruitment workflow should now have allowed this to occur.

</comment><comment><USER166> This seems a bit strange. I know some senior Google folks who spend a ton of time interviewing. Could it be that these are maxed out, and that HR people are forced to do the initial screens? In that case it's best to just feed them the simplest accurate answers possible. Similar to taking the SATs.

This type of process does imply something about their recruiting funnel. HR people asking technical questions suggests they've historically passed too many technically deficient people to overworked senior engineers.

</comment><comment><USER167> How is Tcp/ip stack, MAC addresses and low level linux commands are "up to date codong skills".

Not saying they are not important, but you could have asked the same questions 20 years ago.

</comment><comment><USER168> #9 is especially stupid because it's so context-dependent. SSE4 gives you a popcount instruction, for example, which would be easily the fastest way to do this, if available.

<comment><USER169> Yes, but without that instruction, the algorithm mentioned by recruiter is really the quickest way. I coded chess algorithm in the past and this was exactly the method top chess open-source engines used. But imho it is hard to figure that out without prior experience with this problem.

<comment><USER170> Yep. Went and tried the lookup method against a 5 step parallel shift and add method (which is the fastest bitwise way I know of without, and the lookup is ~5% faster than the bitwise way.

[https://gist.github.com/monocasa/1d44a03cbd0170bfffc6a4a5c37...](https://gist.github.com/monocasa/1d44a03cbd0170bfffc6a4a5c37b2210)

<comment><USER58> Your code has 6 shifts, 6 adds/subs and 6 ANDs.

You can do it with 4 shifts, 3 adds, 1 MUL and 4 ANDs.

Your code is simply suboptimal.

<comment><USER170> For a 64bit quantity? I'm curious to see your algorithm in actual code.

</comment></comment></comment></comment></comment><comment><USER171> If I ran Google, I would just send unsolicited offers for a three-month trial contract to people who fit the profile of a talented software engineer with a friendly personality and who recently started searching for jobs. Yes, I know, "that's why you don't run Google," but I don't think it's that crazy. For example, I may or may not be a good fit, but even if I am, the chances are slim that I'll ever have the confidence to apply.

</comment><comment><USER172> So… someone care to explain to me where I'm going egregiously wrong, apparently? Because, at least on my machine with the code I spewed out quickly, the Kerningham way of counting bits is ~6x slower than a lookup table (including generating the table itself).

[http://sprunge.us/IIEH](http://sprunge.us/IIEH)

The Kerningham way code seems faster for _very_ sparse arrays (i.e. only one bit set per uint16), but slower otherwise.

<comment><USER173> You weren't doing anything wrong. He discusses two methods: [https://graphics.stanford.edu/~seander/bithacks.html#CountBi...](https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetKernighan) [https://graphics.stanford.edu/~seander/bithacks.html#CountBi...](https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel) The second option will probably beat a byte lookup table. GCC switched from a lookup table to similar code. If this still isn't fast enough, try using SIMD registers and the Harley/Seal method based on carry save adders ([http://www.hackersdelight.org/hdcodetxt/popArrayHS.c.txt](http://www.hackersdelight.org/hdcodetxt/popArrayHS.c.txt)). If you like this sort of bit twiddling, you probably would enjoy Henry Warren's Hacker's Delight.

</comment></comment><comment><USER174> This wasn't a technical interview, it was an asshole detector. And it worked.

This test was written by somebody who knows the answers as well as this interviewee. It might have even been administered by somebody who is also in on the game. A tech prima donna like this is team cyanide. I once had to escalate to the VP of Engineering to get one such engineer off my project. The entire work atmosphere improved after he was removed.

</comment><comment><USER154> quicksort is O(n^2) which is definitely not the "best big-O" for sorting.

<comment><USER154> "how do you count the bits most efficiently?"

What does this even mean?

<comment> UK-AL What i think he means is counting the amount of set(1) bits in the array,

<comment><USER154> Thanks, the question makes more sense now :)

</comment></comment></comment></comment><comment><USER71> On #9, is it 16-bit or 64-bit values? Sounds like you may have been answering a different question. Isn't the standard answer to use a 65536 entry lookup table?

Edit: oh, are you reinterpreting the array of 10000 16-bit integers as 2500 64-bit integers? But then what operation do you use on each?

Either way, if you find yourself arguing with the recruiter, it's probably a bad sign.

<comment><USER175> I thought the reason it was generally accepted that the 8-bit lookup table is optimal is because it can fit in the L1 cache.

<comment><USER58> (Very) embedded developer speaking here. What's this L1 cache you speak of?

<comment><USER124> It's level 1 CPU cache, the fastest (and smallest) cache.

It caches both instructions and data.

[https://en.wikipedia.org/wiki/CPU_cache](https://en.wikipedia.org/wiki/CPU_cache)

<comment><USER176> It was a joke. Some embedded processors lack a cache.

</comment></comment></comment></comment></comment><comment><USER177> Thinking more about this, it's also possible that the candidate failed on understanding what the screener wanted, and giving it to him. If the question was "what signal does kill command send by default" and the candidate hears "what is the name of the kill signal," that's an indicator about important communication skills.

</comment><comment><USER178> I think he took his website offline.

You can see read cached version here, [http://webcache.googleusercontent.com/search?q=cache:53TICuY...](http://webcache.googleusercontent.com/search?q=cache:53TICuYCFiYJ:gwan.com/blog/20160405.html+&cd=1&hl=en&ct=clnk&gl=us)

<comment><USER179> It's not, it just got overloaded. Guess G-WAN can't handle Hacker News. Funny that.

In case you missed it: G-Wan is a software he is selling, which supposedly is twice or fourt times faster than everything, including nginx and varnish cache.

</comment></comment><comment><USER180> You can fire this Director of Engineering.

</comment><comment><USER181> There loss.

I am glad you kept a log of all the questions. I think the problem exists with a lot of tech companies our there. In my short career, I have been asked to solve mathematical problems, which is absolutely fine, but I write web apps that are not even remotely related or perform any complex calculations.

</comment><comment><USER182> I was recently asked in an interview (for a position as programmer at a 3D printer startup): "When we have to update our software, we have to update thousands of machines. How would do you see that reflected in the _code_ of our _error recovery_?"

Am I stupid, or is that a hard to answer question?

</comment><comment><USER183> > Google pagerank: the ultra-secret mathematical formula demonstrating that > sponsored search results rank higher than reality can.

I am not sure why he was rejected, but this sentence makes it clear that he isn't mature enough to be a directory so I doubt that Google misses him.

</comment><comment><USER184> And what is an SRE at Google? [https://www.atlassian.com/it- unplugged/devops/site-reliabili...](https://www.atlassian.com/it- unplugged/devops/site-reliability-engineering-sre)

</comment><comment><USER185> Q: What is 2+2?

      Me: 4
      Recruiter: Wrong.  2 + 2 = 5 for very large values of 2.

</comment><comment><USER186> Wow, I need to apply for a director job at Google. I knew about 8/10 things to the level that the recruiter knew about them with my 20+ year old C knowledge. The guy who responded was way better but obviously overqualified!

</comment><comment><USER187> This is exactly on par with my experience with them -- I was interviewing and a particular engineer just wouldn't let me move forward with "linked list" because he wanted me to say "queue".

</comment><comment><USER188> Both of them come off as really obnoxious. I highly doubt this is real though.

</comment><comment><USER189> Am I the only one who thinks that this is a terrible way to hire any Engineer, Director or not? I may have hung up after first 3 questions saying that "this does not sound like a good fit to me".

</comment><comment><USER190> They need to get rid of that recruiter. He/She is obviously not technically educated enough in computer science enough to understand the meaning of what is being said - Only the literal answer.

</comment><comment><USER191> Perhaps the context of the interview is that you must answer using no more than three words or numbers. In this context defining a hashmap as a fingerprint or an inode as metadata is ok.

</comment><comment><USER192> I believe the guy just talked with one of the non-tech recruiters from the agencies, not the actual Google employed recruiter.

There are bunch of those non competent recruiters playing smart asses...

</comment><comment><USER193> Looks like the page is down. Is there an archived copy somewhere?

<comment><USER194> Archived version: [http://archive.is/2Fj58](http://archive.is/2Fj58)

</comment></comment><comment><USER195> Another google HR "experiment" that obviously failed...

<comment><USER196> (un?)fortunately big companies like these have enough resources to have failed experiments..

</comment></comment><comment><USER197> Well, assuming the transcript is even remotely correct, they should start doing phone screens using algorithms. I'd guess they would outperform this recruiter.

</comment><comment><USER198> Good to see that recruiting is broken for big positions too.

</comment><comment><USER199> Had similar questions for an SRE role, but yes i didnt like the fact that i had to answer these over the phone to a recruiter. Also i was asked what is 2^16

</comment><comment><USER200> I would be extremely offended if I was in his position and an HR-bot (both literally and figuratively) wasted my time with an interview process like this.

</comment><comment><USER201> While there is a notion that devs are in demand for a company like google they have so many candidates that can be dicks to people and get away with it.

</comment><comment><USER202> He's confused an inode (file object) with an inode number (the index). But who cares? This is not a useful interview question.

His confusion carries over to the stat question, because he's still thinking an inode is just an index. That said, I wouldn't describe stat() as returning an inode, either... it fills a stat struct. That's all. Inodes can have more or less information than is present in the standard stat structure.

If this is how Google interviews director candidates, they've really gone downhill since I last tried to interview there in 2011 or so.

</comment><comment><USER203> Received a phone interview for the UK Google Maps team. Interviewer couldn't pronounce 'spatial'. My heart sank.

spat-e-all. spat-e-all. \o/

</comment><comment><USER204> Looks like the other side was just a turing machine.

</comment><comment><USER205> It was not the answers but the cultural fit ehehe...

</comment><comment><USER206> Looks like the recruiter failed the interview here.

</comment><comment> mk-61 Feels like overqualification for that position.

</comment><comment><USER207> I've interviewed at google for a lower position, and recruiters don't do phone screens or ask technical questions.

</comment><comment><USER208> If I were interviewing him and he gave those answers I'd definitely give him a second round and try to get him in.

</comment><comment><USER209> This is epic. Why would not Google just give a written test and not use a recruiter for this? I do not see the point.

</comment><comment><USER210> "Powered by G-WAN" but that is down.

Based what the interview goes, Google might be on the "down" path too.

</comment><comment><USER211> I had a Google phone interview around 2008. I remember a question how much is 2^5 (without calculator :).

</comment><comment><USER212> In summary: "Recruiter: that's not the answer I have on my sheet of paper."

</comment><comment><USER213> > What is the opposite function of malloc() in C?

Google uses C++. Do they use malloc/free?

<comment><USER58> Google makes extensive use of third party libraries. Some are in C.

</comment></comment><comment><USER214> I really hope this isnt real.

</comment><comment><USER169> I once coded chess playing algorithm for fun, and can confirm that the recruiter was correct on #9: you count bits by using a lookup table and then sum the results. It's the quickest way. But I am not sure if this is possible to figure out immediately without such experience...

<comment><USER58> Ah, the appeal to authority.

It depends, but generally speaking, you are wrong and OP is right that you'd want to benchmark on the actual architecture.

a) First of all, you're probably basing your answer off of experience with 64-bit popcounts. But note the question was about popcounting multiple 16-bit words, not single 64-bit words. This _isn 't_ typically what you do in a chessprogram. b) The table has a cache footprint and can be pushed out of L1, which kills that approach in many real programs. c) Modern CPUs have a POPCOUNT instruction. It's slow and limited to one port on most Intel machines, though, so not necessarily always a win either. d) Lacking POPCOUNT, and with cache pressure, the SWAR approaches are good, especially if you can compute multiple results at once. With AVX2 it becomes especially interesting. f) If the the expectation is that many of the numbers are zero, a simple loop will win.

<comment><USER215> >"Lacking POPCOUNT, and with cache pressure, the SWAR approaches are good, especially if you can compute multiple results at once"

Can you explain what a SWAR approach is?

</comment></comment></comment><comment><USER118> >that's what happens when AI bots discover recreational drugs. LOL

</comment><comment><USER216> This entire transcript reads like a metaphor for democracy.

</comment><comment><USER217> The best solution to this problem is multiple choice.

</comment><comment><USER218> This is the best example of one unintentional DoS attack, now I cannot read it anymore :(

</comment><comment><USER219> for this level, isn't the process itself a bit humiliating?

</comment><comment><USER220> looks like he needs a better web server for hosting his blog :-)

</comment><comment><USER221> anyone have a mirror ?

<comment><USER222> Webcache from Google: [http://webcache.googleusercontent.com/search?q=cache:rPrtrh1...](http://webcache.googleusercontent.com/search?q=cache:rPrtrh15wsMJ:www.gwan.com/blog/20160405.html+&cd=1&hl=en&ct=clnk&gl=us)

<comment><USER221> thank you

</comment></comment></comment><comment><USER223> Can anyone access parent site? Seems we have given it the HN kiss of death.

</comment><comment><USER224> Site's down?

<comment><USER225> [http://archive.is/2Fj58](http://archive.is/2Fj58)

ctrl-f for "down" next time :P

</comment></comment><comment><USER226> Offered without comment:

The site has been flaky, if not down, for hours now.

</comment><comment><USER178> aaaand website is offline 100%

</comment><comment><USER227> I'm reminded of a story about Einstein in the 1930s. The fad at the time was to have a "skills test" which was supposed to place you perfectly according to your results.

Einstein took the test, and did _terribly_. Everyone was shocked, and asked him what was going on. His response was "The questions tested memorization. Why would I remember what the capital of North Dakota is? I can look that up in a book!"

Perhaps unsurprisingly, the tests faded out of popularity.

It's sad that 100 years later, even Google hasn't learned that lesson.

<comment><USER228> Perhaps, as of yet, Google isn't living fully by their own principles ("automating themselves out of a job"), maybe because the tech isn't _quite_ there yet or maybe for other reasons. It remains to be seen if the ultimate solution to bureaucracy is AI/ML _or_ if it will just be a further extension of these same mechanisms.

The problem with simple "skills tests" is they lack depth, and of necessity due to time, always will. The problem with performance tests is the opposite: they may take too long to reach a conclusion in human terms, during which time significant money is lost.

Recruiters seem like a great candidate for replacement by AI. [edit: and I should add, most middle managers too]

</comment></comment><comment><USER229> This is very hard to believe. In most big tech companies technical interviews are conducted by technical people, not recruiters. Especially for a senior role like Director of Eng. the experience described here stretches credulity.

Also most of these companies have policies which don't allow any feedback to be given on interview performance. In light of that the recruiter saying "you don't have necessary skills" is extremely surprising.

<comment><USER230> As stated elsewhere, these questions have been very typical for what I'd call 'first level phone screen' for SRE positions at Google.

I interview with Google every couple of years for fun; I always learn a lot and have a lot of fun with the on-site interviews.

The recruiter does indeed ask these kinds of questions. I've been asked most of the ones mentioned here, some of the multiple times.

I find it extremely hard to believe that the answers the recruiter had in front of them was wrong.

So to be clear, how it has worked every time I've done the dance with Google is:

1\. An initial, non-technical recruiter chat.

2\. The recruiter gives me a series of technical questions with extremely clear-cut answers, as described in the article.

3\. A phone screen with someone technical.

4\. A second technical phone screen.

5\. On-site, 5-6 50 minute interviews.

<comment><USER215> What the 5 different subjects of those 60 minute interviews?

</comment></comment></comment><comment><USER231> "4\. sort the time taken by: CPU register read, disk seek, context switch, system memory read. Me: CPU register read, system memory read, context switch, disk seek. Recruiter: right."

This is the exact question I got in a phone screen (although mine included CPU caches so was actually _harder_ ) for the lowest level SRE position at Google. That and the obvious lack of knowledge of their interviewer, who I'd expect to know these answers inside and out, point to Google lowering the bar extensively not only on their interviewing practices (where it certainly was never high as in quality) but on the actual quality of their hires. Any SRE could be Director of Engineering at Google, apparently, going by this test. I'd say that equates to not having a bar at all.

</comment><comment><USER232> "Recruiter: wrong, it's SYN, SYN-ACK and ACK; if Google is down you will need to know this to diagnose what the problem is. We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. "

Because when Google is down, it's typically upper management that fixes network issues. CEO level to directors of engineering are on pager duty most nights there.

<comment><USER233> May I assume this is tongue in cheek?

<comment><USER232> Absolutely not. The reason so many Google upper management types sport beards (case in point, Sundar Pichai), is the chronic lack of time from working nights as data-center technicians/network engineers. How else can you explain Google's up-time and low-latency? :)

<comment><USER233> Right. Who has time to shave when you're busy examining network traffic?

</comment></comment></comment></comment><comment><USER234> Just a general comment, again anecdotal. There seems to be a trend of recruiters performing bait-and-switch in SV currently.

For example, you may be hired for a technical role, but you end up doing manual work or bash script maintenance.

Another tactic (this one is pretty hilarious) is that hiring managers will continuously interview new people for the same job description, without any intention of hiring them, in order to keep the slot open. Sad, but true.

</comment><comment><USER235> This is weird - do big companies actually ask stupid questions I can google, and let non-technical people lecture engineers on Big-O?

Hope this obviously talented person finds more meaningful employment elsewhere.

<comment><USER87> > do big companies actually ask stupid questions I can google

Well, he was interviewing _for_ google. Maybe they wrote up the test before google was online and forgot to update it.

</comment></comment><comment><USER236> I feel sudden brick wall awaits in a recruiter career path once the google people read that.

Not only because of that interview, but the questions transforms into - <USER3> else have we missed from the great guys ...

<comment><USER76> Having had some experience with big companies, I doubt that. They'll probably just write this guy off as being 'non googley' or whatever, and keep on keeping on.

(assuming the interview really went down this way. Which I have a hard time believing)

</comment></comment><comment><USER237> Maybe they set unrealistic expectations to see if the applicant lies about meeting them and give wrong answers to see if the person acts like a smartass.

</comment><comment><USER238> I think this is a very equitable process. If a medium-functioning retarded person wouldn't hire you, that's saved the company like $100 of time to ascertain your qualifications. This is much better than using biased metrics like problem solving sessions or personal assessments of character from people who will be working with them.

</comment><comment><USER239> This entire blog post does not cast the author in a favourable light.

First off: It is rude to post the questions and expected answers, perhaps moreso when you just failed to pass the test yourself. That reeks of sabotage out of spite.

Then pulls the argument from authority, aggrandizing his accomplishments in an effort to salvage some of his obviously bruised ego.

> Is Google raising the bar too high or is their recruiting staff seriously > lacking the skills they are supposed to rate?

Seems like Google raised the bar just high enough to weed out the unpleasant personalities. A job interview, even a phone screening, is not _all_ about technical skill, it is also about soft skills: Is this person a pleasant and communicative person?

> Recruiter: wrong, it's file metadata.

> Me: the inode is an index uniquely identifying ...

Here is where the interview (or at least, this is probably how the author remembered it) went off the rails. Arguing with the recruiter and trying to right a perceived wrong was just plain bad strategy.

From there on out it starts being argumentative, and you can see the recruiter having none of it.

> Recruiter: Quicksort has the best big-O.

Here you can clearly tell the recruiter is just fishing for "correct" answers at this point. Just tell the recruiter with the big-O is here, don't be obtuse or difficult.

> Why not let me compare my code to yours in a benchmark?

Here it turns into a code-measuring contest. Not a very bright idea. By this point in the interview I find this author's personality very grating and needlessly argumentative. He can't do anything right by now.

> We will stop here because it's obvious that you don't have the necessary > skills to write or review network applications.

The recruiter seems to agree with me, but I doubt this is what was said exactly. The conclusion may be similar though.

> Maybe Google should have stated that practice is not necessary for the job.

Maybe Google does know best what is necessary for the job. Or maybe the author knows, but he is too curt in getting his views across. Not a favourable trait.

It is hard to not get salty over a failed job interview. It takes strength of character to not burn bridges and try again in the future with a more pleasant humble approach. Take it as a lesson and move on.

</comment><comment><USER240> >>Recruiter: I have to check that you know the right answers.

This is classic: _the_ right answers!! Must be google getting infested with managers who don't have shit clue about what is programming and computer science.

</comment><comment><USER241> I'm feeling a bit confident looking at the questions. Woo.

</comment><comment><USER242> It seems easier to get Google to fund and then acquire your startup then get hired there.

</comment><comment><USER243> I am doing neither of those things. I said it was tempting, because it puts things I've read about G-WAN into perspective (the claims I saw some time back when I was shown a heads-up versus nginx were questionable, and it's an interesting data point). That's why it's an unrelated addendum, and it's completely unrelated to the blog post at all.

I have no desire to discredit someone I have never met and whose name I do not know, much like I have no desire to have my intentions explained to me by a Hacker News commenter. I wrote, quite clearly, that I wasn't doing something. To directly assert that I am in fact doing that thing and then ascribe further malice to it is to challenge my honesty and integrity, and I'd appreciate if you'd not do that in the future because you've never met me and know nothing about me.

There is an interpretation of my first bullet that would support your conclusion, but I only put down my first bullet to establish relevance in the comment, not to connect the two things.

<comment><USER244> I never said anything about your integrity but you inferred from my comment just like others will do from yours.

The difference is the individual you're disparaging is a real person with a reputation. You, like me, are a throw away account on a message board. You have no integrity because you have no identity.

<comment><USER245> >The difference is the individual you're disparaging is a real person with a reputation.

So? If the criticism is invalid, then it's inoffensive. If it's valid, it's deserved.

<comment><USER246> False I think.

Invalid criticism posted on the Internet or spoken out loudly might very well negatively affect someones life even if they don't personally care.

</comment></comment></comment></comment><comment><USER247> lol, site down. nice scale

</comment><comment><USER247> lol, site down nice engineering work!

</comment><comment><USER248> Google doesn't ask these types of trivia questions. I don't believe that you were talking to a person from Google one bit.

Everything documented about their hiring practices and anecdotal evidence from people gone through their interview process is that you talk with a real engineer and write code for your interview.

<comment><USER124> I took a phone screen interview for SRE (site reliability engineer) at Google Dublin and the questions at the screen test were the same, almost to the word.

I don't know this guy but the questions he's talking about are genuine Google screen questions.

Questions in the later interviews (that is, if you pass the initial screen) are more complex, and involve actual coding or longer problem solving.</comment></comment>